ICEpdf
  1. ICEpdf
  2. PDF-561

Graphic state or text fill mode is not being property respected when painting text.

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 5.0.1
          • Fix Version/s: 5.0.1
          • Component/s: Core/Parsing
          • Labels:
            None
          • Environment:
            any
          • Salesforce Case Reference:

            Description

            The file in question has title/section text which should be drawn as plain white text. Instead ICEpdf is stroking with white correctly but filling with black incorrectly. The file can't be uploaded do to confidentiality.

              Activity

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

              Spent a bit of time looking into this one. The first problem is related to the new ContentParser that is created to parse the Type3 glyph. This new content parser has no visiblity to the parent graphics context and thus will always have the default black color defined in a new Graphics state. The good news is that that the TextSprite has this information has this information and can be passed into the font when the drawEstring() is called.

              The second problem here is that we use glph cache to try and speed up the paint time. This cache is indexed by the character name/number which doesn't take into account if a glyph is painted using a different fill color. Once again not to terrible a problem as we can change up the key to take into account the fill color.

              Show
              Patrick Corless added a comment - Spent a bit of time looking into this one. The first problem is related to the new ContentParser that is created to parse the Type3 glyph. This new content parser has no visiblity to the parent graphics context and thus will always have the default black color defined in a new Graphics state. The good news is that that the TextSprite has this information has this information and can be passed into the font when the drawEstring() is called. The second problem here is that we use glph cache to try and speed up the paint time. This cache is indexed by the character name/number which doesn't take into account if a glyph is painted using a different fill color. Once again not to terrible a problem as we can change up the key to take into account the fill color.
              Hide
              Permalink
              Patrick Corless added a comment -

              Updated the NFontType3 class as described above. Fill colours are now correctly displayed in the final render.

              Show
              Patrick Corless added a comment - Updated the NFontType3 class as described above. Fill colours are now correctly displayed in the final render.

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: