Details
-
Type:
Bug
-
Status: Closed
-
Priority:
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
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
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #51799 | Mon Jul 31 13:26:16 MDT 2017 | patrick.corless | an AFM which should avoid potential mappings of CID font to non CID glyph assignment. |
| Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/core/core-awt/src/main/java/org/icepdf/core/pobjects/Resources.java
|
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #51731 | Mon Jul 10 10:41:53 MDT 2017 | patrick.corless | an AFM which should avoid potential mappings of CID font to non CID glyph assignment. |
| Files Changed | ||||
|
MODIFY
/icepdf/branches/icepdf-6.2.0/icepdf/core/src/org/icepdf/core/pobjects/Resources.java
|
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
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.
| Support Case References | Support Case 14145:- https://icesoft.my.salesforce.com/5007000001kvMSp | Support Case 14147:-https://icesoft.my.salesforce.com/5007000001kvaMs?srPos=0&srKp=500 |
| Support Case References | Support Case 14145:- https://icesoft.my.salesforce.com/5007000001kvMSp |
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 6.2.5 [ 13102 ] |
Need to do a full QA round but pretty happy with this fix.