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
