Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 5.0.6_P01
-
Fix Version/s: 5.0.7
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:PRO
-
Support Case References:Support Case #12934 - https://icesoft.my.salesforce.com/5007000000dyVuv
Description
A customer submitted a PDF that has missing Euro currency symbol. The reasoning for this is that the differences dictionary entry 164 -> /euro doesn't like up with the fonts encoding where /Euro is defined as a named.
Generally the upper/lower case start of the named character is an indicator of if the corresponding character's case. For example, 180 /Zcaron 184 /zcaron . That said the idea of capital Euro isn't relevant or at least as I see it.
I think ultimately we are looking at a document encoding issue but I think a work around can be applied to address the problem.
Generally the upper/lower case start of the named character is an indicator of if the corresponding character's case. For example, 180 /Zcaron 184 /zcaron . That said the idea of capital Euro isn't relevant or at least as I see it.
I think ultimately we are looking at a document encoding issue but I think a work around can be applied to address the problem.
The Encoding class method getChar(String name):char does the ./euro lookup and returns a zero value. If case wasn't taken into account then the /euro lookup should have returned 164. However we can't simply to a String.equalsIgnoreCase() as /A and /a be treated as one and all the text will be automatically make upper case.
No minimize regressions I've added a simple check for "euro" when the method is called and we make the case sensitive adjustment. Going forward this approach might need to be updated but for now will leave as is as it's our only test case.