Fonts are embedded in EPS/PDF files at the wrong scale on Windows, meaning they can't be substituted for the real fonts without changing the apparent size of the text

When an application such as Adobe Illustrator opens an EPS file, it expects to be able to substitute any embedded fonts with the real ones from the user's system if the PostScript name matches. This currently won't work with EPS files exported from Qt due to the glyph and font names being wrong - see QTBUG-12834 and QTBUG-12727 - but even if the names match, it won't work at present due to a problem with the scale at which fonts are embedded.

To see the problem:

1. Build and run the attached test application and choose "File > Save as EPS".
2. Open the EPS file in a text editor.
3. To work around QTBUG-12834, find and replace "TimesNewRomanRegular" with "TimesNewRomanPSMT" (the correct PS name for Times).
3. To work around QTBUG-12727, find and replace "/gl59" with "/X" (the correct glyph name for the X glyph). Alternatively use a build of Qt with my patch from QTBUG-12727 applied.
4. Now open the EPS file in Adobe Illustrator.

Observe that the glyph is larger when rendered with the installed font that Illustrator substitutes for the embedded font, overflowing the bounds that were drawn around the glyph in red. I've attached an EPS file exported with 4.7.0 beta 2 where I've done steps 3 and 4 already, correcting the glyph and font names, so you can see the problem more immediately.

This seems to be caused by the code in #ifdef Q_WS_WIN inside QPdfBaseEnginePrivate::drawTextItem and QPdfEnginePrivate::drawTextItem which uses the TEXTMETRIC's height rather than the font definition's pixel height on Windows. It seems as this was done to work around some odd scaling that's happening inside the addGlyphToPath static in QFontEngineWin, where the glyphs returned will be scaled down from the native outlines of the font itself (by the GetGlyphOutline API). Effectively Qt is enlarging the text items drawn on Windows to compensate for the embedded glyphs themselves being scaled down. A better fix would be to remove these workarounds and pass a scale factor to addGlyphToPath in QFontEngineWin::getUnscaledGlyph, thereby ensuring that the font is embedded at the correct size. The scale factor would be the TEXTMETRIC height divided by the pixel height, to achieve the effect of the current code.

This would also require that the metrics returned in addGlyphToPath would need scaling by the scale parameter too, as the existing comment "#### obey scale" suggests.

With this fix in place (and the others to bugs 12727 and 12834), an exported EPS file would open correctly in a viewer that uses the embedded fonts (such as GhostView or Mac OS X Preview) and an editor that uses the installed fonts if available (such as Adobe Illustrator).