Q: During PDF/A conversion/validation we are occasionally running into “e_PDFA3_6_1: Widths in embedded font are inconsistent with /Widths entry in the font dictionary”. The issue is not resolved during PDF/A conversion with ‘pdftron.PDF.PDFA.PDFACompliance’.
What are exact technical issues at play, so that we can better understand why this is a difficult issue to resolve and potentially explore new approaches to fixing it.
A: e_PDFA3_6_1 or ‘inconsistent widths’ issue is caused when advance widths in PDF font dictionary do not match advance widths in the embedded font.
Given that advance widths in the embedded font are never supposed to be used during PDF rendering it is not clear why PDF/A standard puts this restriction in the first place. Furthermore PDF/A-1 does not define if the match is exact or approximate, and if it is approximate, what is the error tolerance . Unfortunately there are many similar holes in PDF/A standard(s).
Given the above perhaps the issue should be reported as a ‘warning’ instead of an ‘error’? This should minimize concerns. We will most likely add support for warning in a next update.
We believe that there is no ‘good’ way to fix this ‘error’. Also it seems that there is no third party software that will resolve the issue in a reasonable way.
One way to fix the issue is to rewrite the entire content stream using explicit glyph positioning, and override Widths entry in the font to match the embedded font. This solution does not make much sense because ‘Widths’ entry would not be used at all, but more significantly it will bloat file size, slow down the rendering, and would interfere with text extraction/selection.
Perhaps another option with many down sides is to rasterize the entire page and discard all font info. Needless to say this would not work for most users.