ICEpdf
  1. ICEpdf
  2. PDF-223

CID font not correctly rendered

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 4.1.1
          • Fix Version/s: 4.2
          • Component/s: Core/Parsing
          • Labels:
            None
          • Environment:
            pro version, ok on OS release
          • Assignee Priority:
            P1

            Description

            The fonts in question CID based and have toUniode mapping which is why the OS version work OK as does PRO text selection, copy/paste. I'll have to look closer but CID font are loading correctly we just not getting the correct glyphs.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Patrick Corless added a comment -

              Currently no test file to work against. Moving issue out of 4.2 target stream.

              Show
              Patrick Corless added a comment - Currently no test file to work against. Moving issue out of 4.2 target stream.
              Hide
              Permalink
              Patrick Corless added a comment -

              Retargeting 4.2, got the file.

              Show
              Patrick Corless added a comment - Retargeting 4.2, got the file.
              Hide
              Permalink
              Patrick Corless added a comment -

              This turned out to be fairly complicated, many attempts were made to try and load the correct toUnicode cmap file for the fonts in question but I was always 29 characters on the glyph indexes. Normally the fonts in question CID would have a corresponding embedded font but this document did not.

              I've updated the Font class to stop the font initialization if the the type0 cid font doesn't have an embedded font file. The content parser can pick up on the null initialization and fall back to awt font loading which can handle the toUnicode mapping better.

              Ideally an Nfont solution would be better but the fix as is should help load other documents like this.

              Show
              Patrick Corless added a comment - This turned out to be fairly complicated, many attempts were made to try and load the correct toUnicode cmap file for the fonts in question but I was always 29 characters on the glyph indexes. Normally the fonts in question CID would have a corresponding embedded font but this document did not. I've updated the Font class to stop the font initialization if the the type0 cid font doesn't have an embedded font file. The content parser can pick up on the null initialization and fall back to awt font loading which can handle the toUnicode mapping better. Ideally an Nfont solution would be better but the fix as is should help load other documents like this.
              Hide
              Permalink
              Patrick Corless added a comment -

              Revisited the problem and manged to figure out why I wasn't getting the correct glyph for the specifed toUnicode value. In this case I needed to insure the CIDToGIDMap was assigned so that the toUnicode map could be used to find the right GID. Pretty simple in hindsight.

              Show
              Patrick Corless added a comment - Revisited the problem and manged to figure out why I wasn't getting the correct glyph for the specifed toUnicode value. In this case I needed to insure the CIDToGIDMap was assigned so that the toUnicode map could be used to find the right GID. Pretty simple in hindsight.

                People

                • Assignee:
                  Patrick Corless
                  Reporter:
                  Patrick Corless
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: