Vkladani/pouzivani obrazku v docbooku

Radek Hnilica Radek1 na hnilica.cz
Pátek Prosinec 16 18:55:06 CET 2005


On Fri, Dec 16, 2005 at 05:34:54PM +0100, Jirka Kosek wrote:
> Radek Hnilica wrote:
> 
> >Chtěl jsem použít catalog entit pro všechny obrázky.  Ten by obsahoval
> >řádky jako jsou ty následující
> 
> Máte nějaký důvod proč obrázky definujete jako entity? Jediný důvod by 
> byl, že chcete přepínat mezi různými variantami obrázků prostou změnou 
> definice souboru s entitami, ale i to jde obejít bez použití entit.

Zdálo se mi toto zavedení dalšího místa "redirekce" vhodné.  Pokud
bych provedl něco s obrázkem týkající se změny jména souboru nebo
cesty.  Nastavil bych to na jednom místě místo hledání všech výskytů.
Nicméně podstatná část obrázků se používá jen na jednom místě, takže
jsem to oželel.

> Nejjednodušší a nejflexibilnější je podle mne cestu k obrázků určit 
> pomocí relativní cesty přímo pomocí atributu fileref.

No jednodušší to je, ale flexibilnější nikoliv vis výše.  Ale už ty
entityrefy nebudu dál zkoumat, tedy rozhodně ne v souvislosti s
obrázky.

> >Failed to load image: file:/home/radek/src/book/docbook/picture/
> >Failed to load image: file:/home/radek/src/book/docbook/picture/
> >Failed to load image: file:/home/radek/src/book/docbook/picture/
> >Failed to load image: file:/home/radek/src/book/docbook/picture/
> >
> >A ve výsledném html se objeví následující nesmyslný img tag.
> >
> ><img src="file:/home/radek/src/book/docbook/picture/" alt="Ten samý 
> >obrázek jinak">
> >
> >Použité xsl jsou snapshhot 2005-12-15 at 10:20 PST.  Unique ID for
> >this snapshot is E1Emxh2-0003DU-1z.  Saxon 6.5.3 a extensiony od p. Koska 
> >co mi osobně posílal.
> 
> Jak jsem psal, příčina problému je jasná, projevuje se pouze při použití 
> profilování, kdy se ztratí base URI dokumentu. Pro fileref odkazy je to 
> již opravené, pro entityref je tam ještě asi nějaká chyba. Zatím jsem 
> neměl čas to debugovat a opravit, ale mám to na to-do listu.

Ano o této příčině vím, a trpělivě čekám až ji opravíte.  Ale zde se
projevila další "chyba/vlastnost".  On totiž hlásí, že nemůže otevřít
soubor file:/home/radek/src/book/docbook/picture/, ale v xml ve
skutečnosti jsem se odkazoval na úplně jiný soubor a měl hledat
/home/radek/cache/book/docbook/picture.  Tu cestu si "vyvěštil" ze
symbolických linků, kterými jsem poskládal prostředí a on je
dereferencoval, čímž rozbil prostředí v kterém byl spuštěn a tím pádem
nemůže dosáhnout na žádné soubory neb ty jsou někde úplně jinde.
Matně se mi vybavuje, že by někde měl být přepínač nebo volba, kterými
se zakáže vyhodnocování symbolických linků (prostě chci aby se k
symbolickým linkům choval jako k adresářů nebo souborům).


> >http://www.sagehill.net/docbookxsl/GraphicsLocations.html#HtmlOutputDirectory
> >jsem pochopil, že se mají provést nějaké šachy s katalogy.  Ale
> >absolutně nechápu jaké.
> 
> Použijte fileref, a nemusíte dělat žádné šachy.

Ano, velmi záhy jsem dospěl k poznání, že použití entityref je
absolutně neprůchozí, už kvůli tomu že za těchto okolností dává do
html abolutní cesty.  Tím celý vegenerovaný web znehodnotí.

Atribut fileref má však vlastní problémy.  A tím je.  Co do něj mám
napsat.  XSLT systém potřebuje znát dvě hodnoty.  Cestu k souboru s
obrázkem v xml dokumenut a cestu k souboru s obrázkem v html
dokumentu.  Nicméně atribut je jen jeden a cesty rozdílné.

Např v XML dokumentu se odkáži na obrázek buďto:

1. pomocí fileref s absolutní cestou
fileref="/uplne/divna/absolutni/cesta/smerujici/k/pracovnimu/adresari/se/sestavenymi/obrazky/obrazek.png"
jenže v html by mělo být <img src="picture/obrazek.png" ....> a není.

2. nebo pomocí url s relativní cestou, kterou ovšem měří od teď přesně
nevím kterého dokumentu.  Ovšem stějně mám všechny xml dokumenty v
asresáři ./xml/, takže se odkazuji fileref="../picture/obrazek.png"
jenže v html by mělo byt <img src="picture/obrazek.png" ...> a je tam
zase něco jiného.

Zatím jsem dopěl k poznání že jediné možné řešení je mít stejné
relativní cesty, což by znamenalo přemístnit všechny picture adresáře
do jednoho ./xml/picture/ .  To mě ovšem přivádí na úplný začátek, neb
v ./xml/picture nemají co dělat generované obrázky.  A už vůbec ne
jakékoliv pobrázky neb je v tom pak strašný zmatek.

Struktura adresářů je asi taková
  projekt/        základní soubory, make, negenerované katalogy entit, skripty
  projekt/xml/    adresář se všemi xml kapitol, sekcí a taktéž kořenový xml
  projekt/db/     databáze ze kterých jsou vytvářeny xml soubory v pracovní části
  projekt/picture/  zdrojová data ze kterých jsou generovány obrázky 
  projekt/figure/   -||-
  projekt/example/  soubory s příklady
  projekt/session/  zdrojová data sezení

  work/           pracovní adresář, neznámo kde.  je vytvořen dynamicky
                  za běhu ale cesta k němu je známa jen přes
                  proměnnou.  (toto je problém, zatím to smolím tak že
                  vím kde ten adresář vznikne a cpu všude statické
                  odkazy) Snad to nějak ošetřím preprocesorem.

  work/  zde jsou rovněž všechny vygenerované xml, a vygenerované katalogy entit
  work/picture/  zde mají být vygenerované obrázky z /projekt/picture/
  work/figure/   -||-
  work/session/  xml soubory generované ze sezení.

Cílem je mít celou projekt/ adresářovou strukturu čistou a nezasaženou
generovanými meziprodukty.  Naopak work/ adresář je možno beztrestně
odstranit, neb je generovaný z projekt/

Přemýšlím nad několika cestami jak to řešit.  Ale nic jednoduchého mě
nanapadá (už mi to nemyslí).

Jednak zavedu dvouprůchodové zpracování, nejdřív profilaci a pak
transformaci.  Profilaci mám nastavenu, ale ještě jsem neopravil
transformační makra aby používaly vyprofilované dokumenty.  Musí se to
vyčistit a prověřit všechny proměnné kam ukazují, odladit.

Když to nepůjde jinak, skončím tak že ve work/ bude připravená celá
struktura tak jak to xslt vyhovuje a prostě tam ty věci nakopíruju.
Všechy transformace by se pak dělaly tam, baz jakýchkoli odkazů na
zdrojové soubory.  Teda ještě pořád doufám že to tak půjde udělat.

Dneska jsem už tak unavený že mi to ani nemyslí, takže snad zítra to
budu muset probrat celé znovu, jestli jsem něco nepřehlédl.

-- Radek Hnilica <Radek at Hnilica dot CZ>  http://www.hnilica.cz



Další informace o konferenci Docbook