Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 5.0.4
-
Fix Version/s: 5.0.5
-
Component/s: Font Engine
-
Labels:None
-
Environment:icepdf
-
Salesforce Case Reference:
Description
Note that this is a regression from 4.3.4 which worked correctly.
pdf file is located in iceads:/Users/pcorless/PDF-Jiras as well as png screenshot of how text rendered in 4.3.4.
pdf file is located in iceads:/Users/pcorless/PDF-Jiras as well as png screenshot of how text rendered in 4.3.4.
Activity
Judy Guglielmin
created issue -
Judy Guglielmin
made changes -
Field | Original Value | New Value |
---|---|---|
Salesforce Case Reference | 5007000000XThqUAAT |
Judy Guglielmin
made changes -
Security | Private [ 10001 ] |
Patrick Corless
made changes -
Fix Version/s | 5.0.5 [ 11373 ] |
Patrick Corless
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Patrick Corless
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
The PDF content stream is technically malformed for example the following postscript defines the second line of text:
[(\Ü) 2.167969 ... 2.167969(ü) -3.847656(\ä\ä\ä) ...
Which renders as ü.
The problem being that \ is supposed to be used to define a octal number \ddd and not an escaped character. The problem here is that Acrobat renders it and thus we must. A small tweak to our lexer is needed, should be relatively low risk at octal definitions aren't that common.