I talked on the last post about the problems in using directly SVG in the current status of affair. I wanted to continue using these standard technologies (DocBook and SVGs to produce PDF and XHTML through XSLT stylesheets and FO processors), but I had to circumvent somehow the problems. Here’s the solution I found.

My problem is I can’t use directly SVGs. So, at last I concluded that the practical solution is to produce two PNGs of different resolution for the PDF and XHTML output. But then I considered the fact that I didn’t want to make things manually: I wanted to continue making the document as if the problem wasn’t there, so that, once the situation will be stable, I have to do nothing but to remove the additional infrastructure I’m putting in. So, for the making of the PNG versions I simply had to expand the Makefile I already had:


# variables for SVG to PNG conversion
SVGS := $(wildcard *.svg)
LOWRES_PNGS := $(SVGS:.svg=_lowres.png)
HIRES_PNGS := $(SVGS:.svg=_hires.png)


[…]

# SVG to PNG handling
corso_reworked.xml: corso.xml imageprocessing.xsl
xsltproc imageprocessing.xsl corso.xml > corso_reworked.xml

%_lowres.png: %.svg
inkscape --file=$< --export-png=$@

%_hires.png: %.svg
inkscape --file=$< --export-dpi=300 --export-png=$@


This code simply takes all SVGs it can find, and make a low and hi res versions (for example, from stack_tcp_ip.svg generate stack_tcp_ip_hires.png and stack_tcp_ip_lowres.png).

This was the easy part. But how could I modify the docbook? Very simple: being XML, I simply had to write one more XSLT that made conversions for me. To be exact, the change is from something like this:


<mediaobject id="StackTCPIP">
  <imageobject>
    <imagedata
      fileref="stack_tcp_ip.svg"
      format="SVG"
      align="center"/>
  </imageobject>
</mediaobject>


To something like that:


<mediaobject id="StackTCPIP">
  <imageobject role="fo">
    <imagedata
      fileref="stack_tcp_ip_hires.png"
      format="PNG"
      align="center"/>
  </imageobject>
  <imageobject role="xhtml">
    <imagedata
      fileref="stack_tcp_ip_lowres.png"
      format="PNG"
      align="center"/>
  </imageobject>
</mediaobject>


That is, the imageobject is duplicated with different roles, and the imagedata are changed to accomodate the PNG version. At the end, all the work is made automatically and, again, in a standard way. The two files that make all the work are thus this Makefile (the one I’m using for producing the documents) and the SVG to PNG stylesheet. The second one I tried to make the most flexible, so that it works on various situations.

Posted by mattia as docbook, fo, make, pdf, png, svg, xhtml, xslt at 1:45 AM CEST

No Comments »

It’s so nice to have standards. DocBook is one which is good enough for many uses. E.g., the notes for the linux system and network administration course I’m writing which I mentioned about some posts ago.

So, tell me why if you ask for an SVG image to be right aligned, 5cm wide and to scale height appropriately, the results with, respectively, the Norman Walsh XHTML XSL stylesheets and his same FO stylesheets and FOP, are the following:

The code was:

<imagedata
width=”5cm”
align=”right”
fileref=”stack_tcp_ip.svg”
format=”SVG”
scalefit=”1″/>

I know, I ask much, since I involved SVG, DocBook, XHTML, XSL and PDF all in a single cauldron, but… damn, they are ALL standards! :-P

– 2:15 update

I tried for a while to make things fit well, and they didn’t. So, I chose to make conversion to PNG beforehand. This worked well for HTML version, but gave very ugly results in PDF, which uses higher DPI. So I renounced to a single format, and gave double specification of images in the docbook (why have I used a vectorial format, then…). I tried to include PDF in PDF version, but FOP crashes on it (isn’t able to get information from PDF; the comic thing is that he says in turn: “Content is not allowed in prolog”, “Error while recovering image information” and “GRAVE: Image not available” - a perfect case of exception misunderstanding). So I chose for double version PNG (a 90dpi and a 600dpi one), and this way it worked. Almost. In the XHTML version, the “right” alignment is interpreted as a float, in the PDF, as a normal align. Well, I can’t have everything. All in all, I had to make some four trials, which should have all worked, and instead only one did. *GROWL*.

Posted by mattia as docbook, fo, fop, html, image, svg, xhtml, xml, xsl at 9:35 PM CEST

1 Comment »

When Zope parses text/html elements, instead of XML (xhtml and the like) uses a different parser. That is, not an XML parser, but rather an HTML parser like the ones used by browser, more relaxed, which allows for unclosed tags and the liks.

BUT…

there’s always a but. In HTML, technically speaking, not all combinations of tags are allowed, even if browsers permit it. E.g., a span cannot contain a div. So, zope too complains about this fact. But how does it complain?

Page Template Diagnostics
Compilation failed
zope.tal.htmltalparser.NestingError: Open tags <html>, <body>, <div>, <div>
do not match close tag </span>, at line 105, column 5

Now, please, tell me, why the fuck you told me about not matching tags when the problem is that the document in not valid against given DTD?!?! So, I lost a whole afternoon after this wrong error message, before been enlightened by the documentation. For sure, I didn’t mind looking at it, since the error message did state quite clearly what the problem was.

One more notes about designing programs in the future. Tell a lots of things when an error come out but, above all, tell the REAL error, not some approximate, wrong information. This is much worse that a laconic error message.

Posted by mattia as html, xhtml, zpt at 10:47 AM CEST

No Comments »

You know that there will never exist a single language to control everything when you start writing stuff like this:

<body tal:attributes=”onload python:’javascript:fill_form(%d);;’ % p[’uid’]”>

I mean, four programming/markup languages in one row it’s quite the best I’ve succeeded in for something meaningful.

(for the curious, I’m talking about markup XHTML, markup/programming TAL, programming python and javascript, or better ECMAScript).

Posted by mattia as ecmascript, python, xhtml, zpt at 9:26 PM CEST

No Comments »