Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 4.0
-
Fix Version/s: 4.1
-
Component/s: Core/Parsing, Font Engine
-
Labels:None
-
Environment:Pro and OS version of the ICEPdf
Description
A sample PDF produced by Ghostscript 8.7 in PDF/A compatibility mode did not correctly render. After a lot of debugging and reading of the specification I was apple to figure out what was going on. When handling a CID font we always assumed that it was a 2 byte code were in fact the the CID can be 1 or 2 bytes as defined by the CIDSystemInfo dictionary.
Because this problem occurred deep in the parser it affected both version of the product, OS and PRO.
Because this problem occurred deep in the parser it affected both version of the product, OS and PRO.
Activity
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #21782 | Tue Jun 22 09:22:29 MDT 2010 | patrick.corless | |
Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/ofont/CMap.java
MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/CMap.java MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/LiteralStringObject.java |
Patrick Corless
created issue -
Patrick Corless
made changes -
Field | Original Value | New Value |
---|---|---|
Summary | Incorrect handling of 1byte CID values | Incorrect handling of 1 byte CID values |
Salesforce Case | [] | |
Fix Version/s | 4.1 [ 10227 ] |
Patrick Corless
made changes -
Salesforce Case | [] |
Patrick Corless
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Updated the CMap classes and interface to have a new accessor for checking if a string should be parsed using one or two bytes. This variable is check by the LiteralStringObject when handling content streams from a CID formated font. I don't think this rule applies to HexStringObject but I can say for sure.
Checking code and closing issue.