I don't know how FontEngine works under-the-hood, but stepping through AbstractContentParser.drawString(...) in a debugger shows that all the necessary information is present at the time GlyphText objects are constructed. For example, the first embedded font in the attached PDF is used for the blue text ("Front Range") on the middle-right side of the page:

• displayText contains CIDs, in the font's custom encoding: \u0001\u0002\u0003\u0004\u0005\u0006\u0007\u0008\u0004\u0009\u000A
• textState.font appears to contain an Encoding object named "WinAnsi+diffs" that maps these CIDs to standard symbol names:

  0 -> ".notdef"
  1 -> "F"
  2 -> "r"
  3 -> "o"
  4 -> "n"
  5 -> "t"
  6 -> "space"
  7 -> "R"
  8 -> "a"
  9 -> "g"
  10 -> "e"
  11 -> "space"
  

  ...so the CIDs can be mapped to: ["F", "r", "o", "n", "t", "space", "R", "a", "n", "g", "e"]

• The OFont Encoding implementation (org.icepdf.core.pobjects.fonts.ofont.Encoding) has a mapping from these symbol names to UVs, from which it should be trivial to get to a Unicode string. I'm guessing that NFont's Encoding implementation has something similar.

So, given that all this information is already available to the code, it seems that FontEngine should be able to work with the custom encoding without too much trouble.

Note that this issue may be related to PDF-936 ("ToUnicode conversion errors for text extraction") or PDF-616 ("Missing unicode value when extracting text"), since both of those issues involve embedded custom-encoding font subsets.

This appears to be a regression introduced in PDF-722. The basic problem was that for some TrueType fonts the encoding information specified by the document doesn't always match the font. As a result we can get an encoding that doesn't always match the glyph map of the font and end up with a PDF rendering that doesn't look right. In this particular the encoding data is fine and matches what is in the font. However in such a case we normally generate a toUnicode table out of the encoding data for text extraction purposes. The fix for PDF-722 prevented this map from being correctly assigned.

Marking as fixed.