Can you make the first page print from a different tray?

Kurt Pfeifle kpfeifle at danka.de
Fri Aug 11 01:48:20 PDT 2006


 -------------------------------------------------------------------
  [ Disclaimer: don't take my word for The Gospel on this subject.
    here, hence I've currently no working Samba + CUPS + Winword 
    setup around no means to verify my thoughts. ]
 -------------------------------------------------------------------

Adam Nielsen <a.nielsen at research.uq.edu.au> wrote (Friday 11 August 2006 08:35):
 
>> Printing from Windows/Word does already support selecting a different
>> first page paper tray. For *any* printer, *any* driver (where printer
>> has more than one tray). CUPS or not CUPS.
> 
> Yes, sorry, I'm not printing from Word normally, I was just using
> that to test the change.  The final print jobs will be generated 
> by Crystal Reports, 

Cr*p! I've seen so many weird problems when printing from Crystal 
Reports (for anything that involves non-default settings)....

> and the client for that is so limited that it won't even let you
> select a different printer (you can only print to your default
> printer.)  

Yes.

>> The hidden secret is to not look for the option in the printing dialog
>> itself. You have to use the "Page Setup"
> 
> I made sure both the first page and the rest of the document was 
> set to "Default Tray" here,

Well, "Default Tray" is... we don't know. We would have to look 
into the PPD for knowing this....

You're talking about printing from Winword now? Using "Page Setup"
settings?

Don't do this. There should be a different option to use (I assume
you do *not* want to set the job for different trays in Winword, 
but you want to set it up in a way that is "neutral" on trays,
and let CUPS do the code injection for tray control...): 

   I seem to remember that it is called "Autoselect" or "Automatic 
   Selection" in Winword (and it is a *separate* item in the 
   dropdown, right above or below the one that is called "Default
   Selection (Automatic)". 

These two entries are the top two in the dialog. They are added
by Winword. Always. Below these, there will be enumerated all 
"InputSlot" names read by Word from the PPD (attention: the one 
that is currently (!) selected in Word); this may include yet
another "$auto*" item to pick, depending on the PPD...

You find the naming of the two options as "Automatic Selection"
and "Default Tray (Automatic)" confusing? /me too. But that's the
way MS made it for us to appreciate...  ;-)

See, I suspect the following is happening: the PPD most likely has
entries like these (where XXXXXXXXXXXXXX is some PostScript code,
for the "setpagedevice" call):

  *DefaultInputSlot: 2Tray
  *InputSlot MultiTray/Bypass Tray: "XXXXXXXXXXXXXX"
  *InputSlot 1Tray/Upper:           "XXXXXXXXXXXXXX"  
  *InputSlot 2Tray/Lower:           "XXXXXXXXXXXXXX"
  *InputSlot Auto/Auto Select:      ""

As you see, the "Auto" option will insert $nothing, while the
default is set to use "Lower" in this case.

> which then makes Word pull the tray settings from the print 
> options window (so the whole document should be on the  
> same page.)  

That's approximately correct.

> Alas it all came out of the same tray, as if the CUPS option had 
> no effect.  

One potential explanation is this:

Your job arrives at CUPS with some page selection code already
inserted. Then you ask CUPS insert another, different page 
selection code. Depending on the order and the exact position
of the code insertion (Prolog, Setup or PageSetup), it remains 
undecided which one "wins" once it is interpreted by the RIP.

I'd try to set the PageSetup to "Autoselection", meaning: no code
insertion from Word, only from CUPS.

> I still suspect the problem is because the PostScript code is 
> being generated by the Windows PS driver, and CUPS isn't altering 
> it before sending it to the printer. 

CUPS may in fact be altering it, but that modification may have
no effect...

The only way to know, is by intercepting the data and compare. The 
file as it arrives from Winword should be in "/var/spool/cups/d*"
(use "PreserveJobFiles Yes" to prevent their deletion); the file
as it is sent to the printer you could reap by temporarily setting 
the printer backend to the "file:/" device:

  lpadmin -p the_printer_name -v file:/tmp/the_printer_name.ps -E 

(you need "FileDevice Yes" in cupsd.conf).

Once you have the two files, search for the "%%Page: 1 1" and
"%%Page: 2 2" lines, and compare the "%%BeginFeature" thingies
you find below them....

> Of course printing via lp had the same effect, but this wasn't 
> turned into PostScript at all (the printer just printed the 
> plaintext in the standard Courier font.)  

I don't understand what you say here. lp? lp from Windows?

> Is CUPS normally meant to convert plain text printjobs into 
> PostScript? 

If CUPS receives a file, it tries to determine its mime type, using
rules in "/etc/cups/mime.types". If it finds "text/plain", it looks 
up in "/etc/cups/mime.convs" what to do with this: usually there it
is told to run "texttops".

So yes, plain text thrown to CUPS is normally converted to PS.

The "unusual" case:  if the printqueue's PPD has an entry for 
"*cupsFilter:" like this:

  *cupsFilter: "text/plain  0  text-to-somethingelse"
 
CUPS will try to run the "/usr/lib/cups/filter/text-to-somethingelse" 
filter on that input.

> Cheers,
> Adam.

Cheers,
Kurt





More information about the cups mailing list