createGlyphVector prints in worse quality than drawString

[tresf]

Platform and architecture

Windows 10 x64

Java version

AdoptOpenJDK 11.0.4+11 HotSpot

Summary

Per Apache PDFBOX-4709, printing 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 printing with createGlyphVector versus drawString. Leveraging RenderingHints does not appear to help.

• ✅ drawString
  

• 🚫 createGlyphVector
  

Details

Quoting the PDFBOX developer Tilman Hausherr:

I'm now able to reproduce the effect [...] without using [Apache] PDFBox [...] please submit it to OpenJDK support with the sample code that does not use [Apache] PDFBox.

Steps

(Note, these steps include installing a proprietary printer driver to visually observe the issue, but the Apache PDFBOX developer was able to observe it without the proprietary driver and printing to a PDF instead)

1. Using Windows 10, install the latest ZDesigner driver from Zebra's website. The driver chosen was ZDesigner TLP 2884-Z although any ZPL driver should technically work.
2. Using Google Chrome, install the Zpl Printer plugin. If not already, open the Zpl Printer application and click it to "On".
3. Manually add a new Standard TCP/IP printer port to the system with an IP address of 127.0.0.1 (the OS took a long time to timeout and allow me to finish the port addition, but it does eventually let you.
4. Manually add a new printer to the system pointing it to the newly added TCP/IP port.
5. Select the ZPL driver (eg. TLP 2884-Z)
6. From the newly added printer properties, go to Preferences, Options and change the size to 4x6 inches (otherwise our example will throw PrinterException("Paper's imageable height is too small.");
7. Set the printer as the system's default printer.

import javax.print.PrintServiceLookup;
import java.awt.*;
import java.awt.font.FontRenderContext;
import java.awt.font.GlyphVector;
import java.awt.geom.AffineTransform;
import java.awt.print.PageFormat;
import java.awt.print.Printable;
import java.awt.print.PrinterException;
import java.awt.print.PrinterJob;

public class PrintQuality {

    public static void main(String[] args) throws Exception {
        //print using Graphics2D.drawString(...)
        new DrawStringTest();

        //print using Graphics2D.getFont().createGlyphVector(...)
        new GlyphVectorTest();
    }

    static class DrawStringTest implements Printable {
        DrawStringTest() throws PrinterException {
            PrinterJob job = PrinterJob.getPrinterJob();
            job.setPrintService(PrintServiceLookup.lookupDefaultPrintService());
            job.setPrintable(this);
            job.print();
        }

        private void paint(Graphics2D g2d) {
            g2d.setFont(new Font("Times New Roman", Font.PLAIN, 8));
            g2d.setColor(Color.BLACK);

            g2d.drawString("Thermal test [drawString]", 100f, 128f);
            g2d.drawRect(72, 72, 128, 64);
        }

        @Override
        public int print(Graphics graphics, PageFormat pageFormat, int index) {
            if (index == 0) {
                Graphics2D g2d = (Graphics2D)graphics;
                paint(g2d);
                return PAGE_EXISTS;
            } else {
                return NO_SUCH_PAGE;
            }
        }
    }

    static class GlyphVectorTest implements Printable {
        GlyphVectorTest() throws PrinterException {
            PrinterJob job = PrinterJob.getPrinterJob();
            job.setPrintService(PrintServiceLookup.lookupDefaultPrintService());
            job.setPrintable(this);
            job.print();
        }

        @Override
        public int print(Graphics graphics, PageFormat pageFormat, int index) {
            if (index == 0) {
                FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
                Graphics2D g2d = (Graphics2D)graphics;
                g2d.setFont(new Font("Times New Roman", Font.PLAIN, 8));
                GlyphVector gv = g2d.getFont().createGlyphVector(frc, "Thermal test [GlyphVector]");
                Shape outline = gv.getOutline();
                g2d.translate(100f, 127f);
                g2d.fill(outline);
                g2d.translate(-100f, -127f);
                g2d.drawRect(72, 72, 128, 64);
                return PAGE_EXISTS;
            } else {
                return NO_SUCH_PAGE;
            }
        }
    }

}

[karianna]

@tresf - 11.0.6 was just released, are you able to try that (both regular and adoptopenjdk.net/upstream.html versions).

[tresf]

Identical results with AdoptOpenJDK 11.0.6+10 x64.

This bug has existed for a while, my Oracle JDK8 environment exposes it as well.

[johnoliver]

Can you confirm that antialiasing definitely does not work and is not a viable solution.

I think I have produced a tighter reproducer of the issue as follows. As can be seen from the images, antialiasing does seem to have an effect and produce something readable.

import javax.imageio.ImageIO;
import java.awt.Color;
import java.awt.Font;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.Shape;
import java.awt.font.FontRenderContext;
import java.awt.font.GlyphVector;
import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;
import java.io.File;

public class PrintQuality2 {


    public static void main(String[] args) throws Exception {


        BufferedImage bImg = new BufferedImage(20, 20, BufferedImage.TYPE_INT_RGB);
        Graphics2D graphics = bImg.createGraphics();
        paint(graphics);
        ImageIO.write(bImg, "png", new File("/tmp/image.png"));


        BufferedImage bImgGlyph = new BufferedImage(20, 20, BufferedImage.TYPE_INT_RGB);
        Graphics2D graphicsGlyph = bImgGlyph.createGraphics();
        graphicsGlyph.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
        paintGlyphVector(graphicsGlyph);
        ImageIO.write(bImgGlyph, "png", new File("/tmp/antialiased_image.png"));


        BufferedImage bImgGlyph2 = new BufferedImage(20, 20, BufferedImage.TYPE_INT_RGB);
        Graphics2D graphicsGlyph2 = bImgGlyph2.createGraphics();
        paintGlyphVector(graphicsGlyph2);
        ImageIO.write(bImgGlyph2, "png", new File("/tmp/non_antialiased_image2.png"));

    }

    private static void paint(Graphics2D g2d) {
        g2d.setColor(Color.white);
        g2d.fillRect(0, 0, 20, 20);

        g2d.setFont(new Font("Times New Roman", Font.PLAIN, 8));
        g2d.setColor(Color.BLACK);

        g2d.drawString("Thermal test [drawString]", 0f, 10f);
    }

    private static void paintGlyphVector(Graphics2D graphics) {
        FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
        graphics.setColor(Color.white);
        graphics.fillRect(0, 0, 20, 20);
        graphics.setColor(Color.black);

        graphics.setFont(new Font("Times New Roman", Font.PLAIN, 8));
        GlyphVector gv = graphics.getFont().createGlyphVector(frc, "Thermal test [GlyphVector]");
        Shape outline = gv.getOutline();
        graphics.translate(0f, 10f);
        graphics.fill(outline);
    }
}

[tresf]

Can you confirm that antialiasing definitely does not work and is not a viable solution.

Setting RenderingHints.VALUE_ANTIALIAS_ON does not appear to impact the print output in the original unit test.

antialiasing does seem to have an effect and produce something readable.

It appears to be slightly visually improved for a format (such as PNG) which supports sub-pixel interpolation, however thermal printers don't support this. Furthemore, your antialias output is much different than the image created from drawString.

In contrast to the aliasing suggestion, techniques which force aliasing off and nearest-neighbor on are often preferred when readability is needed on a thermal printer... e.g: https:/qzind/tray/blob/b3e364028c6694e6fd571c08a44468948190d7e8/src/qz/printer/action/PrintPixel.java#L174-L180

Since the Apache library uses createGlyphVector (and not drawString), it results in print output that's inferior to all alternative applications for a low-dpi thermal printer (e.g. Chrome, Edge, Acrobat, etc).

As Tillman observes in his tests, the issue is very hard to observe at a high-dpi, which is probably why it's gone so long unnoticed (or perhaps more accurately, unreported).

[johnoliver]

You will have to bear with me as I am not familiar with this area so I am probably going off on red herrings. So I followed the steps to reproduce the issue. I noticed that I get acceptable results if I use drawGlyphVector and not creating an outline as in the example, i.e:

				FontRenderContext frc = new FontRenderContext(new AffineTransform(), true, true);
				Graphics2D g2d = (Graphics2D) graphics;
				g2d.setColor(Color.BLACK);
				g2d.setFont(new Font("Times New Roman", Font.PLAIN, 8));
				GlyphVector gv = g2d.getFont().createGlyphVector(frc, "Thermal test [GlyphVector]");
				g2d.drawGlyphVector(gv, 100f, 128f);

Do we have a link to the code where the apache library is drawing the GlyphVector to see how it is using it?

[THausherr]

The PDFBox library is not using "drawGlyphVector", it is drawing / filling the shapes it gets from decoding the font
https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java?view=markup#l481

The "drawGlyphVector" thing was created as a simple example to show that for some mysterious reason, fonts drawn with the font drawing methods are OK but no longer when their shapes are drawn directly, but only for small font sizes.

[tresf]

I noticed that I get acceptable results if I use drawGlyphVector and not creating an outline as in the example

I can confirm these findings:

[tresf]

I don't know if this information is helpful, but the example isn't reproducible on macOS.

Although there's a slight difference in output (font weight is a bit bolder), the quality is readable and acceptable.

[THausherr]

Yeah, Maruan (another PDFBox committer) tested on Linux and it was OK there. The original issue has my thoughts on that.

[tresf]

Yeah, Maruan (another PDFBox committer) tested on Linux and it was OK there. The original issue has my thoughts on that.

I'm quoting the conversation that you're referencing incase it offers any more context to the problem. @THausherr do you have any idea where to start looking for this? I know it sounds small and specific, but I feel the scope is quite large when thinking of how many real-world implementations of Apache PDFBOX are out there using this with 180 or 203 DPI printers (as well as any other projects leveraging similar Java code for printing).

Tilman wrote:

[...] this is a java or windows bug, that happens with small shapes. I am thinking of submitting it to java as soon as it is proven that my reasoning (printing to PDF demonstrates the problem) is correct [...]
[...] the workaround solution would be to use graphics.drawString(), but this would work only on fonts based on type1 or truetype fonts [...]

Maruan wrote:

[...] The test code from the original gist has the same quality [on Linux]

Tilman wrote:

Could you please repeat this with font size 4? I'd like to see whether there are interesting differences in the content stream.

Maruan:

(supplies size 4 test results)

Tilman wrote:

The curves are fine, and the strategy used is different: there is a 0.24 scale at the beginning, and then the vector graphics uses numbers with three digits after the ".". What didn't work so well is the alignement, like the "h" is too close to the "T".

[THausherr]

The real question is: what is done with the curves in the printer driver, why the loss of precision? I changed the initial code here to have a font size of 4 and set my default printer to "print to PDF" and here is the result
b.pdf
when viewing at 1000%, one sees this:

These are vector graphics. If they were correct, they would look good at any large scale.
A look at the PDF operators show only 2 digits behind the ".", see also the observation in the original bug report, search for the text "I also traced the shapes that are being passed, these have more digits".
My theory is that if one finds the cause for that, one has also found the problem with the Zebra printer.

With font size 8 the effect is harder to see but still here:

Same with drawString:

The difference can be seen on the "h" and the "e".

[THausherr]

I looked into the settings of my laser printer and it turns out I can set it to 300dpi.

[tresf]

An interesting write-up I found on stackoverflow: https://stackoverflow.com/a/18484397/3196753

Quoting...

With a little of black-box testing we realized that the problem vanishes when using bigger font sizes. Then, using very big font sizes (25000px) we got the upper points of the glyphs getting negative coordinates which look suspiciously like integer overflow side-effects.

I haven't tried to find the font engine's source code, but with the black-box testing I can suspect that the font engine used in our java version somewhere uses integer when reading the glyphs from the font which gets pretty big rounding errors when using small font sizes and overflow errors when using big font sizes.

To fix our problem and change our production code as least as possible we have decided to always load the font with a font size of 100px and then to scale the Shape with AffineTransform to the desired size.

Unfortunately, my attempts to render at a larger size and then shrink explicitly using AffineTransform still result in poor quality.

[tresf]

Unfortunately, my attempts to render at a larger size and then shrink explicitly using AffineTransform still result in poor quality.

I also tried to create a default transform and render everything at a larger size and the bug still occurs, nearly identically...

// Snag the old transform so we can use it for scaling
AffineTransform backup = ((Graphics2D) graphics).getTransform();

// Reset to a default transform
((Graphics2D) graphics).setTransform(new AffineTransform());
double fontSize = 8;
double patchedSize = fontSize * backup.getScaleX();
graphics2D.setFont(new Font("Times New Roman", Font.PLAIN, (int)patchedSize));
GlyphVector gv = graphics2D.getFont().createGlyphVector(frc, "Thermal test [GlyphVector]");

I even tried coercing the AffineTransform to use a higher (10.0f) and lower (0.001f) value for the scaling factors, but all resulted in the same poor quality output.

After a bunch of digging I had a suspicion that the bug was rooted in SunGraphics2D, but naturally I'm having a hard time running any experiments against it. Interestingly, when reading some unit tests against SunGraphics2D I found this blurb...

// REMIND: We will allow this test to pass silently on Windows
// (when OGL is not enabled) until we fix the GDI pipeline so that
// its stroked/filled GeneralPaths match our software loops (see
// 6322554).  This check should be removed when 6322554 is fixed.
GraphicsConfiguration gc = frame.getGraphicsConfiguration();
if (gc.getClass().getSimpleName().startsWith("Win")) {
   System.out.println("GDI pipeline detected: " +
      "test considered PASSED");
   frame.dispose();
   return;
}

So I looked up JDK-6322554 and found this old bug... which is marked as affecting JDK6, JDK9 for Windows. It's currently classified as "Fix Understood". Here's the description:

GDIRenderer has noticeable problems with matching fill(Shape) and draw(Shape) methods.
So, should perform drawing through new subpixel rendering code.

So I kept digging... I found reference to another issue, JDK-7129078.

This issue has a much better writeup and although it contains information specific to Swing drawing routines and double-buffering, I feel it may be applicable as it reads very similar to what we're observing. I'll quote the whole thing as I feel it's all relevant...

This issue is present only when double buffering is enabled.
In the sample provided, with double buffering enabled, the two draw calls uses two different renderers for blit operations.
In paint, the RepaintManager gives the Graphics object from the VolatileOffscreenBuffer and all the path drawing operations happens on it through java2d/loops/DrawPath.
However, in the second drawing part, where the Graphics object is obtained from the Panel, path drawing operations are routed to java2d/windows/GDIRenderer.
The GDI Renderer uses the WinGDI calls MoveToEx, LineTo and PolyBezierTo to complete the path drawing operations.
For line drawing operations, when comparisons were done with the values being calculated for the two renderers, it was found that the loops renderer rounds the float coordinate values to the nearest int, whereas the GDIRenderer uses floor to convert the floating values to int. Because of this line drawing having floating coordinate values above x+0.5 (say 130.6 as given in the test) was behaving differently across the two renderers. (Refer to attachment "Line_Drawing_Floor_Coords.png")

When double buffering is disabled, (RepaintManager.currentManager(panel).setDoubleBufferingEnabled(false)), both the rendering happens through the GDIRenderer and no disparity is observed.

Changing the GDIRenderer to round the float coordinate to the nearest int fixes the issues for Line Rendering. (Refer to attachment "Line_Drawing_Round_Coords.png")

However, if we extend the test case to include other shapes viz qaudratic and cubic curves through quadTo and curveTo interfaces we can still see some disparity in rendering with the two methods, with round and floor both (Refer to attachments "Path_Drawing_Floor_Coords.png" and "Path_Drawing_Round_Coords.png").

A proper solution to fix this issue, for all shapes, is to make GDIRenderer use ProcessPath routines, doFillPath and doDrawPath. However this causes a performance impact as detailed out in https://bugs.openjdk.java.net/browse/JDK-6322554

So am I getting close? Is there a way to force quality over performance using the information provided in JDK-7129078?

[karianna]

Thanks, @tresf - @johnoliver can you take a look at the code samples in those two OpenJDK bug reports and see if you can repro?

[Vzor-]

This 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. This causes each node to 'snap to' an integer value, this includes bezier curve control points. 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.

Unfortunately this issue seems to be caused by limitations within windgi rather than a flaw in its java implementation. I do not know much about the topic, but perhaps an alternative could be used.

[karianna]

@tresf - I saw an old note that setting -Dsun.java2d.d3d=true might force a difference rendering pipeline - is that something you can quickly test your side?

[tresf]

@karianna, -Dsun.java2d.d3d=true yields identical results.

[THausherr]

@tresf This was written without thinking much. I looked at our current code, one would first have to get the the font stream and then open it with Java (not all types of valid fonts can be opened in java). This is what PDFBox 1.8 was doing. So I did it with your "drug-print.pdf" test file on jdk14 and there are many error messages, java can't open the font and uses another font instead. (That is the reason why we have our own font engine that does the complete rendering) Try the PDFBOX 1.8 app jar on your printer to see what you get... My output didn't really look good at 300dpi.

[tresf]

My output didn't really look good at 300dpi.

Hmm... well, 1.8 didn't have the rendering hints added yet, would that impact it? I'll see what it draws like on the emulator.

[tresf]

The emulator's results for 1.8 confirm @THausherr's suspicions that it may not help a whole lot for the PDF that inspired the bug report. One could argue that 1.8 is slightly better, but I would say it's marginal. Here're my results.

And here's the results printing to a PDF printer, zoomed in to illustrate the inaccuracies that are created:

@THausherr this is quite different from what the drawString(...) results showed. Do you know why?

[THausherr]

I've recompiled and added 3 rendering hint commands before the drawString() command and it is a bit better. I'm going to sleep soon so if you want to test this, get the source, search for Pagedrawer.java and add these 3 lines before "font.drawString"

            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);

or whatever else you think might help.

[tresf]

I've recompiled and added 3 rendering hint commands before the drawString() command and it is a bit better.

It may be marginally better, but since the rounding issues:

1. Occur using 1.8, 2.0 as well as createGlyphVector(...)
2. Do NOT occur using drawString(...)

I'm inclined to believe that the underlying rounding issues that are plaguing Windows won't be fixed using 1.8 (or more accurately, won't be fixed by reverting to 1.8's logic) . Evidence of this is here. These same artifacts do not occur when using drawString(...).

[tresf]

Our primary JDK support provider has attempted and failed to fix this issue through GDI by working directly with Microsoft. As a result they've reached out to the openjdk mailing list for advice on how to fix this moving forward: https://mail.openjdk.java.net/pipermail/2d-dev/2020-September/011071.html

Our secondary JDK support provider is taking a different approach by adding a System property to Java which allows switching to GDI+. This impacts quite a bit of code due to API changes between GDI and GDI+. Results already look promising although I'm not certain as to the chances of this being accepted upstream (if not, the project requiring this will be on a forked release for eternity as a result of this change). I'll provide updates as I receive them.

[tresf]

Good news, testing our secondary JDK support provider's code, @lite1979 and I were able to achieve near-identical results to Ubuntu, but using Windows 10 and a custom JDK.

This isn't as good as Adobe, but it's more readable than the current JDK and the vendor was able to do so both with GDI and GDI+ to near identical results. The current plan is to submit the pure-GDI patch to openjdk for approval. Currently, the setting is toggled using a system property, which we'll share when the feature is closer to landing upstream.

[tresf]

Despite the "good news" from previous post, it turns out that neither GDI nor GDI+ really help improve this to even come close to CUPS/Adobe, so the vendor has taken a second approach.

This new approach is to scale the content 1000x so that when GDI transforms it, it maintains most of the quality.

Although instinct would say to only do this for small fonts, I've been able to visually see these artifacts even on higher DPI printers (600dpi, 1200dpi). For example, if a PDF is printed to a HP Laserjet 4000 series and if I look closely, I can see the artifacts. So I'm quite confident that this technique will be welcomed by all print jobs -- albeit not necessarily needed for readability for the larger unit-tests, should be welcomed from a quality perspective. 🚀

Here's a before/after:

The vendor has a JDK patch ready, we'll be testing shortly.

[tresf]

The vendor's patch was tested with mixed results. Although the shapes improve, the lack of outer stroke causes them to still suffer from quality issues. Adding a stroke causes them to be too bold. The vendor is still working towards a palatable solution.

[tresf]

Upstream PR created: openjdk/jdk#1183. This doesn't entirely fix the problem, something with the missing text outline when using fill just never achieves the same quality as drawString. So in addition to this bug, we're looking into patching PDFBOX downstream per @THausherr recommendation in PDFBOX-4709, quoting:

Tilman, would PDFBOX entertain adding something in that allows a user to go back to [1.8's drawString(...) -- which is only compatible with certain fonts]? The reason I ask is because the low-dpi PDFs/fonts are often prepared by controlled environments, so it at least offers a stop-gap for shops that need good quality PDF printing on Windows..

It seems difficult. It might be done by the user by extending PageDrawer and PDFRenderer and implementing the showFontGlyph method.

[tresf]

we're looking into patching PDFBOX downstream per @THausherr recommendation in PDFBOX-4709, quoting:

The PDFBOX downstream bug report has been documented here, and can be tracked as such: https://issues.apache.org/jira/browse/PDFBOX-5093

I'm leaving this bug report open since JDK-8256264 hasn't landed on any of the Adopt builds, as it hasn't been backported to any versions offered on the downloads page yet. If interested, EA builds directly from openjdk should contain the first half of the patch.

[tresf]

Quoting our JDK provider:

JDK-8256264 is now backported to OpenJDK 11 upstream and will appear in the 11.0.11 April release. Closing this issue.

Since the remaining components are related to https://issues.apache.org/jira/browse/PDFBOX-5093, we'll continue tracking those there. Closing. :)