[
https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039594#comment-14039594
]
John Hewson commented on PDFBOX-2149:
-------------------------------------
[~lehmi], you've missed the point, PDFBox is already equipped to handle the
cases where the FontDescriptor is missing by substituting in a synthetic
FontDescriptor, so we shouldn't be seeing cases where the getFontDescriptor()
returns null. It's a bug in PDFBox. Defaulting to returning false from
isSymbolicFont() is incorrect, for example if it's the "Symbol" font which is
missing it's FontDescriptor - it's related to PDFBOX-2140 which I'm trying to
fix. What we're seeing in these PDFs in that when a font is missing we're
replacing it with the default font but we should be synthesising a
FontDescriptor from the default font which we loaded from disk. In other words
the NPE is actually showing us that there is a bug in PDFBox which needs a fix:
and returning false is not going to produce the correct results. Just because
you got rid of an exception doesn't mean that PDFBox's behaviour has been
corrected: there's more work to be done here to synthesise the missing
FontDescriptor correctly.
> Font Refactoring
> ----------------
>
> Key: PDFBOX-2149
> URL: https://issues.apache.org/jira/browse/PDFBOX-2149
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox, PDModel
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Attachments: 000039.pdf, 000467.pdf
>
>
> To fix bugs such as PDFBOX-2140 and to enable Unicode TTF embedding we need
> to sort out long-standing font/text encoding issues. The main issue is that
> encoding is done in an ad-hoc manner, sometimes in the PDFont subclasses,
> sometimes elsewhere. For example TTFGlyph2D does its own decoding, and this
> code is copy & pasted into PDTrueTypeFont. Likewise, PDFont handles CMaps and
> Encodings despite the fact that these two encoding methods are mutually
> exclusive. The end result is that the process of reading Encodings/CMaps is
> often following rules which are completely invalid for that font type but
> mostly work by luck.
> Phase 1
> - Refactor PDFont subclasses to remove setXXX methods which allow the object
> to be corrupted. Proper use of inheritance can remove all cases where public
> setXXX methods are used during font loading.
> - Clean up TTF loading and the loadTTF in anticipation of Unicode TTF
> embedding, FontBox's TrueTypeFont class is externally mutable via setXXX
> methods used only by TTFParser: these can be made package-private.
> - the Encoding class and EncodingManager could do with some cleaning up prior
> to further refactoring.
> - PDSimpleFont does not do anything, its functionality should be moved into
> its superclass, PDFont.
> - PDFont#determineEncoding() loads CMaps when only Encodings are applicable,
> and vice versa. Loading needs to be pushed down into the appropriate
> subclasses, as a starting point the relevant code should at least be copied
> into the relevant subclasses ready for further refactoring.
> - TTFGlyph2D does its own decoding of char codes, rather than using the
> font's #encode method (fair enough because #encode is broken) and there's a
> copy and pasted version of the same code in PDTrueTypeFont - we need to
> consolidate this code into PDTrueTypeFont where it belongs.
> Phase 2
> - Refactor loading of CMaps and Encodings from font dictionaries, this will
> involve changes to PDFont and its subclasses to delegate loading to
> subclasses where it can be properly encapsulated
> - May need to alter the class hierarchy w.r.t CIDFont to facilitate this, as
> CIDFont isn't really a PDFont - it's parent Type0 font is responsible for its
> CMap. We'll see.
> Phase 3
> - Refactor the decoding of character codes by PDFont and its subclasses, this
> will involve replacing the #getCodeFromArray, #encode and #encodeToCID
> methods.
> - Fix decoding of content stream character codes in PDFStreamEngine, using
> the newly refactored PDFont and using the current font's CMap to determine
> the code width.
> Phase 4
> - Add support for generating embedded TTFs with Unicode
--
This message was sent by Atlassian JIRA
(v6.2#6252)
