number-up > 1 incompatibel with foomatic? [was: Blank pages when printing Mozilla PostScript file with 2 pages/sheet on postscript printer ]

[Hartvig Ekner]

Thanks a lot for all the help finding the root cause. Is there somewhere else I
could/should post/email your findings to make sure the issue is resolved, or at
least looked at by the relevant people?

Also, how come it works when you're printing at your end, and it fails here? Is
the problem linked to a specific version of foomatic? And why do I only see the
problem with Mozilla prints, not any other application?

Best regards,

Hartvig


Helge Blischke wrote:
> Well, it is sort of a foomatic issue: for some reason (I don't know
> why) Ghostsceript is called with the pswrite device, and that inserts
> the line
> ---snip---
> 595 842 /a4 setpagesize
> ---snip---
> into the page setup section of every page. The "setpagesize" in turn
> calls (in case of level 2 or 3) the setpagedevice operator, which 
> in turn completely defeats CUPS' number-up stuff: the page size for
> the logical page is reset to the original (A4 in this case), and the
> current page is erased, thus you get a blank page.
> 
> I hope the foomatic guys will read this.
> 
> Helge
> 
> 
> Hartvig Ekner wrote:
> 
>>I put a new trace-file at:
>>
>>    http://www.ekner.info/traces.tgz
>>
>>This time it is a .tgz file due to limitations at my hosting company :-) It contains
>>three files: The original mozilla.ps output (captured with print-to-file from mozilla)
>>and two traces captured by replacing foomatic-rip with a small script. The two foomatic-rip
>>traces are done with 1-up printing (TRACE.1up) and 2-up printing (TRACE.2up). (Note that
>>the argument dumps in the first few lines of each trace need to be removed to get clean postscript
>>data).
>>
>>I can "GGV" the TRACE.1up trace, and it looks as expected. When opening the TRACE.2up trace,
>>I can see that GGV draws something, and then it immediately after clears it, so that I'm looking
>>at a blank page (which is also what the printer outputs). So I think the answer lies within the
>>TRACE.2up file. Doing a diff between these two trace files reveals:
>>
>>[hje at hje-6 tmp]$ diff TRACE.1up TRACE.2up
>>2c2
>>< 24
>>---
>> > 25
>>6c6
>>< outputorder=normal number-up=1 page-border=single nowrap position=top-left Duplex=Notcapable PageSize=A4 Resolution=default PreFilter=No
>>---
>> > outputorder=normal number-up=2 page-border=single nowrap position=top-left Duplex=Notcapable PageSize=A4 Resolution=default PreFilter=No
>>16c16
>>< %%CreationDate: 2004/10/26 11:19:03
>>---
>> > %%CreationDate: 2004/10/26 11:19:33
>>97a98,101
>> > userdict/ESPsave save put
>> > 24.0 48.0 translate
>> > 547.0 0.0 translate 90 rotate
>> > 0.0 1.1 translate 0.647 0.647 scale
>>99,100c103,104
>>< 0.240 setlinewidth 0 setgray newpath
>>< 26.2 50.2 542.5 765.5 ESPrs
>>---
>> > 0.371 setlinewidth 0 setgray newpath
>> > 3.5 3.5 588.0 835.0 ESPrs
>>101a106
>> > 0 0 595.0 842.0 ESPrc
>>1251a1257,1264
>> > userdict /ESPsave get restore
>> > userdict/ESPsave save put
>> > 24.0 48.0 translate
>> > 547.0 0.0 translate 90 rotate
>> > 385.0 1.1 translate 0.647 0.647 scale
>> > 0 0 595.0 842.0 ESPrc
>> >
>> > userdict /ESPsave get restore
>>1252a1266
>> > 595.0 0.0 translate 90 rotate
>>
>>But I'm not post-script capable enough to see what the problem is.....
>>
>>Best regards,
>>
>>/Hartvig
>>
>>Helge Blischke wrote:
>>
>>>Well, your sample file prints ok here, both normal and with the
>>>number-up=2 option. Moreover, I printed some web pages from mozilla
>>>with this option successfully.
>>>How is your mozilla printing configured? I use "kprinter -stdin"
>>>as printer setup in mozilla, and this works with both CUPS 1.1.18
>>>and 1.1.19 (the versions in use at our site).
>>>
>>>Perhaps you could try to intercept the data that go into the
>>>foomatic RIP (e.g. temporarily replace foomatic-rip by a script
>>>that simply dumps the standard input to a file) and post that.
>>>
>>>You see, I've no proper idea what the issue might be (yet).
>>>
>>>Helge
> 
>