xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 42144] - [PATCH] Safely set postscript page device dictionary, additional processing states for OffDocumentItems
Date Wed, 13 Jun 2007 14:23:22 GMT
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





------- Additional Comments From dev@cumiskey.com  2007-06-13 07:23 -------
(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.


-- 
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.

Mime
View raw message