iTextSharp font widths definition not correctly loaded - pdf

Question

I have peculiar issue with a PDF i got from a customer who used Ghostscript 9.19 to create a PDF/A compatible PDF (1.4). I want to extract text from it, using the LocationTextExtractionStrategy but I get most of the text in reversed order and with additional spaces:
expecting: abc
getting: c b a
in the content stream this might be [a,1,b,1,c] TJ
This issue has been posted to Stackoverflow before, however I cracked down the issue further than hacking my own extraction strategy. I realized that the font widths for the font used, is all zeroes and neither the metrics nor hMetrics maps are filled. I was using iTextSharp 5.5.4, but 5.5.9 still has the same issue.
This is the font:
/Subtype /Type0
/BaseFont /VGOQEA+SegoeUI
/Type /Font
/Encoding 33 0 R
/ToUnicode 48 0 R
/DescendantFonts [35 0 R]
object 33 is a CMap:
/CIDSystemInfo 32 0 R
/Filter /FlateDecode
/Length 266
/CMapName /OneByteIdentityH
/Type /CMap
object 48 is a Stream and incidentally also a CMap
object 35 finally has some width definitions
/DW 539
/CIDSystemInfo 32 0 R
/Subtype /CIDFontType2
/BaseFont /VGOQEA+SegoeUI
/FontDescriptor 26 0 R
/Type /Font
/W [0, [646], 32, [274], 40, [302, 302], 44, [217, 400, 217], 48, [539, 539, 539, 539], 53, [539, 539, 539, 539], 58, [217], 64, [955, 645, 573], 68, [701, 506], 72, [710, 266], 75, [580, 471, 898], 80, [560], 82, [598, 531], 85, [687], 87, [934], 90, [570], 97, [509, 588, 462, 589, 523, 313, 589, 566, 242], 107, [497, 242, 861, 566, 586, 588], 114, [348, 424, 339, 566], 119, [723], 122, [452], 220, [687], 228, [509], 246, [586], 252, [566]]
/CIDToGIDMap 47 0 R
In the order that iTextSharp initializes the CMapAwareDocumentFont, first the base DocumentFont gets initialized. The constructor then checks:
if (PdfName.TYPE1.Equals(subType) || PdfName.TRUETYPE.Equals(subType))
it's neither.
else if (PdfName.TYPE3.Equals(subType))
it's not. Then the next else branch is entered:
PdfName encodingName = font.GetAsName(PdfName.ENCODING);
if (encodingName == null)
but since encoding is given as an indirect reference, encodingName is null. Thusly the handling of this Type0 font is never handled.
I changed this bit in the library code, but even if the method ProcessType0(font) is called, the widths values never made it to the font definition - i.e. all remained zero. This is probably to be expected. Finally I got the metrics hash map filled, but i didn't cover all the used characters. I.e. the situation got a bit better, but not all good:
instead of: abc -> c b a
I now got: abc -> acb
My only working but hacky solution to the current issue was to hack processor.DisplayPdfString((PdfString)entryObj) to adjust the textMatrix by a fixed amount. However this is no general solution and I would rather that the font would work correctly. Any other suggestions what I should try?
EDIT:
I revisited my issue using iText 7 .Net and now I get a NullReferenceException when trying to read text from my test file.
var reader = new iText.Kernel.Pdf.PdfReader(#"itextsharp_sample_locationtext_extraction_reversing_characters(1).pdf");
var extractionStrategy = new LocationTextExtractionStrategy();
var doc = new PdfDocument(reader);
var page = doc.GetFirstPage();
var test = PdfTextExtractor.GetTextFromPage(doc.GetFirstPage());
Console.WriteLine(test);
This is the file I used: https://drive.google.com/file/d/0B1RdIg0_Pbd_aTlOT2VmbnFlaTQ/view?usp=sharing
The code works for other PDF files but not for this one.
UPDATE
Thanks to mkl I know now for a while that the underlying issue is font encoding streams. Sadly I just got a message via the iText sales team that this is not on the roadmap. They claim this is issue is a weird outlier, most anybody else does not need the support for font encoding streams. So if any of you reading this does have an issue with missing support, kindly let them know by email.