If you take on page-number-citation-last, that's fine with me. It's a
very good addition to the page-position="last" feature I managed to
implement this week. The SVGRenderer is actually about the SVG rendering
backend (producing SVG), not anything about external-graphic (consuming
SVG). The SVGRenderer can be implemented in two different ways:
1. As it currently is, i.e. the Renderer implementation directly creates
the necessary SVG elements.
2. Using Batik's SVGGraphics2D (see )
The second way much less work because you can mostly reuse existing
components like the Java2DRenderer (which knows how to render to a
Graphics2D instance like SVGGraphics2D provides it. The existing
SVGRenderer is in the src/sandbox directory where it will remain until
it's usable again. The only complication I can imagine is about handling
the slide feature, i.e. putting multiple pages into one SVG file, since
by default, SVG only supports one page. Using the guidelines from SVG
Print  could also be an option.
If you need any help or guidance, just ask.
On 25.03.2006 13:38:19 Pierre-Henri Kraus wrote:
> My name is Pierre-Henri Kraus and i'm a student at the University of
> Liège (ULG) in Belgium.
> I'm currently in the last year to be a bachelor in computing (5 years
> studies type), and i have to do an "end of study work", and mine
> consists of helping an open-source XSL-FO processor developpement team.
> After a preliminary analysis, i've chosen FOP, which proved to be the
> most advanced and "living".
> I've had a talk with Jeremias, and with my supervising teacher too, and
> among the points worth looking at, we decided that i would work on
> page-number-citation-last from XSL 1.1 (if that's ok for you), and/or
> eventually, on reviving SVGRenderer if you can confirm me that it's
> about taking a SVG file as input for a fo:graphic element (by opposition
> to the SVG rendering backend).