Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.1.1
-
Fix Version/s: 5.1.2
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:All
-
Support Case References:Support Case #13233 - https://icesoft.my.salesforce.com/5007000000yB0fd
Description
With the provided PDF file, there are embedded fonts that are non being rendered correctly. The customer has the following comments which might help to narrow down the issue:
"On the cover page of the pdf the customer uses two embedded fonts that display with incorrect mappings (AveniR LTSTD-Light and AveniD LTSTD-Black) when viewed with IcePDF v5.1.0 and v5.1.1-p2.
In Reader they render correctly and they printed fine on the ImagePress.
Ghostscript 8.64 appears to have the same mapping problem as IcePDF.
Ghostscript 9.0.5 seems to render the pdf correctly. "
"On the cover page of the pdf the customer uses two embedded fonts that display with incorrect mappings (AveniR LTSTD-Light and AveniD LTSTD-Black) when viewed with IcePDF v5.1.0 and v5.1.1-p2.
In Reader they render correctly and they printed fine on the ImagePress.
Ghostscript 8.64 appears to have the same mapping problem as IcePDF.
Ghostscript 9.0.5 seems to render the pdf correctly. "
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 5.1.2 [ 11872 ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #44115 | Wed Feb 25 13:00:30 MST 2015 | patrick.corless | |
| Files Changed | ||||
MODIFY
/icepdf/branches/icepdf-5.0.1/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontDescriptor.java
MODIFY
/icepdf/branches/icepdf-5.0.1/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontManager.java
MODIFY
/icepdf/branches/icepdf-5.0.1/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontFactory.java
|
Finally manged to find the line in the spec that corresponds to the strange mapping
"The “CFF” font program has a Top DICT that does not use CIDFont operators: The CIDs shall be used directly as GID values, and the glyph procedure shall be retrieved using the CharStrings INDEX. Detection happens
in the setEncoding method.."
The above is only for CFF programs that are of Type0 or Type0c and are CID.
The font engine has no notion of this concept and thus some refactoring is needed to make sure we can pass the FontDescriptor subtype info into the font engine. No we can chose to use an identity mapping if we have a CFF font that is of Type0 or Type0c. And presto the PDF in question renders correctly.
Show
Patrick Corless
added a comment - Finally manged to find the line in the spec that corresponds to the strange mapping
"The “CFF” font program has a Top DICT that does not use CIDFont operators: The CIDs shall be used directly as GID values, and the glyph procedure shall be retrieved using the CharStrings INDEX. Detection happens
in the setEncoding method.."
The above is only for CFF programs that are of Type0 or Type0c and are CID.
The font engine has no notion of this concept and thus some refactoring is needed to make sure we can pass the FontDescriptor subtype info into the font engine. No we can chose to use an identity mapping if we have a CFF font that is of Type0 or Type0c. And presto the PDF in question renders correctly.
Updates have passed QA, marking as resolved.
Show
Patrick Corless
added a comment - Updates have passed QA, marking as resolved.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #44155 | Tue Mar 03 10:08:58 MST 2015 | patrick.corless | |
| Files Changed | ||||
|
MODIFY
/icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontFactory.java
MODIFY
/icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontDescriptor.java
MODIFY
/icepdf/trunk/icepdf/core/src/org/icepdf/core/pobjects/fonts/FontManager.java
|
| Status | Resolved [ 5 ] | Closed [ 6 ] |
I've spend some time looking at this this morning. The font in question is a type CIDFontType0C and there is indeed something funky happening with the encoding. The font is in question has a Adobe Standard encoding but for some reason we are treating it as an Identity-h. Further investigation into 5176 CFF specification is needed as well as verifying any font program parsing issues.