[OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve text printing performance for postscript devices

[Alex Geller]

Hi Anton,
yes I am aware of your analysis of the issue. Working around the problem 
by using printer fonts was one of the first things I suggested. When it 
turned out that it wasn't working anymore  I posted a bug for it at 
Oracle (9008662) that hasn't appeared yet. Later I found your 
description and based on that also found a workaround (By setting the 
system property "sun.awt.fontconfig" to point to a pre 6u18 
"fontconfig.properties" file (The workaround is described in more detail 
in the second paragraph of my previously mentioned post to the OTN 
(https://community.oracle.com/thread/2617145)).

 >P.S. I'm not a 2D developer, so I couldn't take care of your proposal, 
but I think it's good.
Thanks a lot.
Regards,
Alex
On 1/10/2014 12:49 PM, anton nashatyrev wrote:
> Hi Alex,
>
>     you also might be interested in the issue I'm working on: 
> https://bugs.openjdk.java.net/browse/JDK-8023990
>     If you are targeting Linux platform and working with Latin-1 
> charset primarily this fix may help (I hope I could push it in the 
> nearest future). FYI the fix is here: 
> http://cr.openjdk.java.net/%7Ealitvinov/8023990/webrev.00
>
> Regards,
> Anton.
>
> P.S. I'm not a 2D developer, so I couldn't take care of your proposal, 
> but I think it's good.
>
> On 09.01.2014 20:34, Alex Geller wrote:
>> Hi,
>> this is not a production code patch but rather a proof of concept.
>> The patch improves the Postscript produced in calls to 
>> Graphics2D.drawString().
>> The the current implementation first tries to print strings using one 
>> of the standard Postscript fonts (PSPrinterJob.textOut()) and if that 
>> fails it falls back to drawing glyph vectors.
>> The patch adds a third method which is to convert the string into 
>> glyphs by means of Font.createGlyphVector() and embed those glyphs in 
>> form of a Postscript "Type 3" font.
>> The font is updated incrementally which is explicitly allowed by the 
>> Postscript specification.
>> The incremental update makes the patch also usable for Asian 
>> environments where eager embedding is not a good option because the 
>> fonts are huge.
>> The file is reduced compared to glyph vector drawing. As an example 
>> consider a "terms an conditions" page that has 17,000 characters 
>> using 3 different fonts.
>> Using the current method the Postscript file is about 8 MB. Using the 
>> new method the file is 164 KB.
>> However, the motivation for submitting this patch is not the file 
>> size but the printing time. The original file takes 4:45 minutes to 
>> print while the version with the embedded font prints in less than 10 
>> seconds on the same printer.
>> I suspect the slowness in the fact that the glyph vectors are not 
>> cached while the Type 3 fonts are. I posted the results of some 
>> related experiments with the Postscript "ucache" command on the OTN 
>> forum (see https://community.oracle.com/thread/2617145).
>> Based on that I can post a patch for speeding up 
>> Graphics2D.drawGlyphVector() substantially too if there is interest.
>> Coming back to the main topic my question is if there are chances 
>> that this gets included. If yes, then I would do (perhaps with some 
>> help) what is necessary to take it from a POC to production code.
>> I would also be happy if it could be included and activated only by a 
>> system property or a rendering hint.
>> The issue is quite important to us and time doesn't seem to heal 
>> this. Even printers in the 10,000$ class can take minutes to print a 
>> few pages using the current method.
>> Attachments:
>> - openjdk.patch: A patch based on "openjdk_7_b147_jun_11"
>> - PSTest.java: A test program demonstrating the feature
>> - out.ps.zip: A zipped Postscript file produced by the test program 
>> "PSTest.java"
>> Thanks,
>> Alex
>>
>>