Drawing text a PDF with an OpenType PS font (ie. with type 1 outlines) will result in the glyphs being drawn at the wrong horizontal position. Instead of adding the left side bearing specified in the font's <htmx> table, all the glyphs will be offset by the 'xMin' value from the <head> table of the font.
This is most noticeable with a font that has a large negative minimum left side bearing such as our 'Opus Special'. I've attached this along with a simple test case. The test case also draws text with Adobe's Myriad Pro, another commonplace .otf font, to indicate that the problem is not specific to our (slightly unusual) font. Build and run 'pdf-aligment-bug', then choose File > Save as PDF. The glyphs won't line up with the red line in the exported PDF.
This seems to be caused by a peculiarity (bug?) with the Win32 API GetGlyphOutline when used with an OpenType PS font. Qt uses this API in QFontEngineWin::addGlyphToPath. It can return the glyph's metrics as well as its outlines, and Qt uses the metrics when embedding the font in the PDF file to fill in the left side bearing value for each glyph. However, the API seems to return incorrect values if it's called in GGO_NATIVE mode and the font is OpenType PS. It works correctly with TrueType fonts, and works with all fonts when used in GGO_METRICS mode. So I've changed the code in getOutlineMetrics so that metrics (if requested) are retrieved in a separate call to GetGlyphOutline using GGO_METRICS, before retrieving the outlines themselves with GGO_NATIVE. This fixes the problem. I've attached my patch to this bug.
|For Gerrit Dashboard: QTBUG-12799|
|95188,5||Use metrics returned by GetGlyphOutline in GGO_METRICS mode||5.4||qt/qtbase||Status: MERGED||+2||0|
|99163,2||windowsfontengine.cpp: Fix coding style violation and warning.||5.4||qt/qtbase||Status: MERGED||+2||0|
|101886,4||Use metrics returned by GetGlyphOutline in GGO_METRICS mode||4.8||qt/qt||Status: MERGED||+2||0|