[jira] [Commented] (PDFBOX-833) Wrong encoding with Type1C font when specific encoding is defined

["Luis Bernardo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631408#comment-13631408 ] 

Luis Bernardo commented on PDFBOX-833:
--------------------------------------

I think I may have bumped into this bug and other related ones (wrong mapping of character codes to glyphs with Type1C fonts). I investigated and came up with a fix which I am attaching. The issue was complicated by apparently some bug in Sun JDK's native code (used by StandardGlyphVector) that resulted in character codes being mapped to the missing glyph. To get around this apparent bug the patch includes a workaround to do the mapping directly (this requires the use of reflection). In OpenJDK, which uses Freetype for the native code, this particular bug does not happen, but there is other issue that this patch also addresses (Freetype expects uppercase hexadecimal names).

I am attaching also part of the sample document that I used to investigate this, together with image outputs before and after the patch is applied that show what the issue is. 
                
> Wrong encoding with Type1C font when specific encoding is defined
> -----------------------------------------------------------------
>
>                 Key: PDFBOX-833
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-833
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Parsing
>    Affects Versions: 1.3.1
>            Reporter: Timo Boehme
>
> The Type1C font implementation overwrites the encoding() method of PDFont base class. This results in a lookup of codes to characters as defined in the font.
> However if an encoding is explicitly given (like WinAnsiEncoding) this leads to wrong results if encoding codes do not match glyph codes.
> In a test document (which unfortunately I cannot make public - an article from Elsevier) a Type1C font is embedded which defines a copyright sign at glyph position 259. The encoding is defines as WinAnsiEncoding. Text characters are defined corresponding to the WinAnsiEncoding. In case of the copyright sign it is 0xa9 (169) where the font has glyph 'quotesingle' defined.
> Since currently I have no other test cases I implemented following workaround for WinAnsiEncoding (which might be relaxed to other PDF encodings as well:
> in PDType1CFont.encode() I start with:
> if ( getEncoding() instanceof WinAnsiEncoding )
>   // use PDFont encoding
>   return super.encode( bytes, offset, length );
> This resolves the encoding problems for text extraction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira