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.

Marking as fixed.