ICEpdf
  1. ICEpdf
  2. PDF-1170

Missing input fields values on page resize.

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 6.2.4
          • Fix Version/s: 6.2.5
          • Component/s: Core/Parsing
          • Labels:
            None
          • Environment:
            ALL
          • Support Case References:
            Support Case 14147:-https://icesoft.my.salesforce.com/5007000001kvaMs?srPos=0&srKp=500

            Description

            A client has discovered a very reproducable but strange bug with the input field components.

            STEPS TO REPRODUCE:
            1. Run icepdf-viewer.jar, click "No", open attached file
            2. Enter some text into "Full name of the centre", unfocus
            3. Click "Fit Width" tool and resize the window as wide as possible.
            Somewhere in the process text will disappear but will be available when
            editing textbox
            ACTUAL RESULTS:
            Text in first text box becomes invisible (despite it still present)
            EXPECTED RESULTS:
            Text should be always visible

              Activity

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

              This was a tricky one to track down. When we build the content stream for the first time when editing a input text content stream we correctly find and assign the form's resource for the /helv font. After garbage collection or page initialization the full content parser uses used to parse the form that holds the text annotations content stream.

              The bug is that we pick up on a font subset "asdzr+helvetica" as a valid font. The problem with this font is that it has a different character mapping and the glyphs are not mapped correctly and hence no content. I've made a small tweak to the Resources class to avoid such a corner case. Once this is done we correctly use the form's parent resources instead of the pages resource hierarchy.

              Show
              Patrick Corless added a comment - - edited This was a tricky one to track down. When we build the content stream for the first time when editing a input text content stream we correctly find and assign the form's resource for the /helv font. After garbage collection or page initialization the full content parser uses used to parse the form that holds the text annotations content stream. The bug is that we pick up on a font subset "asdzr+helvetica" as a valid font. The problem with this font is that it has a different character mapping and the glyphs are not mapped correctly and hence no content. I've made a small tweak to the Resources class to avoid such a corner case. Once this is done we correctly use the form's parent resources instead of the pages resource hierarchy.
              Hide
              Permalink
              Patrick Corless added a comment -

              Need to do a full QA round but pretty happy with this fix.

              Show
              Patrick Corless added a comment - Need to do a full QA round but pretty happy with this fix.

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: