DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42144>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42144 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 2007-05-30 12:49 ------- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
