This is probably a lack of definition/documentation about intended behavior than a a bug, see background. http://bugs.ghostscript.com/show_bug.cgi?id=690733#c26 Currently ghostscript read pdf's dimensions and passes it on, but ghostpcl doesn't; so for unusual size pdf's, the generated rasters are clipped comparing gs -> ppm gs -> pxl -> ghostpcl -> ppm . Will attach example.
Created attachment 5501 [details] one such pdf This is one of attachement 5494. Try this: gs -dBATCH -dNOPAUSE -r600 -sDEVICE=pxlcolor -sOutputFile=out.pxl $1 gs -q -dBATCH -dNOPAUSE -r600 -sDEVICE=ppmraw -sOutputFile=out.ppm $1 pspcl6 -dBATCH -dNOPAUSE -r600 -sDEVICE=ppmraw -sOutputFile=tigerfrompxl.ppm out.pxl the ppm generated from gs is horiontal; the pxl also seems to have a larger dimensions than vertical in the bounding box (from pxldis). This bounding box info is ignore in pspcl, although the media is autoselect which probably is why ghostpcl just use a default (a4/letter portrait) which result in clipping. May be what I am asking for is that ghostpcl should optionally decide from boundingbox what size the output should be.
Yes there is a feature request for this in pcl5 and it could be extended to support pcl xl. Unfortunately I don't think it will be available in time to be useful for this problem. Since your NDA is complete please contact Ralph Giles ralph.giles@artifex.com for test files and access to private attachments. He'll need a public key.
Is there some reason the pxlcolor and pxlmono devices cannot use the attribute CustomMediaSize with the BeginPage operator? That support was added to Artifex pcl xl some time ago.
For the purpose of regression testing of the parent bug, I assume pspcl6 takes -gXxY so some extra processing of the original may be possible to hook that up quickly. At the moment pcl6 behaves a bit like old ghostscript 5/6-ish as far as embedded media size instructions/suggestions (i.e. ignore document DSC suggestions but take note of command-line specified ones), I think. I guess the question is, what is the intended behavior? ATM pxlmono/pxlmono emits media autoselect, which means it is up to the printer or pcl6 to choose size. To not break any current workflow, it is probably best for pcl6 to try to guess the media size from the boundingbox (eventually). (Actually emitting custom media size might break some current use of pcl6).
I don't think PCL implements the -gWWWxHHH option. I know it's on the plmain 'help' list given when you just invoke pcl6, but Henry told me (March 2008) that this was not implemented.
Ray is correct, -g does not work or is it planned to work in the near future. I'll remove it from the usage statement. > I guess the question is, what is the intended behavior? ATM pxlmono/pxlmono > emits media autoselect, which means it is up to the printer or pcl6 to choose > size. To not break any current workflow, it is probably best for pcl6 to try to > guess the media size from the boundingbox (eventually). > (Actually emitting custom media size might break some current use of pcl6). The eAutoSelect decision was made by a previous Artifex employee, I don't think workflow was a factor in his coding choice. Aside from assuming the code was written purposefully to fulfill some requirement do you know of any other reason we should leave it to the printer? I don't know of other devices that work that way by default, I'd think custom paper sizes is really the way to go here.
Some HP printer's firmware has a configurable option about what to do if the incoming paper size does not match the papersize in the tray (and can autodetect, what paper size is currently in the tray). The default is 'prompt user' - if you sent letter size job to printers stocked only with A4 paper, the LCD would light up and ask if you really want to go ahead - which is quite annoying. I don't know if custom size with dimension which "happens" to match size exactly would trigger such behavior.
I think we are confused about this, eAutoSelect is a MediaSource attribute which doesn't need to be specified at all. That has nothing to do with media source (tray), if we can't find a matching paper size in gdevxput.c we should use a custom paper size, instead of pxaMediaSize we use pxaCustomMediaSize, not default to Letter. The tray attribute eAutoSelect can be left as it is. Do you want me to make this bountiable and assign it to you?
> eAutoSelect is a MediaSource attribute which > doesn't need to be specified at all. That has nothing to do with media source > (tray), if we can't find a matching paper size in gdevxput.c we should use a > custom paper size, instead of pxaMediaSize we use pxaCustomMediaSize, not > default to Letter. Yes, I looked at the code and the spec, indeed MediaSource (tray) is optional but MediaSize is mandatory; the current code does try to emit paper code for defined paper size; it is just a bit wrong in the case of odd input sizes to use letter-size instead of custom-size. > Do you want me to make this bountiable and assign it to you? Yes, if that's alright.
Created attachment 5539 [details] customsize patch + bug fix. This implements the CustomMediaSize as discussed; on the way I also found an old bug with the pxl utility code which was just written but not used (until now). See comments within.
patch committed as r10231 .