[PATCH] - PDF/PSTranscoder Fix, ImageElement Bridge

[Thomas DeWeese <Th...@Kodak.com>]

Hi all,

    I've attached two patches for your consideration.

The first patch (pdfTranscoder.patch) fixes a bug[1] in the handling
of the viewbox for the PDF (and I suspect PS[2]) transcoders.  The patch
changes the baseclass for AbstractFOPTranscoder from XMLAbStractTranscoder to
SVGAbstractTranscoder.  The patch needs the latest CVS build of
Batik to work as I moved the creation of the BridgeContext into
a method that these classes can override in order to install their
custom bridges.

    This change allows almost all of the SVG specific code to be
removed from FOP and live in the SVGAbstractTranscoder baseclass.
This also enables the '-onload' switch for PDF output, and the ability to
transcode from Documents that are not from the Batik DOM (the
baseclass clones them automatically).

    The second patch (pdfImage.patch) 'reinstates' the direct embedding
of JPEG date streams. It takes care to only do this in appropriate cases
(JPEG drawn directly to the PDFGraphics without a filter or what ever).
In other cases it falls back to drawing the raster.  I've done a moderate
amount of testing and it seems to perform well.

    These two patches are almost totally independent - the only
overlap is in the build.xml file where I added the new files
for both when building the fop-transcoder-all.jar

    One other issue - It seems that the the PDFDocumentGraphics is
acquiring new dependencies 'scattered' around FOP (apps.Document,
area.AreaTreeControl, fo/FOTreeControl, ...).  Currently these
aren't problematic as they don't seem to reach 'deep' into the
other parts of FOP but it seems like it is a serious problem
waiting to happen (I may be wrong on this and it may be clear to
everyone in the FOP development community that these classes
shouldn't/can't have deep dependencies).

---

[1] It appeared to me that the viewbox transform was being applied
twice to the content, so it was generally scaled larger than it should
have been - leading to it being clipped on the right/bottom edges.

[2] It wasn't clear how to run the PSTranscoder, the changes are
_identical_ to those in the PDF transcoder (so much so I would
encourage you to move most of the code from 'transcode' up into the
AbstractFOPTranscoder).

RE: [PATCH] - PDF/PSTranscoder Fix, ImageElement Bridge

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> If you'd like me to handle the patches, let me know--I
> should be able to get to them this weekend.

Yes, please. I don't have enough bandwidth to get up to speed on Batik right
now.

> --- Victor Mote <vi...@outfitr.com> wrote:
> > 2. fo.FOTreeControl
> <snip/>
> > Its purpose is to allow the
> > FOTree to be independent
> > of the apps classes that control it.
>
> > 3. area.AreaTreeControl
> <snip/>
> > its purpose is to allow the AreaTree to be
> > independent of the apps
> > classes that control it.
>
> Nice design--I'm beginning to see the light! ;-)

That is the best news I've had all day!

Victor Mote

RE: [PATCH] - PDF/PSTranscoder Fix, ImageElement Bridge

[Glen Mazza <gr...@yahoo.com>]

I think one of Tom's concerns is keeping the
transcoder stuff modular enough so that it potentially
can be moved to the Batik team.  But as you're
mentioning, separating the font information is not
that big a deal and can be postponed until the font
handling designs are finished in trunk.  

If you'd like me to handle the patches, let me know--I
should be able to get to them this weekend.

Glen

--- Victor Mote <vi...@outfitr.com> wrote:
> 2. fo.FOTreeControl 
<snip/>
> Its purpose is to allow the
> FOTree to be independent
> of the apps classes that control it.

> 3. area.AreaTreeControl 
<snip/>
> its purpose is to allow the AreaTree to be
> independent of the apps
> classes that control it.

Nice design--I'm beginning to see the light! ;-)

Glen

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

RE: [PATCH] - PDF/PSTranscoder Fix, ImageElement Bridge

[Victor Mote <vi...@outfitr.com>]

Thomas DeWeese wrote:

>     One other issue - It seems that the the PDFDocumentGraphics is
> acquiring new dependencies 'scattered' around FOP (apps.Document,
> area.AreaTreeControl, fo/FOTreeControl, ...).  Currently these
> aren't problematic as they don't seem to reach 'deep' into the
> other parts of FOP but it seems like it is a serious problem
> waiting to happen (I may be wrong on this and it may be clear to
> everyone in the FOP development community that these classes
> shouldn't/can't have deep dependencies).

I'm the culprit here. First, WRT to the types mentioned, the changes that
you have noticed are my attempt make FOP more modular, to separate parsing,
FOTree, layout, AreaTree, and rendering into discrete modules, with the
specific purpose of allowing layout to be pluggable.
1. apps.Document used to be one of the fontInfo classes, which primarily
stored a collection of fonts used by a FOP Document. It has an expanded role
now.
2. fo.FOTreeControl is an interface that will only be implemented (within
FOP) by apps.Document. Its purpose is to allow the FOTree to be independent
of the apps classes that control it.
3. area.AreaTreeControl performs a function similar to the FOTreeControl for
the AreaTree, i.e., it is only implemented (within FOP) by apps.Document,
and its purpose is to allow the AreaTree to be independent of the apps
classes that control it.

Before I dive into this, I want to make sure I'm looking at the right issue.
Are you referring to 1) a Batik class by the name of PDFDocumentGraphics, 2)
the FOP class svg.PDFDocumentGraphics2D, or 3) something else? Assuming for
the moment that you are referring to #2, then a couple of solutions come to
mind:
1. probably the best solution is for me to spin the font portion of what is
now the Document class back into a separate class that handles only font
collections.
2. another alternative would be to have PDFDocumentGraphics2D keep its own
collection of fonts used.

I knew that there was some work that needed to be done in
PDFDocumentGraphics2D WRT to this issue, but had hoped to defer it until I
get to some planned font refactoring work. AFAIR, only Document and
PDFDocumentGraphics2D used the FontInfo collection object, so I had (and
still have) an open issue in my mind about how the font collection was being
used in PDFDocumentGraphics2D -- i.e. whether the fonts used there should be
managed as part of the collection that goes with the FOP document, or
whether it really needed an independent collection. Under the old scheme the
FontInfo collection had to be passed around in method signatures, and I had
thought it possible that PDFDocumentGraphics2D might have just created a new
instance because of that inconvenience. So, if the fonts used by
PDFDocumentGraphics2D can/should be commingled with those used in the rest
of the FOP Document, probably the status quo is good, except that I need to
get the Document instance to PDFDocumentGraphics2D instead of having it
instantiate a new one. OTOH, if they need to remain separate, then I should
probably pursue one of the two solutions mentioned above.

Victor Mote