[OpenJDK 2D-Dev] In windows GlyphVector produces poorer quality output versus using Graphics.drawString

Anawesha Khuntia AnaweshaK at in.ibm.com
Tue Sep 15 12:57:44 UTC 2020


Hi, 


As Per Apache PDFBOX-4709 ( https://issues.apache.org/jira/browse/PDFBOX-4709 ), while printing in windows using GlyphVector produces poorer quality output versus using Graphics.drawString(...). There's a significant quality difference ,especially on low-dpi (e.g. thermal) printers printing with createGlyphVector versus drawString. 

Leveraging RenderingHints does not appear to help.

Incase of GlyphVector,the issue seems to be caused by precision loss in WPrinterJob.lineTo which maps to wingdi.h LineTo. In all of the jni functions, floats are passed, but in native, only ints and longs are accepted. However , the drawstring function utilizes the wingdi TextOut function and is unaffected due to the text never being converted to curves. It is simply saved as text and the recipient renders it.

We have explored various options such as,
1. alternate to lineTo function. However there was no alternate function found in GDI.
2. using setmapmode option, it sets the mapping mode of the specified device context. Using this too did not help us.
3. another alternate lineadd function was evaluated and found inappropriate coz of its dependency on fixed X and Y co-ordinate values which is not the case here.
4. renderingHint options too were tried out, however neither the resulted characters printed were not smooth, nor the curve of characters were smooth.Below options were tried
graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
graphics.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BICUBIC);
graphics.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);


A similar rendering issues have been reported in the bugs : https://bugs.openjdk.java.net/browse/JDK-7129078 and https://bugs.openjdk.java.net/browse/JDK-6322554

We understand this is a very old issue and various challenges related to GDI rendering.These days more and more customers moving into opensource and this could well sound like a limitation for a certain set of consumers who has strong business need to extensively use low-dpi printers.Hence the recommended option would be to look into this issue by the community and fix it.


Regards,
Anawesha 



More information about the 2d-dev mailing list