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