Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 6.3.2
-
Fix Version/s: 6.3.3
-
Component/s: Colour
-
Labels:None
-
Environment:any
-
Support Case References:Support Case 14455:- https://icesoft.my.salesforce.com/5000g000024MDal
Description
The PDF in question contains some vector graphics on the second page. The colour space is DeviceN [cyan, Magenta, yellow], uses a type 4 function for the tint and the alternative colour space is CMYK. The functin 4 is parsed and executed correctly which is nice to see.
However the color array shouldn't be reversed or at least it rendered correctly if not revered. There is some code around detecting cymk colour and applying some fuzzy logic to process a three channel colour as deviceCMYK. I'll need to go back and find the related bugs. I fix should be possible just need to avoid breaking something else.
However the color array shouldn't be reversed or at least it rendered correctly if not revered. There is some code around detecting cymk colour and applying some fuzzy logic to process a three channel colour as deviceCMYK. I'll need to go back and find the related bugs. I fix should be possible just need to avoid breaking something else.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Support Case References | Support Case 14455:- https://icesoft.my.salesforce.com/5000g000024MDal |
| Fix Version/s | 6.3.3 [ 13282 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Summary | DeviceN color space reveral | DeviceN color space reversal |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #53124 | Wed Dec 11 21:05:44 MST 2019 | patrick.corless | |
| Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/core/core-awt/src/main/java/org/icepdf/core/pobjects/graphics/ShadingType3Pattern.java
MODIFY
/icepdf/trunk/icepdf/core/core-awt/src/main/java/org/icepdf/core/pobjects/graphics/DeviceN.java
|
Marking as fixed, also took some time to do some refactoring to the core parser to standardize how we work with colour arrays. Should speed things up too.
Show
Patrick Corless
added a comment - Marking as fixed, also took some time to do some refactoring to the core parser to standardize how we work with colour arrays. Should speed things up too.
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Finally cracked this nut. The issue was partly in how we handle the Device colour space with regards to colour names and the other was how we order the colour data in the Type 3 Shading implementation. The DeviceN color space was originally setup for the content parser where colour data is parsed in reverse so we do a lot of revering colour data in various ways all over the code base.
I might take a little time and clean this up as well.