Hi Craig, I'll address each of your suggestions inline:
<snip/> The reason I'm adapting fop-pdf-images to support "merging" PDF images > into the main PDF content instead of using XObject Forms is that the use > of lots of PDF XObject Forms seems to cause RIPs and clients to perform > poorly or run out of memory. The way I propose to do it, fop-pdf-images > will use an XObject form if the preloader sees a pdf image re-used more > than a configurable number of times (one by default), and otherwise > merge it into the main pdf. > How do you plan to make this configurable? From the fop.xconf? I think we may want to do either ALL XObjects or ALL overlaid pages, adding configurability here doesn't really add anything that I can see. <snip/> Unfortunately, fop doesn't do anything so consistent for fonts or most > other resources, and that's made it nearly impossible for me to > guarantee that I can use a name without a later part of the XSL-FO > causing fop to create an object that tries to use the same name. Solving > this will require some changes to the way fop writes the PDF resources > dictionary. > Presumably you're a talking about the PDFName which holds a reference to the Font (i.e. /Font << /F1 X 0 R >> - where X is the object number)? > I propose that the PDFResources class should take responsibilty for > allocating resource names and ensuring they're consistent. Instead of > asking each resource what its name is, the PDFResources class should > *assign* it a name. Those names can be minimal and compact - eg "Fnn" > for fonts, "GSnn" for graphics states, etc. "nn" would be a counter > maintained by PDFResources. That's the convention followed by most other > PDF producing software and would make it simple and reliable to inject > objects not created by fop into the resources dictionary without risk of > conflicts. > Again, by "font name" I presume you're meaning the one I describe above. If you are, then that's fine. If you're meaning the actual "/FontName" parameter within the "/FontDescriptor" then no, you can't do that. For the latter the PDF spec is quite clear about it's expectations having a tag prefix the font name and also, if you didn't already know, font subsets must have unique "/FontName" properties. By unique, I don't mean "unique" in the general sense; only that they must be unique within the document. Just something to be aware of. > This API change would only affect extensions, services and clients that > work directly with org.apache.fop.pdf. and > org.apache.fop.render.pdf. classes, and only some of those. Clients > that use the main fop APIs would be completely unaffected, as would > clients that use the area tree / IR code, image loader code, or pretty > much anything except the guts of pdf handling. > > I'll post a proposed patch soon, along with patches for some other > changes that enable what I'm doing but may be useful for others. A patch > with the fop-pdf-images "merge" feature support will follow once I've > finished it enough that I can do test-runs. > Excellent, I look forward to seeing your patch! Sorry it's taken so long to respond to this, but do let me know if you need any help. Mehdi
