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
