[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107815#comment-14107815 ] ASF subversion and git services commented on PDFBOX-2149: - Commit 1619957 from [~jahewson] in branch 'pdfbox/branches/no-awt' [ https://svn.apache.org/r1619957 ] PDFBOX-2262/PDFBOX-2149: Refactor CMaps and Encodings (Preflight) These changes allow preflight to work with the changes from the commit 1619956 > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107812#comment-14107812 ] ASF subversion and git services commented on PDFBOX-2149: - Commit 1619956 from [~jahewson] in branch 'pdfbox/branches/no-awt' [ https://svn.apache.org/r1619956 ] PDFBOX-2262/PDFBOX-2149: Refactor CMaps and Encodings - Proper handling of CID and ToUnicode CMaps - Proper handling of multi-byte character codes using CMap codespace ranges - Override widths as according to Adobe Supplement to the ISO 32000 - Improved handling of toUnicode CMaps - PDCIDFont no longer a subclass of PDFont as it is not a font - Reintroduced PDSimpleFont to handle Encoding and simple ToUnicode mappings > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085112#comment-14085112 ] John Hewson commented on PDFBOX-2149: - The file from PDFBOX-122 shows some font encoding/AWT bugs. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049554#comment-14049554 ] John Hewson commented on PDFBOX-2149: - I've moved the rendering of TrueType glyphs into a new GlyphRenderer class in FontBox instead of inside PDBox's TTFGlyph2D. I've also moved the various Glyph2D subclasses to a new pdfbox.rendering.font package in [r1607236|http://svn.apache.org/1607236]. This shouldn't affect rendering of any files. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041310#comment-14041310 ] Tilman Hausherr commented on PDFBOX-2149: - Thanks, now all files pass. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041179#comment-14041179 ] John Hewson commented on PDFBOX-2149: - Thanks Tilman: loading the TTFs uncovered a bug in PDTrueTypeFont, fixed in [r1604916|http://svn.apache.org/r1604916]. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040453#comment-14040453 ] Tilman Hausherr commented on PDFBOX-2149: - The cheese file (attached by Petr) works without NPE now, but there's a new exception for the file of PDFBOX-2059: Jun 23, 2014 8:02:49 AM org.apache.pdfbox.pdmodel.font.PDFont getSpaceWidth Schwerwiegend: Can't determine the width of the space character, assuming 250 java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.codePointAt(Unknown Source) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.makeFontDescriptor(PDTrueTypeFont.java:325) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getFontDescriptor(PDTrueTypeFont.java:150) at org.apache.pdfbox.pdmodel.font.PDFont.getFontWidth(PDFont.java:814) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getFontWidth(PDTrueType Font.java:379) at org.apache.pdfbox.pdmodel.font.PDFont.getFontWidth(PDFont.java:312) at org.apache.pdfbox.pdmodel.font.PDFont.getSpaceWidth(PDFont.java:855) at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:317) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:44) ... > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040349#comment-14040349 ] John Hewson commented on PDFBOX-2149: - Ok, the underling problem which caused an NPE in getFontDescriptor() is solved in [r1604679|http://svn.apache.org/r1604679]. System TrueType fonts now synthesise a FontDescriptor in the same manner as Type1 fonts. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040054#comment-14040054 ] Tilman Hausherr commented on PDFBOX-2149: - Thanks, yes, that one is fixed. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040006#comment-14040006 ] John Hewson commented on PDFBOX-2149: - Tilman, I've fixed the rendering of the PDFBOX-1283 file in [r1604497|http://svn.apache.org/r1604497]. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[
https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039896#comment-14039896
]
John Hewson commented on PDFBOX-2149:
-
{quote}
it shouldn't be possible for *getFontDescriptor()* to return null, either the
font is embedded in which case it must have a FontDescriptor, as this is where
the embedded file is stored, or it is a Type 1 system font in which case it
will have an AFM file, or it is a TTF system font *in which case its
FontDescriptor is populated in PDTrueTypeFont's constructor*.
{quote}
That's not a quote from the spec, I'm specifically discussing PDFBox's
getFontDescriptor() method. I also mention the FontDescriptor being populated
by PDFBox for system AFMs and TTFs (i.e. "synthesised" - which is what I've
been discussing all along). The behaviour of PDFBox when it encounters a
missing FontDescriptor is, in general, to synthesise a new FontDescriptor, but
there are cases where this isn't done, which is why I call it a bug: there's an
established approach to solving this problem but in one case it's not being
done and instead a questionable workaround has been used in its place.
But we seem to have figured this out now: I'll work on fixing it.
> 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039873#comment-14039873 ] Andreas Lehmkühler commented on PDFBOX-2149: [~jahewson] I didn't get your point as you didn't make your point clear in the first place. You were just quoting the spec, nothing more or less. And now you're talking about missing font descriptors and substituting those by a synthetic one. So, at least in the case of those by fault missing descriptors, we are talking about a workaround and not about a bug within PDFBox. Maybe such a workaround is better/more elegant than just avoiding a NPE but it's still a workaround. If we are talking about correct/incorrect values for the flags values of a dictionary, we should have a look at the PDFontDescriptorAFM#getFlags method, as it doesn't provide reasonable values in every case. Now that we are all in line, we can concentrate on the issue itself. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039717#comment-14039717 ] John Hewson commented on PDFBOX-2149: - I'm just going to fix the underlying bug. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039683#comment-14039683 ] Tilman Hausherr commented on PDFBOX-2149: - Can't this be done in a "softer" way, e.g. with a WARN if that branch is NULL so that rendering can go on and the problem be corrected in the future? > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039084#comment-14039084 ] Tilman Hausherr commented on PDFBOX-2149: - The file of PDFBOX-2059 has also the NPE. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038579#comment-14038579 ] Andreas Lehmkühler commented on PDFBOX-2149: [~jahewson] According to the spec you are totally right, but the real world is quite different. There are a lot of pdf generators which don't care about the spec. And more important the user doesn't care about the spec either. If the pdf opens in acrobat than it has to be opened by any other pdf reader as well. Tilman has an example, Petr as well, have a look at PDFBOX-62 and you'll find another one and I guess there are a lot more in with wild out there triggering the described NPE. Either you revert your changes to reinstate my workaround or you'll come up with another/better one yourself. We, the PDFBox community don't like it, but we've learned that we have to live with such workarounds. > 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: 39.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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[
https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038567#comment-14038567
]
Petr Slaby commented on PDFBOX-2149:
Attached a file which runs into a NPE in PDFont#isSymbolicFont() now.
{noformat}
Caused by: java.lang.NullPointerException
at org.apache.pdfbox.pdmodel.font.PDFont.isSymbolicFont(PDFont.java:694)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getGIDForCharacterCode(PDTrueTypeFont.java:408)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getFontWidth(PDTrueTypeFont.java:378)
at org.apache.pdfbox.pdmodel.font.PDFont.getFontWidth(PDFont.java:312)
at
org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:377)
at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:44)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:508)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:259)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:226)
at
org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:209)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:175)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:227)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPageToGraphics(PDFRenderer.java:190)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPageToGraphics(PDFRenderer.java:174)
{noformat}
> 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: 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037751#comment-14037751 ] John Hewson commented on PDFBOX-2149: - Tilman, I'll look into the rendering of PDFBOX-1283, it's a fairly broken file, I can view it in Acrobat but not any of my other PDF viewers. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037734#comment-14037734 ] John Hewson commented on PDFBOX-2149: - Sorry, I reversed your change in [r1604018|http://svn.apache.org/r1604018] because it shouldn't be possible for getFontDescriptor() to return null, either the font is embedded in which case it must have a FontDescriptor, as this is where the embedded file is stored, or it is a Type 1 system font in which case it will have an AFM file, or it is a TTF system font in which case its FontDescriptor is populated in PDTrueTypeFont's constructor. It looks like getFontDescriptor() and getAFM() could do with some refactoring to make this clearer, as it stands these methods have several code paths which return null - they just shouldn't get called in practice. Anyway, if for some reason we do get an NPE here then I'd prefer to have the NPE and get a bug report so that we can understand what's going on with the font in question - because I have no way to guess, and I suspect that PDFBox will break elsewhere with such a font. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037294#comment-14037294 ] Andreas Lehmkühler commented on PDFBOX-2149: I've fixed the NPE in isSymbolicFont in revision http://svn.apache.org/r1603854 There is another potential NPE in PDFont#getFontBoundingBox > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036963#comment-14036963 ] Tilman Hausherr commented on PDFBOX-2149: - Thanks, PDFBOX-1452 is now good, PDFBOX-1283 no longer has an NPE, but the rendering looks terrible. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036824#comment-14036824 ] John Hewson commented on PDFBOX-2149: - Thanks for spotting this, I've fixed this in [r1603698|http://svn.apache.org/r1603698]. It was a tricky bug, the "Signature not verified" text is inside a visual signature annotation which is rendered after clear() has been called on the pages resources, which was clearing the cmap cache in PDTrueTypeFont. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036613#comment-14036613 ] Tilman Hausherr commented on PDFBOX-2149: - PDFBOX-1283 also fails with an NPE. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036536#comment-14036536 ] Tilman Hausherr commented on PDFBOX-2149: - After the second commit, I got an NPE with that file: PDFToImage failed with the following exception: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDFont.isSymbolicFont(PDFont.java:694) at org.apache.pdfbox.pdfviewer.font.TTFGlyph2D.extractFontSpecifics(TTFGlyph2D.java:152) at org.apache.pdfbox.pdfviewer.font.TTFGlyph2D.(TTFGlyph2D.java:107) at org.apache.pdfbox.pdfviewer.font.TTFGlyph2D.(TTFGlyph2D.java:88) at org.apache.pdfbox.rendering.PageDrawer.createGlyph2D(PageDrawer.java:592) ... > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036505#comment-14036505 ] Tilman Hausherr commented on PDFBOX-2149: - Just before you had the last commit, I did a diff test and the file of PDFBOX-1452 came up differently. Instead of "Signature not verified" it says "Pignature k ot s erified". > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036494#comment-14036494 ] John Hewson commented on PDFBOX-2149: - Completed phase 1 with [r1603653|http://svn.apache.org/r1603653]: - 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. - 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. This commit is mostly devoted to deleting public setXXX methods and moving their functionality into font constructors. There shouldn't be any functionality changes, if there are, let me know. > 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 > > 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)
[jira] [Commented] (PDFBOX-2149) Font Refactoring
[ https://issues.apache.org/jira/browse/PDFBOX-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036378#comment-14036378 ] John Hewson commented on PDFBOX-2149: - I've begun phase 1 with [r1603633|http://svn.apache.org/r1603633]: - 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. This removes some public API methods which don't work in practice - if anybody is missing something I've overlooked, let me know. > 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 > > 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)
