Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.1.1
-
Fix Version/s: 4.2
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:-
-
Assignee Priority:P2
Description
***************
DecimalFormat for sk_SK locale returns the number "1,000.00" formatted as "1 000,00" with 0xa0 (no-break space) as a decimal group separator. IcePDF v4.1.0-pro (and also the other versions) library has problems with correctly displaying this character (it shows it, perhaps, as two space characters) while the Acrobat Reader shows the PDF file with such a number correctly.
So we have to use force here to convert all 0xa0 characters in the resulting formatted string to 0x20 (space) so that they were handled correctly with the IcePDF library.
http://www.fileformat.info/info/unicode/char/a0/index.htm
In addition, this bug occurs only when the Java SansSerif font is used and it occurs on both, Windows and Linux, systems.
***************
However, I am unable to verify the issue with 4.1.1 Pro since the PDF does not display correctly. Instead of seeing 65 536,00 displayed in the PDF, I only the see the number 6.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | screenshot-1.jpg [ 12709 ] |
| Attachment | 9550_test.pdf [ 12710 ] |
| Salesforce Case | [] | |
| Fix Version/s | 4.2 [ 10243 ] |
Screenshots were taken on Mac OSX 10.6.4. I will post the log file.
| Attachment | 9550_Mac_log [ 12717 ] |
The only suspicious portion of the log files is:
Nov 30, 2010 4:21:17 PM org.icepdf.core.pobjects.fonts.FontFactory <clinit>
FINE: NFont font library was not found on the class path
Nov 30, 2010 4:21:17 PM org.icepdf.core.pobjects.fonts.ofont.Font init
FINE: null - WinAnsiEncoding Helvetica org.icepdf.core.pobjects.fonts.ofont.OFont@4e84f566 true
Nov 30, 2010 4:21:17 PM org.icepdf.core.util.ContentParser parse
| Salesforce Case | [] | |
| Assignee Priority | P2 |
The PDF in question is pretty standard and the text is in plain ascii.
(65 536,00)Tj and (65 536,00)Tj respectively.
The log would indicate an OS version is being used instead of the PRO. That said the encoding is WinAnsiEncoding and thus maybe there is something else wrong.
I couldn't reproduce this on Windows with the ghost script fonts installed.
| Salesforce Case | [] | |
| Assignee | Patrick Corless [ patrick.corless ] | Tyler Johnson [ tyler.johnson ] |
| Assignee | Tyler Johnson [ tyler.johnson ] | Ken Fyten [ ken.fyten ] |
Just retested this using ICEpdf and ICEpdf PRO with svn rev. # 24106 from March 8th, 2011. Problem exists in both versions.
| Assignee | Ken Fyten [ ken.fyten ] | Patrick Corless [ patrick.corless ] |
There are always a pain the debug. I couldn't find anything wrong with how we where encoding the font. The only work around I could fine was to update the encodingLatin.txt encoding file to have a new entry for space where 240 octal is assigned across the board (win, mac etc.). This address the missing width problem assigning the space width rather then the default font width.
Marking as resolved.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Salesforce Case | [5007000000E7M2Z] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Installing the ghostscript fonts should help out with the first issue the users is seeing. The PDF uses font substitution so it should look pretty good in both versions.
That's said the missing text might be a bigger problem with mac support. Any chance someone can confirm that the screenshot where taken on the Mac and if so can they post a debug level log file of the file loading so I can see what fonts are substituted or if there are any errors.
I see the issue with the OS version but not with the Pro version.