ICEpdf
  1. ICEpdf
  2. PDF-188

Incorrect handling of 1 byte CID values

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major 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.

             

              Activity

              Descending order - Click to sort in ascending order
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]
              Patrick Corless made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Hide
              Permalink
              Patrick Corless added a comment -

              checked in code to core and the font library.

              Show
              Patrick Corless added a comment - checked in code to core and the font library.
              Patrick Corless made changes -
              Salesforce Case []
              Hide
              Permalink
              Patrick Corless added a comment -

              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.

              Show
              Patrick Corless added a comment - 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.
              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 created issue -
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #21782 Tue Jun 22 09:22:29 MDT 2010 patrick.corless PDF-188 fixed issue where one byte character codes where not correctly picked up for CID fonts. Normally two bytes are used but for some reason ghostscript 8.7 started generating PDF's with one byte.
              Files Changed
              Commit graph MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/ofont/CMap.java
              Commit graph MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/CMap.java
              Commit graph MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/LiteralStringObject.java

                People

                • Assignee:
                  Patrick Corless
                  Reporter:
                  Patrick Corless
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: