Bug 48797 - [PATCH] Optimize EPS and PS file size
Summary: [PATCH] Optimize EPS and PS file size
Status: RESOLVED FIXED
Alias: None
Product: XMLGraphicsCommons - Now in Jira
Classification: Unclassified
Component: postscript (show other bugs)
Version: Trunk
Hardware: PC Linux
: P2 enhancement with 1 vote (vote)
Target Milestone: --
Assignee: XML Graphics Project Mailing List
URL: http://mail-archives.apache.org/mod_m...
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2010-02-22 18:35 UTC by Calixte Denizet
Modified: 2010-03-18 16:45 UTC (History)
0 users



Attachments
The patch (8.53 KB, patch)
2010-02-22 18:35 UTC, Calixte Denizet
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Calixte Denizet 2010-02-22 18:35:10 UTC
Created attachment 25038 [details]
The patch

Hi,

I attach a patch (got with "svn diff") to reduce the size of ps and eps files generated with a PSGraphics2D. I put very simples macros and gave the possibility to disable clipping.

Best regards,

Calixte
Comment 1 Helder Magalhães 2010-02-22 21:35:26 UTC
(In reply to comment #0)
> Created an attachment (id=25038) [details]
> The patch
[...]
> I attach a patch (got with "svn diff") to reduce the size of ps and eps files
> generated with a PSGraphics2D. I put very simples macros [...]

Great! :-)  I guess it's better to state that this was already somehow discussed in the mailing list (bug's URL set to the specific thread).

I'm also slightly rephrasing the summary and adding metadata to reflect a patch (which was already lightly reviewed) being available.


> and gave the
> possibility to disable clipping.

Will this require some sort of documentation aside from the JavaDoc?


> Best regards,
> 
> Calixte

Thanks,
 Helder
Comment 2 Jeremias Maerki 2010-03-18 10:20:40 UTC
Thanks for your patch, Calixte. To produce smaller PS files, your patch makes perfect sense. However, I'm wondering if we should not make it configurable whether the standard commands or the short macros should be used. When debugging PostScript I find it desirable not to have to memorize all the one or two letter commands. Also, having the full commands in the Java source code would also improve readability. I'm thinking about a translation method in PSGenerator that converts the full commands to short ones if that is enabled (probably true by default). Something like this:

public String command(String postscriptCommand);

when compact mode enabled:
command("setlinejoin") --> "LJ"
when compact mode disabled:
command("setlinejoin") --> "setlinejoin"

So before we apply Calixte's patch, I'd like to ask around for opinions on this.
Comment 3 Chris Bowditch 2010-03-18 12:23:34 UTC
Hi All,

I agree with Jeremias. This change should be optional, because the shorthands make the Postscript difficult to read and debug.

Thanks,

Chris
Comment 4 Calixte Denizet 2010-03-18 12:31:50 UTC
Hello all,

I agree with Jeremias too.

Calixte
Comment 5 Max Berger 2010-03-18 13:25:58 UTC
Jeremias,

since you ask for it, here are my 2cts:

yes, the switch you mention makes sense, but I'd prefer it the other way round: Default should be smallest size, and the longer option could be "debug" or "verbose". Why? Because most people don't manually debug PostScript, but want to send it to their printer.

Max
Comment 6 Jeremias Maerki 2010-03-18 15:08:49 UTC
Patch applied with modifications: http://svn.apache.org/viewvc?view=revision&revision=924840

Thank you all for your quick comments. Since there were already 3 positive comments on this, I've added the option more or less as proposed.
Max, we were actually on the same page (compact shall be default).

Thanks, Calixte, for getting the ball rolling.
Comment 7 Calixte Denizet 2010-03-18 15:21:21 UTC
Jeremias,

You should put a setter in EPSTranscoder and PSTranscoder to enable or to disable the clipping (since the method disableClipping is available in AbstractPSDocumentGraphics2D). When clipping is disabled, I can divide by 2 the size of the generated ps,eps.

Thanks a lot...

Calixte
Comment 8 Jeremias Maerki 2010-03-18 15:36:37 UTC
Calixte, do you want to send a patch? Maybe a clever refactoring of PDFGraphics2D could actually improve things in a better way. Currently, the clipping shape is established for every shape operation which is why this probably has such a big effect on file size. The "disableClipping" is just a work-around but is not really fixing the problem, it would seem.

(In reply to comment #7)
> Jeremias,
> 
> You should put a setter in EPSTranscoder and PSTranscoder to enable or to
> disable the clipping (since the method disableClipping is available in
> AbstractPSDocumentGraphics2D). When clipping is disabled, I can divide by 2 the
> size of the generated ps,eps.
> 
> Thanks a lot...
> 
> Calixte
Comment 9 Calixte Denizet 2010-03-18 16:45:14 UTC
(In reply to comment #8)
> Calixte, do you want to send a patch? Maybe a clever refactoring of
> PDFGraphics2D could actually improve things in a better way. Currently, the
> clipping shape is established for every shape operation which is why this
> probably has such a big effect on file size. The "disableClipping" is just a
> work-around but is not really fixing the problem, it would seem.
> 

I'm not sure that "disableClipping" is just a workaround... that depends of what you draw. In my case, the clipping shape is determinated as the bounding box of my datas, so I know that what I draw is always included in the clipping shape, so no need to check and to consume resources !

I agree with you when you don't really know what you draw : a solution could be to make the clipping on the Java side and to send the "clipped" object to the PS writer. If you want I can work on this solution and send you a patch, it could be an interesting feature... I'll look at PDFGraphics2D...