DO NOT REPLY [Bug 48048] [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area )
https://issues.apache.org/bugzilla/show_bug.cgi?id=48048 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremias Maerki jerem...@apache.org 2009-11-25 07:05:24 UTC --- Thanks for spotting this and sending a patch! It is applied now: http://svn.apache.org/viewvc?rev=884129view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48211] How to change/set 128-bit RC4 encryption level in secured PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=48211 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Component|general |pdf Version|0.95|1.0dev Severity|major |enhancement --- Comment #1 from Jeremias Maerki jerem...@apache.org 2009-11-25 07:12:11 UTC --- Support for encryption larger than 40bits has not been implemented, yet. Patches are welcome. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48255] PDFRectangle
https://issues.apache.org/bugzilla/show_bug.cgi?id=48255 --- Comment #1 from Jeremias Maerki jerem...@apache.org 2009-11-25 07:27:58 UTC --- Patches are welcome to improve FOP. PDFRectangle could be changed to be a subclass of PDFArray and PDFLink should actually be a PDFDictionary subclass at some point. Want to give it a try? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #3 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-11-25 07:39:33 UTC --- I have checked this bug with FOP 0.95 version initially, but later understood that FOPTrunk is having this problem instead of FOP 0.95. The Bitmaps are rendering according the image mode configuration (either b+w or color) in both FOP 0.95 and FOPTrunk. The problem is with SVGs, the image mode is not respected in case of SVGs in FOPTrunk. So, It is a valid bug in FOPTrunk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48264] [PATCH] PS Renderer failed to process images using CMYK color space
https://issues.apache.org/bugzilla/show_bug.cgi?id=48264 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jeremias Maerki jerem...@apache.org 2009-11-25 07:55:58 UTC --- So the code was basically already there (due to the JPEG CMYK support) and only had to be enabled. Your patch could actually be further simplified. The check for the component count is not necessary as that is done inside ImageEncodingHelper already. Patch applied: http://svn.apache.org/viewvc?rev=884159view=rev Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311 --- Comment #44 from Jeremias Maerki jerem...@apache.org 2009-11-25 12:01:00 UTC --- (In reply to comment #43) Hi All, We have found one issue during testing this new feature. The issue lies in PageBoundaries.java in calculating crop/bleed boxes. The offsets order is: [top, right, bottom, left], so to calculate Y size of the final box we should use the 'bottom' instead of 'top' offset : return new Rectangle(originalRect.x - coords[3], -originalRect.y - coords[0], +originalRect.y - coords[2], originalRect.width + coords[3] + coords[1], originalRect.height + coords[0] + coords[2]); Please find in the attachments the fix patch. (Comment#41) Also I have attached the full patch for FOP-0.95 version (Comment#42) if somebody will have a need to use this feature with previous version. I've taken a look at that. Thanks for spotting the problem, Boris, but your solution was not the right one. But you brought me on the right track. I've just found out what our mistake is: PDF specifies the boxes as rectangles which are defined as llx lly urx ury (i.e. lower left to upper right). But our/FOP's Rectangle2D objects are actually upper left to lower right. In PageBoundaries we're still in FOP's coordinate system which starts at the upper left. So we have to calculate the right values for the default PDF coordinate system. Boris' change would have broken a test case and created a bug on the bitmap production side. So the right change is to do a transformation from FOP's internal coordinate system to PDF's default one in PDFDocumentHandler: http://svn.apache.org/viewvc?rev=884241view=rev Boris, can you please verify that this fix also work for you? Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #4 from Jeremias Maerki jerem...@apache.org 2009-11-25 12:10:42 UTC --- Peter, I understand the bug report (all colors should ideally be transformed to grayscales when AFP output is configured to 8bit grayscales), but what I'm curious about is whether the current behaviour actually caused a problem on your side. So far I have no reports that the colors cause any problems. The systems seem to be able to handle them correctly, even on a monochrome system. Only the bitmap images are currently reduced in color depth most of all because that has a huge impact on file size. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Thoughts on Bug 48237
Hi Peter See my question I attached to bug 48237. But of course, the ideal case is to have the color converted properly if possible. On 24.11.2009 15:30:30 Peter Hancock wrote: At present FOP does not respect an image color setting of 'b+w' when rendering svg to afp (see Bug 48237) According to the AFP spec ( http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320DT=20001002123303) it does not seem possible to specify a grayscale color space, and so my question is how should colour be controlled? I think there are two general approached besides just using RGB: - CMYK with only the K component (that is a clear indication that we want a fully black color or shades of that) - using a Highlight color space (assuming black as a highlight/spot color) But I have no experience with highlight colors on AFP, so I can't tell if it would work. Since AFPGraphics2D is responsible for setting the color on the MODCA GraphicsObject prior to calling drawing methods, would a sensible fix to the problem be to convert the awt.Color before calling this setter? Probably. I have some tentative need to have a general color conversion facility for FOP (not just AFP). For example, at some point we may want to have color conversion from sRGB to CMYK. Another use case for a color converter would be a detector which would convert any grayscale color (R, G, B or C, M, Y with equal values) to a CMYK value (with only K) which might in certain situations improve output quality because otherwise a RIP might be inclined to mix black by mixing CMY. I can imagine that a general interface could be defined for which there could be multiple implementations depending on the use case and configuration. For the present case, one implementation of that interface per color setting could be written for AFP. Not sure, just brainstorming. Any thoughts would be most welcome, Pete Jeremias Maerki
