xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Issues for after the IF branch merge
Date Wed, 18 Feb 2009 08:27:49 GMT
Hi Martin

On 18.02.2009 07:33:55 Martin Edge wrote:
> Hi Jeremias,
> Is this a IF XML structure change? Or merely the way it's being processed?

I'm not sure how much you picked up from the discussions so I'll start
at the beginning (just to be sure):

The "IF branch" introduces a completely new XML-based intermediate
formats for FOP. The old one (the Area Tree XML, the one you use) still
exists with no changes and will continue to be available. I know this
might create some confusion which is why I tried to make it especially
clear in the documentation how they stand to each other and which one
should be used in which case. Both have their use cases. I've updated
the documentation already but it's not live on the website as it's still
only found in the branch. However, you can read through the
documentation sources here:
(please don't look to closely at the name of the branch. It's misleading.)

We continue to use the Area Tree XML format as our primary format for
layout engine tests as it contains more information than the new one.

So in short: the old IF is renamed to "Area Tree XML" (with no changes
to it) and the new IF becomes our main "IF" (a completely new format
optimized for speed).

The API for working with it is a different one although similar to the
Area Tree XML format.

> I make changes to the IF prior to rendering my final document as I need to
> put information on each page generated and be aware of the total amount of
> pages rendered (a barcode as it was). 

These IF-related changes are 100% backwards-compatible. Don't worry. The
only thing that might require someone's attention is if someone has a
subclass of one of the deprecated Renderers.

But depending on what you're doing you might want to investigate if the
newly won performance (with the new IF) is actually something you could
profit from. Of course, that will mean some work for you because it's a
different format. But given the performance increase it might be worth

> When you say deprecate following implementations, do you mean the fact that
> the IF previously held some reference on what type of output the IF was
> created for?

What we discuss to deprecate are the Renderer implementation for PDF, PS,
AFP, PCL and TIFF, i.e. PDFRenderer, PSRenderer, AFPRenderer,
PCLRenderer and TIFFRenderer. These classes would be taken off the
service registration file or the RendererFactory class will simply let
the new IFDocumentHandler/IFPainter implementations take precedence if
they are available.

If you select the output format in code through its MIME type, you won't
notice the change. An example: if you select "application/postscript"
now, RendererFactory will instantiate an instance of PSRenderer. After
these changes, RendererFactory will create an IFRenderer instance which
will delegate to the new class PSDocumentHandler (and PSPainter).

> Where can I get more information on this change?

The original idea was developed on this Wiki page:

The updated documentation (as already mentioned above) can currently be
read from here:

I've also made performance measurements as part of this effort which
highlights why it was done in the first place:

I hope that clears up everything. If not, please don't hesitate to say
so. I'm actually very happy to see stakeholders speak up. The more
feedback there is the easier it is to make everyone happy (or as happy
as is possible).

> Thanks :-)
> Martin.
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
> Sent: Tuesday, February 17, 2009 3:12 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Issues for after the IF branch merge
> Follow-up issues for after the merge where I'd be glad for feedback:
> - The new implementations currently all use a MIME suffix ";mode=painter".
> They are now sufficiently tested that I'm confident that we can switch over
> to them by default. One idea would be to put a switch in RendererFactory so
> we can say: prefer IFDocumentHandler instead of Renderer implementation. Or
> rather the opposite: by default use the IFDocumentHandler but allow to
> switch to the old mode should there be an unexpected incompatibility. Good
> idea or bad?
> - Given the performance figures I think it would be possible to deprecate
> the following implementations: PDF, PS, PCL and AFP. As for the Java2D
> implementations: the PNG, Print and AWT Preview parts are not implemented,
> yet, so a deprecation here is premature. TXT is probably good enough like it
> is. No change necessary there. After all, we won't deprecate the Renderer
> interface itself. Good idea or bad?
> - A note primarily for Max: For JEuclid to work with the new
> implementations, it will require an ImageConverter implementation (from XML
> Graphics Commons' image loading framework). I haven't investigated how hard
> it would be to provide a compatibility layer so the old implementations
> could be used. The old stuff is in many parts tied into the Renderer
> architecture. For Barcode4J, I've written such an implementation already. I
> can also try to find time to do it for you, if you like. The good thing is
> that the ImageConverter implementation is not FOP-specific but can also be
> used by anyone using the image loading framework. Actually, that part might
> influence the decision for the first and second points above!
> Jeremias Maerki

Jeremias Maerki

View raw message