See http://wiki.apache.org/xmlgraphics-fop/ExtensionsForPostScript for details of the new extensions I have added. This patch should also includes :- * Some performance improvements in page rendition so postscript page setup is cached and reused for pages that use the same simple-page-master. * Changes to org.apache.fop.area.OffDocumentItem, org.apache.fop.area.RenderPagesModel with the addition of some new off document item "when to process" states: BEFORE_PAGE, BEFORE_PAGE_SEQ, AFTER_PAGE_SEQ for org.apache.fop.area.OffDocumentItem. * Changes to org.apache.fop.area.AreaTreeHander so extension attachments declared as children of simple page master are handled BEFORE_PAGE_SEQ on renderer. * Changes to org.apache.fop.area.OffDocumentExtension so whenToProcess can be set. * A new protected accessor method called getPSGenerator on org.apache.fop.ps.PSRenderer that should make it a little easier to customize resolving. * Added extension attachments to base org.apache.fop.area.AreaTreeObject class Please try the patch out, as always feedback is welcome :-). Adrian Cumiskey.
Created attachment 19978 [details] list of files
Created attachment 19979 [details] patch file
Thanks for the patch. It will take a little time until I can look into it in detail. One thing caught my eye: Why do you define an extension element to set the document title? There's a "title" value in the FOUserAgent you can use. I'd prefer if we reused existing functionality if possible, especially in cases where different output formats support the same things. Of course, you obviously want to set the title through the FO document. IMO, this should be done through XMP metadata. The PDFRenderer already listens to the XMP metadata object and populates its Info object accordingly. The PSRenderer could easily do the same. The FO would look like this: [..] <fo:declarations> <x:xmpmeta xmlns:x="adobe:ns:meta/"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title>My document title</dc:title> </rdf:Description> </rdf:RDF> </x:xmpmeta> </fo:declarations> [..] Granted, this is a little more complicated than your approach but it's based on a standard and there would be no special facility just for PostScript. More later when I've had time to look into the details.
I think I may have misunderstood the requirement for the title implementation. Jeremias, Don't waste too much time looking at this patch right now. I will try and resubmit an amended patch sometime tomorrow. Adrian.
Created attachment 20058 [details] patch file Revised patch, see http://wiki.apache.org/xmlgraphics-fop/ExtensionsForPostScript
Created attachment 20059 [details] list of files
Created attachment 20273 [details] patch file Checkstyled, improved javadocs, refactored in parts.
Created attachment 20274 [details] list of files
Adrian, I've looked into this patch today. I've found several issues I'd like adressed: - getPSGenerator() should probably be renamed to createPSGenerator(). A "get" is a little misleading. After all, the method creates a new PSGenerator instance. - In several places you create an anonymous inner class just to fill some values in a PSArray, for example. Please note that while the source code might look elegant, each of these constructs is creating an additional .class file with at least 1KB in size while a normal variable access would only generate a few byte code instructions. - super.init() is missing in PSPageDeviceDictionary. This resulted in a NullPointerException in my tests since those makers weren't initialized. - The PostScript output caused errors in GhostScript/GhostView when I used the setpagedevice functionality. Haven't investigated further. I'll attach the file I tested with. Part of the content is copied from the example in the documentation you wrote. - I'd like the setpagedevice code to be an optional feature not normally generated, since setpagedevice is usually device-specific. I usually post-process PostScript to add media management so I wouldn't want to have to remove it. It would be great if it were only activated if any ps-setpage-device extension is used. - You wrote that the patch contains a performance improvement concerning the page setup. Is that a performance improvement in terms of processing speed inside a PostScript engine? I'm asking because I don't see how the Renderer code would be any/considerably faster like you propose. In the existing code there are no time-consuming operations involved around the page setup that I can see (although I didn't do any measurements). At any rate, I found out that the name of the simple page master is not correctly generated for each page if you have different page masters in your page-sequence-master. See my test file.
Created attachment 20292 [details] Test FO showing the problems described earlier
(In reply to comment #9) > Adrian, I've looked into this patch today. I've found several issues I'd like > adressed: > - getPSGenerator() should probably be renamed to createPSGenerator(). A "get" is > a little misleading. After all, the method creates a new PSGenerator instance. I have renamed this method as you suggested. > - In several places you create an anonymous inner class just to fill some values > in a PSArray, for example. Please note that while the source code might look > elegant, each of these constructs is creating an additional .class file with at > least 1KB in size while a normal variable access would only generate a few byte > code instructions. I have refactored/simplified the code so there are a lot less classes to encapsulate postscript dictionaries and their related components. > - super.init() is missing in PSPageDeviceDictionary. This resulted in a > NullPointerException in my tests since those makers weren't initialized. This is fixed as a result of the simplification work. > - The PostScript output caused errors in GhostScript/GhostView when I used the > setpagedevice functionality. Haven't investigated further. I'll attach the file > I tested with. Part of the content is copied from the example in the > documentation you wrote. I'm not sure what happened here, I wasn't able to reproduce this. This new code produces no such errors in my unix ghost script interpreter. > - I'd like the setpagedevice code to be an optional feature not normally > generated, since setpagedevice is usually device-specific. I usually > post-process PostScript to add media management so I wouldn't want to have to > remove it. It would be great if it were only activated if any ps-setpage-device > extension is used. It is only activated when the extension is used. But it makes sense for the postscript renderer to make SPD postscript function calls instead of direct setpagedevice calls. It is more "safe" this way (i.e. an init-graphics call as a result of a setpagedevice will not be made if the contents of the page device dictionary has not changed). See section ps:ps-setpagedevice in http://wiki.apache.org/xmlgraphics-fop/ExtensionsForPostScript > - You wrote that the patch contains a performance improvement concerning the > page setup. Is that a performance improvement in terms of processing speed > inside a PostScript engine? I'm asking because I don't see how the Renderer code > would be any/considerably faster like you propose. In the existing code there > are no time-consuming operations involved around the page setup that I can see > (although I didn't do any measurements). At any rate, I found out that the name > of the simple page master is not correctly generated for each page if you have > different page masters in your page-sequence-master. See my test file. The idea was to improve the performance of the postscript renderer so it would reuse the page master layout information for pages using the same page master. I'm not sure it was worth the trouble so I have just removed this code. I have now included the test file you provided as a unit test. Adrian.
Created attachment 20340 [details] patch file
Created attachment 20341 [details] list of files
Adrian, thanks for the updated patch. Unfortunately, it seems to be incomplete. The class PSDictionary is missing and it doesn't seem to be expected in the objects package like with the previous patch.
Created attachment 20399 [details] patch file Updated patch with missing files (in my haste I forgot to add them to subversion before creating the diff).
Created attachment 20400 [details] list of files
Greatly reduced the dictionary object, hence the objects package now removed.
Created attachment 20621 [details] patch file This patch depends upon the new safe set page device postscript macro being applied to XmlGraphicsCommons (see http://issues.apache.org/bugzilla/show_bug.cgi?id=43069). * Adds new <ps:ps-setpagedevice/> extension to the postscript renderer (see http://wiki.apache.org/xmlgraphics-fop/ExtensionsForPostScript for details). * Adds safe-set-page-device and dsc-compliant configurations options. The default value for the "safe-set-page-device" setting is "false". Setting it to "true" will cause the renderer to invoke a postscript macro which guards against the possibility of invalid/unsupported postscript key/values being issued to the implementing postscript page device. The default value for the "dsc-compliant" setting is "true". Setting it to "false" will break DSC compliance by minimizing the number of setpagedevice calls in the postscript document output. This feature may be useful when unwanted blank pages are experienced in your postscript output. This problem is caused by the particular postscript implementation issuing unwanted postscript subsystem initgraphics/erasepage calls on each setpagedevice call.
I've done some testing with your patch Adrian and it appears to work very well. None of the previous problems reported by Jeremias showed up. I was able to print Postscript and view in GhostView with all 4 combinations of the new options that you've added. So I have committed the patch. Thanks!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed