Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-12834

Qt uses the wrong PostScript names when embedding fonts in EPS files on Windows and Cocoa



    • Bug
    • Resolution: Unresolved
    • P3: Somewhat important
    • None
    • 4.6.2, 4.7.0
    • None
    • macOS, Windows


      When embedding subsetted fonts in EPS files, it's important that the true PostScript name of the font is used, so that other software can identify the corresponding font on the user's system if it is present. This allows exported EPS files to be opened in, say, Adobe Illustrator and edited as text rather than as outlines, as long as the user has the correct fonts installed.

      Qt uses a different name when embedding fonts in PostScript. This means that upon opening the EPS file in Adobe Illustrator you get errors about fonts not being found, and then the glyphs are rendered as outlines, precluding the text from being edited.

      In Qt the PostScript font name is set in QFontEngine::properties(). The Mac Carbon implemention of this in QFontEngineMac does the right thing, but the windows implementation in QFontEngineWindows and the Cocoa implementation in QCoreTextFontEngine are incorrect. On Windows, the family name and style are concatenated together, and in CoreText the base classes' implementation of properties() is used which adds numbers to the end of the font's family name.

      The Mac CoreText problem is also covered by QTBUG-10094 - it requires the missing QCoreTextFontEngine::properties() method to be implemented using the appropriate APIs to retrieve the PostScript name. On Windows, there's no API to get the PostScript name so Qt needs to look up the PostScript name in the <name> table of the font (assuming it's OpenType or TrueType).

      Addendum: I added some code to retrieve the name from the <name> table QFontEngineWin in my build of Qt, but fell foul of another problem, which is that several of the methods in QFontEngineWin don't bother to reset the GDI font when calling SelectObject on the shared DC. In particular getSfntTable doesn't do so, which meant that the use of this method in properties() to retrieve the correct PostScript name caused drawing to go wrong at a later date.


        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              Unassigned Unassigned
              jlarcombe James Larcombe
              2 Vote for this issue
              5 Start watching this issue



                Gerrit Reviews

                  There are no open Gerrit changes