DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 Glenn Adams gad...@apache.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #6 from Glenn Adams gad...@apache.org 2012-04-11 03:21:43 UTC --- increase priority for bugs with a patch -- 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 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #5 from Glenn Adams gl...@skynav.com 2012-04-07 01:42:55 UTC --- resetting P2 open bugs to P3 pending further review -- 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 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- 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: DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
On 14.09.2009 22:01:08 pohukai wrote: Thank you for your comments. 1) Auto-detection wasn't meant to be detecting the actual printer capabilities but meant to determine whether grayscaling of images would take place. See line 403 of PCLGenerator. In our current use of FOP 0.20x, we have b/w images but wasn't sure how to force b/w when a color image was implemented. Ah, I see. 2) I'm new to FOP and all of it's capabilities and configuration usage. I think a lot of what I really need should be and can be handled there. I wasn't fully aware of this file. 3) I didn't change anything with scaling of the images...at least not intentionally. In my testing, with LOTS of jpg, bmp, these render correctly and print on the PCL5c perfectly. I should have phrased that differently. Sorry. The conversion to blackwhite currently does the scaling, too, because PCL can't scale images itself. You probably just missed that you'd need to scale the color images to get them to the right size. I'd like to implement TIFF compression just to get the PCL file size down. You mean CCITT compression, don't you. FYI, I've started a CCITT Group 4 compressor some time ago, but haven't finished, yet. It's kind of a little pet project of mine which I only pursue while travelling. Let me know when you start on that. I can pass you my unfinished code if you want. Please note that CCITT compression is not just interesting for PCL output but also for PDF, PostScript and AFP! And besides that Apache Commons Sanselan could also use that. So it's going to be important to keep the compressor general and not tied to PCL. 4) I wasn't aware of the 'coding' style. I didn't see a style guideline. Can you point me to one? I was paranoid of making any changes and only placed my initials in there for my reference as I was testing. Of course, these would be removed. Our conventions can be found here: http://xmlgraphics.apache.org/fop/dev/conventions.html Please also note the Checkstyle config file in FOP's root directory that can help you match our conventions. Thanks!!! JimG Bugzilla from bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #4 from Jeremias Maerki jerem...@apache.org 2009-09-10 00:25:14 PDT --- I'm not seeing any auto-detection in the patch. What do you refer to? The offline PCL production doesn't allow for bi-directional querying of the printer to get its capabilities so there can't be any auto-detection anyway. As Chris noted, not all printers support PCL5C. My Brother HL-1250, for example, prints out garbage with the patch applied. IMO, it's imperative to have a configuration option to enable/disable PCL5C functionality. I see various issues with the patch: - the output is no longer compatible with PCL5 printers. - I got ByteArrayOutOfBoundsExceptions with many of my usual test images. - PJL support is disabled in a hard-coded fashion (Jim, you can disable PJL in configuration, no need to do that in code: http://xmlgraphics.apache.org/fop/trunk/output.html#pcl-configuration) - If I interpreted this correctly from my short test, the color images don't get scaled if the image is not used in its intrinsic size. - PCLGenerator.paintBitmap() converts an image to monochrome even though its later rendered in color which gives away lots of performance. Image conversion is an expensive operation. - an updated patch should be a bit closer to FOP's coding style (no tabs in particular). Also, you should remove your initials spread throughout the code. Due attribution will be given in the status file and the commit messages. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- View this message in context: http://www.nabble.com/DO-NOT-REPLY--Bug-47805--New%3A--PATCH--implements-color-pcl-output-tp25353950p25442523.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
http://h2.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf http://h2.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf I was planning to implement HP's flavor of TIFF. See page 15-17 -- View this message in context: http://www.nabble.com/DO-NOT-REPLY--Bug-47805--New%3A--PATCH--implements-color-pcl-output-tp25353950p25458427.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
Just to further clarify. The TIFF format I was referring to is for the embedded PCL graphics (RAW, RLE, and TIFF). I wouldn't use HP's TIFF algorithm as an exporting format like PDF, PCL, or other output formats supported by FOP. pohukai wrote: http://h2.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf http://h2.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf I was planning to implement HP's flavor of TIFF. See page 15-17 -- View this message in context: http://www.nabble.com/DO-NOT-REPLY--Bug-47805--New%3A--PATCH--implements-color-pcl-output-tp25353950p25458683.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
Thank you for your comments. 1) Auto-detection wasn't meant to be detecting the actual printer capabilities but meant to determine whether grayscaling of images would take place. See line 403 of PCLGenerator. In our current use of FOP 0.20x, we have b/w images but wasn't sure how to force b/w when a color image was implemented. 2) I'm new to FOP and all of it's capabilities and configuration usage. I think a lot of what I really need should be and can be handled there. I wasn't fully aware of this file. 3) I didn't change anything with scaling of the images...at least not intentionally. In my testing, with LOTS of jpg, bmp, these render correctly and print on the PCL5c perfectly. I'd like to implement TIFF compression just to get the PCL file size down. 4) I wasn't aware of the 'coding' style. I didn't see a style guideline. Can you point me to one? I was paranoid of making any changes and only placed my initials in there for my reference as I was testing. Of course, these would be removed. JimG Bugzilla from bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #4 from Jeremias Maerki jerem...@apache.org 2009-09-10 00:25:14 PDT --- I'm not seeing any auto-detection in the patch. What do you refer to? The offline PCL production doesn't allow for bi-directional querying of the printer to get its capabilities so there can't be any auto-detection anyway. As Chris noted, not all printers support PCL5C. My Brother HL-1250, for example, prints out garbage with the patch applied. IMO, it's imperative to have a configuration option to enable/disable PCL5C functionality. I see various issues with the patch: - the output is no longer compatible with PCL5 printers. - I got ByteArrayOutOfBoundsExceptions with many of my usual test images. - PJL support is disabled in a hard-coded fashion (Jim, you can disable PJL in configuration, no need to do that in code: http://xmlgraphics.apache.org/fop/trunk/output.html#pcl-configuration) - If I interpreted this correctly from my short test, the color images don't get scaled if the image is not used in its intrinsic size. - PCLGenerator.paintBitmap() converts an image to monochrome even though its later rendered in color which gives away lots of performance. Image conversion is an expensive operation. - an updated patch should be a bit closer to FOP's coding style (no tabs in particular). Also, you should remove your initials spread throughout the code. Due attribution will be given in the status file and the commit messages. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- View this message in context: http://www.nabble.com/DO-NOT-REPLY--Bug-47805--New%3A--PATCH--implements-color-pcl-output-tp25353950p25442523.html Sent from the FOP - Dev mailing list archive at Nabble.com.
DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #3 from Max Berger m...@berger.name 2009-09-09 23:17:53 PDT --- Just got an email from Jim, which I will summarize: - B/W PCL is much smaller than color PCL (therefore, the proposed patch makes a lot of sense) - Older Printers cannot print color PCL directly, is has to be converted to b/w pcl in a separate step. Now the only question remains if the auto-selection method (as in the patch) should be used or a configuration method. I personally prefer auto-selection, but the fop tradition is to be more conservative and let the user decide through configuration. Max And some background reading: http://en.wikipedia.org/wiki/Printer_Command_Language (Contains Links to PCL spec) -- 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 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #4 from Jeremias Maerki jerem...@apache.org 2009-09-10 00:25:14 PDT --- I'm not seeing any auto-detection in the patch. What do you refer to? The offline PCL production doesn't allow for bi-directional querying of the printer to get its capabilities so there can't be any auto-detection anyway. As Chris noted, not all printers support PCL5C. My Brother HL-1250, for example, prints out garbage with the patch applied. IMO, it's imperative to have a configuration option to enable/disable PCL5C functionality. I see various issues with the patch: - the output is no longer compatible with PCL5 printers. - I got ByteArrayOutOfBoundsExceptions with many of my usual test images. - PJL support is disabled in a hard-coded fashion (Jim, you can disable PJL in configuration, no need to do that in code: http://xmlgraphics.apache.org/fop/trunk/output.html#pcl-configuration) - If I interpreted this correctly from my short test, the color images don't get scaled if the image is not used in its intrinsic size. - PCLGenerator.paintBitmap() converts an image to monochrome even though its later rendered in color which gives away lots of performance. Image conversion is an expensive operation. - an updated patch should be a bit closer to FOP's coding style (no tabs in particular). Also, you should remove your initials spread throughout the code. Due attribution will be given in the status file and the commit messages. -- 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 47805] [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805 --- Comment #1 from Max Berger m...@berger.name 2009-09-08 23:37:49 PDT --- Jim, I don't understand the motivation behind this: is there an advantage of NOT using color PCL? Are there some printers which don't support it correctly, or is the image quality better? Is the result smaller? Second: There are some things which are duplicated in your patch, in particular the lines surrounding the *v6W command. They could be refactored into a private methods. Max -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
