On Fri, 20 Nov 2020 06:31:24 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> Printing text using GlyphVector outline has bad quality on printers with low >> DPI on Windows. >> The GDI system used for text printing on Windows accepts only integer path >> coordinates. >> Rounding GlyphVector outline coordinates leads to distorted printed text. >> >> To reproduce the issue run the >> [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) >> file on Windows and select a low DPI >> printer in the printer dialog. The sample prints two lines, one using >> Graphics drawString() method and another by >> filling GlyphVector outline. Chars on the second line are distorted. >> >> It is also possible to reproduce the issue running the sample and printing >> the text to PDF: >> [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) >> >> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" >> property which being enabled >> scales the GDI WorldTransform down and GlyphVector outline coordinates up. >> This allows to keep some digits after a dot from being rounded. >> The value for scaling is chosen to be 1000 in the same way how it is used >> by `String trunc(float f)` method from PSPrinterJob class on Linux: >> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 >> >> See the >> [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) >> screenshot which shows how the GlyphVector outline is filled after the fix >> with the enabled "sun.java2d.print.enablePathPrecisionScale" option. >> >> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) >> shows difference of GlyphVector outline printing before and after the fix. > > I am not sure that we need the additional property for things other than > possibly to workaround some possible bugs. I am fine if we will use the > scaled version all the time, does it have any drawbacks? I prepared a simple [print test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) sample which uses 4 different fonts (plain and bold) with different sizes and prints 640 lines on 10 pages. I run the sample with and without the fix to PDF and measured the time which is used by the deviceFill() method (it both converts the shape to path and fills it): https://github.com/openjdk/jdk/blob/b21b96df2162c72098afcdfd2cf243a55a0f17e1/src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java#L1489 The average time without the fix: 2.77s (min 2.74s, max 2,78) The average time with the fix: 2.76s (min 2.74s, max 2.77) I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1183
