Re: [xmlroff] instream-foreign-object SVG?

[Tony G. <Ton...@Su...>]

Julian Rosse <gn...@th...> writes:
>   What are your thoughts on supporting SVG instream-foreign-objects?  I have

I'm in favour of it.  FOP, for example, does it.

I'd like to get external-graphic working again (and working the
"correct" way from my other mail of today) first.

> been thinking that would be a cool longer-term goal, and an itch that I'd
> eventually like to scratch.  I was doing a bit of reading - there's this
> librsvg associated with GNOME which dumps GdkPixBufs; when I googled svg to

xmlroff uses Pango to lay out blocks of text.

fo:external-graphic and fo:instream-foreign-object are both "inline"
formatting objects in that they "generate and return" inline areas.

The technique that I want to continue using for fo:external-graphic is
to tell Pango the size of the graphic (using Pango's standard
"PangoAttrShape" ) and provide a callback (using PangoXSL's
non-standard and currently no longer implemented "callback" attribute)
for doing the rendering of the graphic.

As it used to work in PangoPDF, when Pango (actually PangoPDF at the
time) renders the run containing the shape and callback attributes,
the processing for the callback attribute places the "current point"
of the rendering context at the top-left corner (at a known corner,
anyway) and calls the callback.  The code in the callback does the
work of writing the image to the rendering context.  In PangoPDF, it
used the PDFlib functions for writing images to the PDF output.  When
re-implemented for GNOME Print, it will use the GNOME Print functions
for writing images to the output.

Given that, there isn't much difference between an external-graphic
and an SVG instream-foreign-object if you have a library that can
covert the SVG into a format that can be passed to a rendering
function as part of the callback processing.

> postscript, I found a discussion on an XSL-FO mailing list about the subject
> which you were part of (you mentioned xslfo-proc -> now dandy - I couldn't
> really tell what its deal is from its website) - but you guys seemed to be
> saying "hmm that should be pretty easy but is there such a tool?" or "maybe
> people will start using SVG as a page description language instead of PS or
> PDF".

As I remember it, xslfo-proc (or xslfoproc) was going to use SVG as
its hub output format from which would be produced other formats such
as PDF.

I don't follow SVG very much, but I believe that a recent version has
made it much easier to write a sequence of SVG pages.  When I first
looked at SVG, an SVG document was one image and if you wanted a
sequence of page images, you'd have had to invent your own element to
wrap a sequence of SVG elements.

>   I'm sure you have ideas about the subject - what are they?  I'm not trying

I have a few...

There's at least four ways to hook SVG and XSL FO together:

 - Use SVG as an instream-foreign-object format, as you've discussed.

 - Use SVG as an output format or the output format from the formatter.

 - Use SVG (or something based on SVG) as the hub output format from
   which are produced other output formats.

 - Use SVG (or something based on SVG) as the internal area tree
   format/model.

That last one always sounds intriguing at first, but in xmlroff, most
of the properties that you'd think of as being in an SVG-like model --
such as font sizes, colours, etc. -- only ever exist in the FO tree
and are copied from the FO tree only when writing the output to a
file.

SVG as an output format would be interesting, and I have sometimes
thought of writing a Pango backend (or are they Pango renderers these
days?) for SVG if I had infinite time to spare.

You could do something SVG-like as an area tree output format that
could be written out and read back in to recreate area trees, but I've
never found a convincing reason to do that.  I find that the
line-based format from "xmlroff -d4" is usually sufficient for
debugging areas and is probably easier to read than if it were XML.
If xmlroff develops to the point of needing to serialize layouts or
even pages to free up memory when processing large documents, then
you'd pick a format that's quick to write out and quick to read back
in, and I don't know that that would be SVG or even XML since we're
not talking interchange at that point.

> to jump into a huge undertaking after just submitting a couple patches - just
> getting excited about a possible longer term goal.  Would an SVG "rendering"
> library on top of gnome-print make any sense?  BTW I still have little to no

You'd hope that someone in the GNOME ecosystem has written something
that can read in SVG and drive gnome-print from it.

> idea what I'm talking about regarding most of these things - so feel free to
> tell me I'm being stupid.

You're not being stupid.

I have asked that you finish off the border properties, but you are
welcome to work on the graphics problem if you want.  This is
voluntary open-source development on your part (and mine, these days)
which means you get to scratch where you have itches.

Regards,


Tony.