RE: Je validní dokument...

[Jan Tošovský]

> Tak jsem doufal, že když soubor rozdělím na hlavní book a 
> začleněných 8 
> parts, bude to lepší a pohodlnější a přehlednější, a když 
> ještě z nich 1 
> part rozdělím na 5 chapters, bude to ještě pohodlnější, a když tyto 
> chapters budou dohromady inkludovat 67 section, bude to super - malé, 
> přehledné soubory... :-(
> Jenže, i když jsou tyto soubory v textpadu přehlednější a 
> pohodlnější, 
> skoro se s tím nedá pracovat.
> Neprojeví se to ani tolik v pdf (saxon a fop), ale v eclipse helpu:
> Když u 8 parts se při vytvoření eclipse help saxon rozmýšlí 
> minutu a pak 
> to chroustá 6 minut, v případě rozdělení na zmíněných 
> 1+8+5+67 souborů 
> se u eclipse helpu saxon rozmýšlí 7 minut a pak to chroustá 12 minut, 
> načež skončí na out of memory. :-(
> K čemu tedy je takové dělení, když veškerý efekt je tímto znehodnocen?
> Editory s tím pracovat moc neumí - XMLMind s include soubory 
> nechce nic 
> mít... Syntext Serna Free se velkým množstvím souborů zalkne 
> a zahltí. 
> Ale aspoň se dá přesvědčit, že je to validní dokument, na rozdíl od 
> trialu Oxygenu, který stále trvá na tom, že dokument je nevalidní.
> Vůbec nevím, jak toto množství souborů zpracovávat == 
> editovat a vyrobit 
> eclipse help, chunk html a single html.
> Vy s tím takovéto problémy nemáte?
> Tomáš Waller

Tohle by bylo na samostatnou diskuzi. Deleni na male casti je vyhodne tam,
kde dokument tvori nekolik autoru. Kazdy edituje sve casti a pokud se celek
verzuje, je pri zaclenovani 'vetvi' do hlavniho dokumentu minimum konfliktu.
Zvlaste u WYSIWYG editoru ocenite male soubory pri otevirani. 

Pro sve potreby jsem si vytvoril skript, ktery mi dle struktury na disku
vytvori konfiguracni soubor, podle ktereho se pak seka HTML vystup do
jednotlivych HTML souboru (tzv. manual chunking). Strukturou souboru na
disku si tedy vytvarim hierarchii HTML Helpu (standardni chunkovani obcas
nevyhovuje). HTML soubory mimochodem cti originalni nazvy XMLek.

Oproti PDF vystupu je generovani sady HTML stranek pomale. Je to dane
zpusobem deleni stranek. Lze to optimalizovat pomoci sablony pro tzv. Fast
chunking, vizte http://www.sagehill.net/docbookxsl/Chunking.html

Svou roli ale hraji i uzivatelske upravy sablon. Generovani originalniho PDF
vystupu trva pro muj max dokument cca 20 minut, s masivnimi upravami temer
30. 

Problem s pameti lze resit parametrem predanym jave. 
Problemy pri generovani nemam, clovek si u tech vetsich dokumentu musi holt
pockat. Generuji prevazne PDF a HTML Help, obcas Java Help. S Eclipse Helpem
zkusenosti nemam, mozna je tam nejaky bug, ktery ty pametove naroky neumerne
zvysuje.

Neklesejte na mysli ;-)

Honza