You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2009/09/08 22:48:34 UTC
DO NOT REPLY [Bug 47805] New: [PATCH] implements color pcl output
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
Summary: [PATCH] implements color pcl output
Product: Fop
Version: all
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: pcl
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: jimg@docmagic.com
--- Comment #0 from jim gabriel <ji...@docmagic.com> 2009-09-08 13:48:33 PDT ---
Created an attachment (id=24232)
adds color pcl support
The implementation to support color pcl is automatic. If a color image is
used, then color pcl is output. Otherwise, the output remains B/W.
--
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
Posted by bu...@apache.org.
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
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
--- Comment #1 from Max Berger <ma...@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.
DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
--- Comment #3 from Max Berger <ma...@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
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
Glenn Adams <ga...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #6 from Glenn Adams <ga...@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
Posted by bu...@apache.org.
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.
DO NOT REPLY [Bug 47805] [PATCH] implements color pcl output
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
--- Comment #2 from Chris Bowditch <bo...@hotmail.com> 2009-09-09 00:23:34 PDT ---
Thanks for the patch.
The current version of the PCL Renderer generates PCL5, but after the PCL5
standard was released there were further standards: PCL5c (for color) and
PCL5e. Older printers may only support PCL5, so if you send it PCL5c it will
fail to print. Therefore this behaviour should be controlled from a
configuration option in fop.xconf. So that existing users of the PCL Renderer
can carry on generating PCL5 and not suddenly start getting PCL5c.
Of course nowadays there is also PCL6, but that is a whole new topic!
--
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
Posted by pohukai <ji...@docmagic.com>.
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://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf
> http://h20000.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
Posted by pohukai <ji...@docmagic.com>.
http://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf
http://h20000.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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
black&white 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 bugzilla@apache.org wrote:
> >
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
> >
> >
> >
> > --- Comment #4 from Jeremias Maerki <je...@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
Posted by pohukai <ji...@docmagic.com>.
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 bugzilla@apache.org wrote:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
>
>
>
> --- Comment #4 from Jeremias Maerki <je...@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
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47805
--- Comment #4 from Jeremias Maerki <je...@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.