New IF: Some thoughts...

[Jeremias Maerki <de...@jeremias-maerki.ch>]

You've all noticed by now that I'm working intensively on the new IF.
Testing with documents only involving text and rectangles (i.e. what is
implemented right now), the new IF is almost twice as fast as the plain
area tree XML format. So I assume the goals for the new IF can probably
be met. It looks like the output format implementations really get
smaller, faster to implement and more readable. My only worry point is
handling advanced borders in a format-independent way. But it should all
be solvable.

I'm also building the SVG (1.1 and 1.2 Print WD) painter next to the
IFSerializer to see whether a subset of SVG might actually be used as
our new intermediate format. However, I don't see that SVG is the right
way because it would mean defining all sorts of extensions to handle all
the additional things needed for the IF. The SVG needs more hierarchy 
(SVG g tags) for getting paint state right (verbosity). The stronger mix
of namespaces might make the thing slower, too. If course, we will also
mix namespaces in the new IF but only at defined points for FOP
extensions. Finally, there are currently no SVG Print implementation
that I know of. Because we need SVG Print's page and pageSet feature we
couldn't preview the file anyway with external tools. Firefow, Inkscape
and Batik won't display the SVG Print file.

Some additional thoughts while going forward...

I think I'd like to split the IFPainter interface in two. Our Renderer
interface is already much too big causing big subclasses with many
methods. If I put everything in the IFPainter interface something
similar will happen here, too. The obvious split-point IMO is the
page. The IFDocumentHandler would deal with setting up the document and
handling page-sequences. The IFPagePainter would deal with single pages.
Formats like PNG, Mars and XPS generate a new file per page inside their
ZIP containers. PDF, AFP and PostScript also have distinct objects for
pages. So I think that makes sense. Please chime in if you don't agree
or if you have better names for the interfaces.

You may have seen my recent addition to the Wiki page about resource
management. This is only an idea at the moment. Basically, it's about an
optimization for formats like PS and AFP (avoids a two-pass approach
when generating a resource-optimized print file).

Thoughts and opinions welcome.

Jeremias Maerki

Re: New IF: Some thoughts...

[Jeremias Maerki <de...@jeremias-maerki.ch>]

After dealing with viewports and block-containers, I've now moved over
to handling images. There I realize how much this whole thing is tied to
the Renderer interface. The RendererContext is omni-present which
references Renderer. Looks like I undererstimated a bit how much work it
will be to untangle the various interfaces and classes so I can reuse
code for both the old renderers and the new painters while maintaining
compatibility for external extensions and not introducing too many new
class/interface names which only produce more confusion and complexity.
I also want to avoid deprecating too much because that won't help code
readability either.

In a way, throwing away the renderer while writing the new painter would
almost be the cleanest approach but also a dangerous one since I'm still
not 100% sure that I've already thought about every single aspect
(present and future) of what FOP needs to be able to do (plain rendering,
extensions, accessibility features, performance etc. etc.). For the new
SVG painter, this whole thing is very easy since you can start on the
green field. For the PDF painter, I probably need to start by
generalizing the PDFImageAdapters (i.e. making them independent of the
PDFRenderer). The image classes from the XGC image loading framework
should make a good anchor point to get to a better general approach that
will work for all renderers. At the end the whole thing should probably
result in an abstract model that describes how we should generally do
image handling at the rendering stage for all output formats. Back to
pen and paper...

On 25.07.2008 10:52:38 Jeremias Maerki wrote:
> You've all noticed by now that I'm working intensively on the new IF.
> Testing with documents only involving text and rectangles (i.e. what is
> implemented right now), the new IF is almost twice as fast as the plain
> area tree XML format. So I assume the goals for the new IF can probably
> be met. It looks like the output format implementations really get
> smaller, faster to implement and more readable. My only worry point is
> handling advanced borders in a format-independent way. But it should all
> be solvable.
> 
> I'm also building the SVG (1.1 and 1.2 Print WD) painter next to the
> IFSerializer to see whether a subset of SVG might actually be used as
> our new intermediate format. However, I don't see that SVG is the right
> way because it would mean defining all sorts of extensions to handle all
> the additional things needed for the IF. The SVG needs more hierarchy 
> (SVG g tags) for getting paint state right (verbosity). The stronger mix
> of namespaces might make the thing slower, too. If course, we will also
> mix namespaces in the new IF but only at defined points for FOP
> extensions. Finally, there are currently no SVG Print implementation
> that I know of. Because we need SVG Print's page and pageSet feature we
> couldn't preview the file anyway with external tools. Firefow, Inkscape
> and Batik won't display the SVG Print file.
> 
> Some additional thoughts while going forward...
> 
> I think I'd like to split the IFPainter interface in two. Our Renderer
> interface is already much too big causing big subclasses with many
> methods. If I put everything in the IFPainter interface something
> similar will happen here, too. The obvious split-point IMO is the
> page. The IFDocumentHandler would deal with setting up the document and
> handling page-sequences. The IFPagePainter would deal with single pages.
> Formats like PNG, Mars and XPS generate a new file per page inside their
> ZIP containers. PDF, AFP and PostScript also have distinct objects for
> pages. So I think that makes sense. Please chime in if you don't agree
> or if you have better names for the interfaces.
> 
> You may have seen my recent addition to the Wiki page about resource
> management. This is only an idea at the moment. Basically, it's about an
> optimization for formats like PS and AFP (avoids a two-pass approach
> when generating a resource-optimized print file).
> 
> Thoughts and opinions welcome.
> 
> Jeremias Maerki
> 




Jeremias Maerki