Weblog Tomasza Przechlewskiego

SVG, Docbook i Firefox

Zaczęło się od tego, że chciałem wstawić ilustrację w formacie SVG do dokumentu redagowanego w Docbooku. Jakoś tak:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
  
]]>

W pliku PDF wygenerowanym FOPem ilustracja wygląda OK. W dokumencie HTML oglądanym w FF 2.0.0.16 wygląda dziwnie: wyświetlany jest tylko fragment rysunku a z boku pojawia się pasek do przewijania (scrollbar). I nie idzie tego się pozbyć...

Zaktualizowałem zatem Firefoxa do wersji 3.0.3. Teraz rysunek jest wyświetlany prawidłowo. Opera 9.27 nie pokazuje go wcale, ale jeżeli pominie się atrybut width, to rysunek jest wyświetlany prawidłowo. Skoro tak to wymyśliłem sobie coś takiego:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
    Na wypadek gdyby powyższy rysunek
był niewidoczny tu jest wersja w formacie PNG 
    
  
]]>

Powyższa uwaga w pliku PDF jest bez sensu. Na szczęście łatwo się go pozbyć, bo w Docbooku zaimplementowano warunkowe przetwarzanie dokumentu (profiling). Następujące kilkanaście atrybutów może być używanych do tego celu:

Nazwa atrybutu	Opis	Parameter XSL
arch	Computer or chip architecture, such as i386.	profile.arch
audience	Intended audience of the content, such as instructor.	profile.audience
condition	General purpose conditional attribute, with no preassigned semantics.	profile.condition
conformance	Standards conformance, such as lsb (Linux Standards Base).	profile.conformance
lang	Language code, such as de_DE.	profile.lang
os	Operating system.	profile.os
revision	Editorial revision, such as v2.1.	profile.revision
revisionflag	Revision status of the element, such as changed. This attribute has a fixed set of values to choose from.	profile.revisionflag
role	General purpose attribute, with no preassigned semantics. Use with caution for profiling.	profile.role
security	Security level, such as high.	profile.security
status	Editorial or publication status, such as InDevelopment or draft.	profile.status
userlevel	Level of user experience, such as beginner.	profile.userlevel
vendor	Product vendor, such as apache.	profile.vendor
wordsize	Word size (width in bits) of the computer architecture, such as 64bit. Added in DocBook version 4.4.	profile.wordsize

Teraz po wpisaniu ... ]]> do dokumentu należy uruchomić procesor XSLT z odpowiednią wartością parametru (podanego w trzeciej kolumnie tabeli). Mówiąc konkretnie:

## Transformacja za pomocą xsltproc xml2xhtml
xsltproc --stringparam chunker.output.doctype-public "-//W3C//DTD XHTML 1.0 Strict//EN" \
     --stringparam chunker.output.doctype-system http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" \
     --stringparam profile.condition "html" -o plik.xhtml szablon.xsl plik.xml

## albo za pomocą procesora saxon:
saxon -o plik.fo plik.xml szablon.xsl profile.condition="pdf"

Do tego zamiast standardowego arkusza XSL-ROOT/xhtml/chunk.xsl (XSL-ROOT oznacza katalog główny dystrybucji arkuszy XSL Docbook) należy w przypadku zamiany na XHTML uruchomić XSL-ROOT/xhtml/profile-chunk.xsl. Podobnie zamieniając XML na FO/PDF należy uruchomić XSL-ROOT/fo/profile-docbook.xsl zamiast XSL-ROOT/fo/docbook.xsl. Oczywiście ww. arkusze są uruchamiane pośrednio, poprzez arkusz dopasowujący nastawy XSL Docbook do moich potrzeb. Początek tego arkusza wygląda zatem następująco:

]]>

Teraz jest tak: plik PDF jest OK. Plik XHTML nie do końca--nie widać wpisu Na wypadek gdyby powyższy rysunek.... Zasłania go rysunek; co ciekawe identycznie wygląda to w Firefoksie i Operze (tzn. identycznie nic nie widać). Relewantny fragment pliku XHTML wygląda następująco:

Rysunek 1. Osie (środkowy węzeł p jest węzłem kontekstowym)