Loading...

XML

Word

Printable

Details

Type: Bug
Resolution: Done
Priority: P3: Somewhat important
Fix Version/s: 5.4.0 Beta
Affects Version/s: 4.6.2, 4.7.0
Component/s: GUI: Font handling, GUI: Printing
Labels:
None
Environment:
Windows

Commits:
4aba2d07d2fe67beaf544a4b38c5b9aa8b8ec39b

Description

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.