Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #3214 > unrolled thread

on paper tray selection

Back to article view | Back to comp.lang.postscript

Contents

  on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-18 00:39 +0000
    Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-18 12:06 +0000
      Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-18 14:06 +0000
      Re: on paper tray selection Martin Leese <please@see.Web.for.e-mail.INVALID> - 2018-01-18 10:57 -0700
        Re: on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-18 19:24 +0000
          Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-19 09:07 +0000
            Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-19 15:46 +0000
              Re: on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-19 18:26 +0000
                Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-20 09:15 +0000
              Re: on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-19 19:24 +0000
                Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-20 09:32 +0000
            Re: on paper tray selection Martin Leese <please@see.Web.for.e-mail.INVALID> - 2018-01-19 10:55 -0700
              Re: on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-19 18:33 +0000
                Re: on paper tray selection ken <ken@spamcop.net> - 2018-01-20 09:18 +0000
    Re: on paper tray selection jdaw1 <jdawiseman@gmail.com> - 2018-01-21 04:44 -0800
      Re: on paper tray selection Martin Leese <please@see.Web.for.e-mail.INVALID> - 2018-01-23 10:17 -0700
        Re: on paper tray selection Eli the Bearded <*@eli.users.panix.com> - 2018-01-26 17:55 +0000

#3214 — on paper tray selection

I have a Brother laser printer. It's a fairly recent model, and one of
the larger ones in their line. (HL-6200DN)

I'd like to be able to switch betwen the manual paper tray and the
regular tray programatically. Specifically I'd like to print collated
collections of covers and interior pages, and never have to hand collate
that stuff.

I gather there are explicit commands in PCL to do tray switches, but
Postscript is a different beast that doesn't include printer commands,
just page description commands. :^) 

One document I found said that you should look in the PPD for the
InputSlot lines, which should have the appropriate setpagedevice
command. So I did that, and the place where it should be is blank.

    The following lines come from the PPD file for the Ricoh cl 3000
    printer:
       *InputSlot MultiTray/Bypass Tray: "<</MediaPosition 0>>
       setpagedevice"
       *InputSlot 1Tray/Tray 1: "<</MediaPosition 1>> setpagedevice"
       *InputSlot 2Tray/Tray 2: "<</MediaPosition 2>> setpagedevice"
       *InputSlot 3Tray/Tray 3: "<</MediaPosition 3>> setpagedevice"

In the Brother PPD they look more like:

       *InputSlot 2Tray/Tray 2: "  "

Does Postscript offer ways to inspect settings that can be made with
setpagedevice? Are there common standards that are likely to work for
tray selection? (Eg, the Ricoh stuff above.)

Another approach that has been suggested to me, but one that I've not
tried to research, is assigning different attributes to the paper in
each tray. In my case the page sizes will be the same, but the paper
weights are different.

I know the printer can distinguish different paper weights, because the
self-diagnostic will tell me how many pages of normal versus heavy paper
have been printed (in my case: circa 30,000 vs none). The covers are
a slightly heavier stock, so it would even be appropriate.

I don't know how to assign that attribute to a particular tray and I
don't know how to specify that in Postscript.

One other wrinkle: covers are simplex and interior pages are duplex.

Advice? Hints? Words of condolance?

Elijah
------
has asked in OS specific groups about apps for managing printing wihout luck

[toc] | [next] | [standalone]

#3215

In article <eli$1801171916@qz.little-neck.ny.us>, *@eli.users.panix.com 
says...

> I gather there are explicit commands in PCL to do tray switches, but
> Postscript is a different beast that doesn't include printer commands,
> just page description commands. :^) 

Not quite true. PostScript the language is device-independent, so 
doesn't include operators to do things like tray switching.

However, the 'setpagedevice' operator allows you to alter features of 
the device. The problem here is that the features and capabilities of 
the device are outside the scope of the language. That said the 
PostScript Language Reference Manual has an extensive section on finding 
and setting media based on the desired attributes (See Section 6, Device 
Control).

 
> One document I found said that you should look in the PPD for the
> InputSlot lines, which should have the appropriate setpagedevice
> command.

On some devices, maybe. But that's not the way you are *supposed* to use 
the media selection abilities of PostScript. InputSlot isn't PostScript, 
its PPD, the PostScript equivalent is the 'MediaPosition' key in the 
PPD. Note that you are not really supposed to select the tray yourself, 
partly because its often the case that users can swap trays around. 
However, if you do, then the interpreter should honour the position 
request, even if its not the best option based on other criteria (see 
next 2 paragraphs).

The intention of the media selection process is that the PostScript 
interpreter is aware of the configuration of the device. What trays are 
available, the media size of each tray, the media weight etc.

You then request a particular kind of media, and the interpreter does 
its best to match your request from what it has available. Depending on 
the configuration of the interpreter it may do things like; select a 
medium and print to it, select a 'best fit' medium and print to that, 
request assistance from the operator (no suitable media available) or 
throw an error.


> So I did that, and the place where it should be is blank.
> 
>     The following lines come from the PPD file for the Ricoh cl 3000
>     printer:
>        *InputSlot MultiTray/Bypass Tray: "<</MediaPosition 0>>
>        setpagedevice"
>        *InputSlot 1Tray/Tray 1: "<</MediaPosition 1>> setpagedevice"
>        *InputSlot 2Tray/Tray 2: "<</MediaPosition 2>> setpagedevice"
>        *InputSlot 3Tray/Tray 3: "<</MediaPosition 3>> setpagedevice"
> 
> In the Brother PPD they look more like:
> 
>        *InputSlot 2Tray/Tray 2: "  "

So you (probably) can't just request a specific tray from the 
interpreter, it won't let you. This suggests that the interpreter 
 does have a lot of information available to it, and you should request 
what you want, rather than asking for a specific tray.


> Does Postscript offer ways to inspect settings that can be made with
> setpagedevice?

Not exactly. You can put anything you like in the dictionary to 
setpagedevice and the device will ignore anything it doesn't understand.

However....

You *can* ask the device what the current settings are, by using the 
'currentpagedevice' operator. That will return a dictionary with all 
kinds of interesting things in it. In particular it will (or at least 
should) return an InputAttributes dictionary.

Why is that interesting ? Because that dictionary should list the 
attributes of the available media.

Assuming that this is present, and matches what you think should be 
there, going by what's loaded in your printer, then you can send a media 
request for that medium. The interpreter should then match that request 
with the tray and print on that medium.


> Are there common standards that are likely to work for
> tray selection? (Eg, the Ricoh stuff above.)

Selecting MediaPosition is standard. The other standard keys for a media 
request are listed in the PLRM but include; PageSize (most important!), 
MediaColor, MediaWeight, MediaType, MediaClass, LeadingEdge, 
InsertSheet, ManualFeed, TraySwitch,  MediaPosition and 
DeferredMediaSelection.


> I know the printer can distinguish different paper weights, because 
the
> self-diagnostic will tell me how many pages of normal versus heavy paper
> have been printed (in my case: circa 30,000 vs none). The covers are
> a slightly heavier stock, so it would even be appropriate.

So that does indicate that the printer, and by implication the 
PostScript interpreter, know a lot about the available media and 
'probably' expect to match it based on your media request.

 
> I don't know how to assign that attribute to a particular tray and I
> don't know how to specify that in Postscript.

Like I said, you would set up a media selection request. For example;

<<
/PageSize [612 792]
/MediaColor (Blue)
/MediaWeight 37.6
/MediaPoosition 2
>> setpagedevice

Would request media which is A4, Blue, has a weight of 37.6 grams/square 
meter and is in tray 2.

The interpreter should match that against the InputAttributes of all the 
media it has available and select the 'best fit' which will usually mean 
that it will consider PageSize first, then colour (if it kows that) and 
weight. Because that request includes a MediaPosition, the interpreter 
will prefer tray position 2 if it possibly can. In that case it might 
ignore everything except the MediaSize. In ecterme cases it may even 
ignore the MediaSize and just select the specified tray (clearly you 
know what you are doing...)


> One other wrinkle: covers are simplex and interior pages are duplex.

So you would also need to add /Duplex true or /Duplex false. Of course, 
depending on the pages emitted so far this may result in a blank side on 
a Duplex print.

You may also need to set /Tumble to control whether page images are 
bottom up or top down on the obverse.

Both of these are also page device controls, along with MirrorPrint, 
NegativePrint, Margins, PageOffset, ImageShift, ImagingBBox and 
HWResolution.

Of course, not all printers will support all of these controls. Duplex 
will be ignored on a pritner without a duplexing unit for example.

There are many other device controls potentially available as standard, 
and then there are also non-standard extensions for features which 
weren't considered at the time (eg /Staple is common)

 
> Advice? Hints? Words of condolance?

Well hopefully you can now see that PostScript does in fact potentially 
boast a rich set of controls for devices. Exactly what is implemented, 
and how, is unfortunately under the control of the printer manufacturer. 
Not every manufacturer bothers to implement all the features and if I 
remember correctly Brother have their own PostScript interpreter, the 
quality of which doesn't hugely impress me.....

If I were you I would contact Brother technical support and ask *them* 
how to achieve what you want. If anyone knows they should, though I 
appreciate it can be difficult to find a suitably informed person.

BTW I can't find a Brother HL-6200DN, only a DW.....


				Ken

[toc] | [prev] | [next] | [standalone]

#3216

In article <MPG.34ca9e01b8ce0da1989920@usenet.plus.net>, ken@spamcop.net 
says...

> > So I did that, and the place where it should be is blank.
> > 
> >     The following lines come from the PPD file for the Ricoh cl 3000
> >     printer:
> >        *InputSlot MultiTray/Bypass Tray: "<</MediaPosition 0>>
> >        setpagedevice"
> >        *InputSlot 1Tray/Tray 1: "<</MediaPosition 1>> setpagedevice"
> >        *InputSlot 2Tray/Tray 2: "<</MediaPosition 2>> setpagedevice"
> >        *InputSlot 3Tray/Tray 3: "<</MediaPosition 3>> setpagedevice"
> > 
> > In the Brother PPD they look more like:
> > 
> >        *InputSlot 2Tray/Tray 2: "  "

Runnaging through the web I see that a similar model allows you to set 
up and select the trays from the print dialog. You could try doing that 
too. 

Check the 'print to file' box on the printer port so that it writes a 
file.

Print a 'Hello World' page to the printer and force it to use tray 1. 
Save the file with an easy to remember name.

Repeat for tray 2.

Compare the PostScript files to see what's different.



			Ken

[toc] | [prev] | [next] | [standalone]

#3217

ken wrote:
...
> You *can* ask the device what the current settings are, by using the 
> 'currentpagedevice' operator. That will return a dictionary with all 
> kinds of interesting things in it. In particular it will (or at least 
> should) return an InputAttributes dictionary.
> 
> Why is that interesting ? Because that dictionary should list the 
> attributes of the available media.

Ken's advice is excellent.  It might also
be useful to examine the contents of the
Page Device Dictionary.  Something like this
will get you started:

%!
% PostScript code to show keys in Page Device Dictionary.
%
/Helvetica findfont 10 scalefont setfont
100 750 moveto
currentpagedevice
{pop 30 string cvs show -75 -12 rmoveto} forall
showpage

This program can be much improved.

...
> BTW I can't find a Brother HL-6200DN, only a DW.....

I also was unable to find a description of
the DN model.  A description of its features
(number of trays, duplex) might help.  Also,
a clearer description of what exactly you
wish to achieve (eg, first page from manual
slot simplex, all subsequent pages from top
slot duplex).

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#3218

In comp.lang.postscript,
Martin Leese  <please@see.Web.for.e-mail.INVALID> wrote:
> ken wrote:
> > You *can* ask the device what the current settings are, by using the 
> > 'currentpagedevice' operator. That will return a dictionary with all 
> > kinds of interesting things in it. In particular it will (or at least 
> > should) return an InputAttributes dictionary.
> > 
> > Why is that interesting ? Because that dictionary should list the 
> > attributes of the available media.
> Ken's advice is excellent.  It might also
> be useful to examine the contents of the
> Page Device Dictionary.  Something like this
> will get you started:
> 
> %!
> % PostScript code to show keys in Page Device Dictionary.
> %
> /Helvetica findfont 10 scalefont setfont
> 100 750 moveto
> currentpagedevice
> {pop 30 string cvs show -75 -12 rmoveto} forall
> showpage
> 
> This program can be much improved.

Adjusting the offsets, I managed to get a full page of one entry per line 
output. Not sure how much is off the bottom... List of what is shown below.

> > BTW I can't find a Brother HL-6200DN, only a DW.....
> I also was unable to find a description of
> the DN model.

My mistake. It is DW. An earlier printer of mine was DN. Like on HPs,
the letters on the end refer options available. N is just networked,
W is wifi networked. D is duplex cabable.

>                A description of its features
> (number of trays, duplex) might help.  Also,
> a clearer description of what exactly you
> wish to achieve (eg, first page from manual
> slot simplex, all subsequent pages from top
> slot duplex).

This printer has one standard tray (capacity 550 sheets of 20lb) and one
manual tray (capacity 25 to 50 sheets). I think there is an option to
add another standard tray, but I'm not certain. It only prints in black
and white and it has no sophisticated output options (eg, collator,
stapler, etc), even though the dictionary suggests those are there.

I suspect Brother is using the same Postscript interpreter on all its PS
capable printers, no matter the hardware options available.

Your eg captures the goal almost exactly. For a single copy, that's what
I'd want. But in this case, I'd like to print ten to twenty copies. I'm
willing to script the printing from the Unix command line to do it in
pieces as needed. Currently I have it working that I can print all the
simplex sheets in one job and all the duplex sheets in another, but I
need to tend to the manual paper tray manually between them: make sure
it has enough paper for covers and has no paper for non-covers.

Output from the page device dictionary 

	PostRenderingEnhance
	PostRenderingEnhanceDetails
	cupsColorSpace
	NegativePrint
	HWResolution
	ProcessColorModel
	OutputType
	Tumble
	ManualFeed
	Duplex
	SeparationColorNames
	Trim
	Separations
	ManualFeedTimeout
	Jog
	MirrorPrint
	Fold
	Policies
	PreRenderingEnhanceDetails
	Signature
	ImagingBBox
	ExitJamRecover
	TrappingDetails
	SlipSheet
	CutMedia
	DeferredMediaSelection
	BindDetails
	OutputFaceUp
	NumCopies
	OutputDevice
	BeginPage
	Orientations
	SeparationOrder
	Install
	UseCIEColor
	PageSize
	BookletDetails
	MaxSeparations
	MediaPosition
	PageOffset
	StapleDetails
	AdvanceMedia
	Collate
	AdvanceDistance
	Trapping
	Staple
	Laminate
	InputAttributes
	TraySwitch
	EndPage
	FoldDetails
	Bind
	OutputPage
	PreRenderingEnhance
	MediaType
	Margins
	MediaColor
	ImageShift
	PageDeviceName
	Booklet
	MediaWeight
	DeviceRenderingInfo

The presence of MediaWeight there gives me hope that I could use that
for selecting cover versus non-cover for task, if I can figure out how
to assign a weight to a tray. TraySwitch is also interesting.

As for the suggestion to set printer tray options then print to file and
examine the differences: I've already thought of that. I've scoured the
Mac and Windows printer options trying to find a way to change tray
options (or any paper attributes other than size). No apparent way to do
this that way.

Elijah
------
oh for an inexpensive printer that could fold and saddle stitch

[toc] | [prev] | [next] | [standalone]

#3219

In article <eli$1801181424@qz.little-neck.ny.us>, *@eli.users.panix.com 
says...

> I suspect Brother is using the same Postscript interpreter on all its 
PS
> capable printers, no matter the hardware options available.

That would be correct anyway, the hardware makes no difference to the 
interpreter as such, it just affects the available options.


> The presence of MediaWeight there gives me hope that I could use that
> for selecting cover versus non-cover for task, if I can figure out how
> to assign a weight to a tray. TraySwitch is also interesting.

Actually I find its presence there somewhat alarming, it should be in 
the InputAttributes sub-dictionary, not the page device dictionary.

In reality what you want is the content of the InputAttributes 
dictionary, and the values printed as well as the keys (dictionaries 
contain key/value pairs).

I presume you don't have 2 way communication with this printer ? It 
would be a lto easier to capture the back channel than print the actual 
data.

I'll see if I can come up with a program to print the key/value pairs 
from the InputAttributes dictionary.


> examine the differences: I've already thought of that. I've scoured 
the
> Mac and Windows printer options trying to find a way to change tray
> options (or any paper attributes other than size). No apparent way to do
> this that way.

Well, I already mentioned that I'm not a fan of Brother devices....



				Ken

[toc] | [prev] | [next] | [standalone]

#3220

In article <MPG.34cbc59b69c27671989922@usenet.plus.net>, ken@spamcop.net 
says...

> I'll see if I can come up with a program to print the key/value pairs 
> from the InputAttributes dictionary.

This will print multiple pages, for me on Ghostscript it prints 5 pages, 
it may be more or less on your printer. After this its going to be a 
case of experimentation to see what works.

%!

/KensDict 10 dict dup begin def
currentpagedevice /PageSize get aload pop
/TopY exch 10 sub def
/TopX exch def
/CurrentY TopY def
/CurrentX 5 def
/Nesting 0 def
/ScratchString 256 string def

/Helvetica findfont 10 scalefont setfont

/CheckLine {
  CurrentY 20 lt {
    showpage
    /CurrentY TopY def
    CurrentX CurrentY moveto
  } if
} bind def

/dumpdict {
  CheckLine
  CurrentX CurrentY moveto (<<) show
  /CurrentY CurrentY 10 sub def
  /Nesting Nesting 1 add def
  /CurrentX CurrentX 5 add def
  {
     exch
     CurrentX CurrentY moveto
     ScratchString cvs dup show stringwidth pop CurrentX add 5 add 
CurrentY moveto
     dup type /dicttype eq {
       /CurrentY CurrentY 10 sub def
       dumpdict
     }{
       dup type dup /arraytype eq exch /packedarraytype eq or{
         /CurrentY CurrentY 10 sub def
         dumparray
       }{
         CheckLine
         dup type /stringtype ne {
         ScratchString cvs
         } if
         show
         /CurrentY CurrentY 10 sub def
       } ifelse
     } ifelse
  } forall
  /Nesting Nesting 1 sub def
  /CurrentX CurrentX 5 sub def
  CheckLine
  CurrentX CurrentY moveto (>>) show
  /CurrentY CurrentY 10 sub def
}def

/dumparray {
  CheckLine
  /Nesting Nesting 1 add def
  CurrentX CurrentY moveto ([) show
  {
    dup type /dicttype eq {
      dumpdict
    }{
      dup type dup /arraytype eq exch /packedarraytype eq or{
        dumparray
      }{
         dup type /stringtype ne {
           ScratchString cvs
         }if
         show ( ) show
      } ifelse
    } ifelse
  } forall
  (]) show
  /Nesting Nesting 1 sub def
  /CurrentY CurrentY 10 sub def
}def

currentpagedevice dumpdict
end

showpage

[toc] | [prev] | [next] | [standalone]

#3222

In comp.lang.postscript, ken  <ken@spamcop.net> wrote:
> ken@spamcop.net says...
>> Well, I already mentioned that I'm not a fan of Brother devices....

I'll grant you they are not perfect. I'm curious what you would
recommend. I will not accept ink jet. I need duplexing, I need wireless
(these days), I need Mac (most printing) and Iphone/Win/Linux support.

Before Brother (and this is my third Brother), I had an HP
2200(someletters) (it was pre-iphone). That developed an issue with the
on-board fonts, so that some letters / numbers misprinted which really
put me off HP. People suggested Brother as good, so I went with that.
(The combined original cost of all three Brothers is probably less than
the original price of that HP.) Since then I've killed one, got a
similiar, and upgraded to a larger size to get me to printer number
three. This one is about the size of the HP I had a decade ago.

Let me take you through a typical day's printing[*] for further detail.
Because it's convenient, everything is saved as PDF. There's no
technical reason that can't be switched to something else. (I have Adobe
Illustrator available.)

Printing booklets (Mac):
	20 to 25 simplex covers
	20 to 25 duplexed interiors. A typical booklet is either three
		 or four interior sheets.
	booklets are then hand collated, folded, and stapled (the
	collation step here is the one I want to solve)

Printing envelopes (Mac):
	20 to 25 simplex (these are brown craft paper and have been
		 known to leave dust in the printer; also these jam
		 easily on this printer)

Printing labels (Mac):
	10 to 13 simplex, these are two-up in the original, for 20 to
		 26 labels output (these are used on the back of
		 the envelopes instead of duplexing those)

Printing orders (Mac):
	a bunch of simplex sheets

Win/Linux/Iphone printing: 
	mix of simplex and duplex depending on content

If not Brother, which has been reliable if not perfect, what do you
suggest for this?

[*] With this printer. There's a dedicated 4"x6" label printer for mailing
    labels, and the large format (engineering size D and E) stuff is
    outsourced to a reprographic place. All of it is for selling sewing
    patterns. Pattern and booklet in brown paper envelope, patterns sold
    individually and in bulk, mailed inside a larger envelope or boxed.


I was going to respond to your script post here, too, but I think I'll
make that a separate followup.

Elijah
------
has been considering using a Raspberry Pi or the like as a print server

[toc] | [prev] | [next] | [standalone]

#3225

In article <eli$1801191241@qz.little-neck.ny.us>, *@eli.users.panix.com 
says...
> 
> In comp.lang.postscript, ken  <ken@spamcop.net> wrote:
> > ken@spamcop.net says...
> >> Well, I already mentioned that I'm not a fan of Brother devices....
> 
> I'll grant you they are not perfect. I'm curious what you would
> recommend. I will not accept ink jet. I need duplexing, I need wireless
> (these days), I need Mac (most printing) and Iphone/Win/Linux support.

My input is only useful in terms of the quality of the PostScript 
interpreter, I don't have any recent wide experience of printer 
hardware.

Any printer using an Adobe implementation will of course be fine. Clone 
Rips from Ricoh and Canon have been good in my experience. Lexmark have 
historically been decent, though I don't know what they use these days.

My exposure is via Ghostscript. Ghostscript has a device for turning its 
input (PCL, XPX, PDF, PostScript) into PostScript output. The PostScript 
produced is machine generated and therefore predictable. Its also 
conforms to the language, and to the architectural limitations of an 
Adobe implementation.

We have, over the years, had to allow options to scale back the feature 
set because the (perfectly valid) PostScript won't run on various 
printers. Brother printers are the most frequent culprits in this 
regard.


> If not Brother, which has been reliable if not perfect, what do you
> suggest for this?

As I said, I've been away from the hardware end of this for some time 
now, I can only comment on the implementation of the PostScript 
interpreter. Of the (few) remaining PostScript interpreters on the 
market the Brother clone is by far the worst implementation I've seen.

Which doesn't mean that it doesn't work well most of the time, or that 
there's anything wrong with the hardware, or that it doesn't do a good 
job for you generally.

But when you want to do something a bit out of the ordinary, its quirks 
start to surface.


				Ken

[toc] | [prev] | [next] | [standalone]

#3224

In comp.lang.postscript, ken <ken@spamcop.net> wrote:
>> I'll see if I can come up with a program to print the key/value pairs 
>> from the InputAttributes dictionary.
> 
> This will print multiple pages, for me on Ghostscript it prints 5 pages, 
> it may be more or less on your printer. After this its going to be a 
> case of experimentation to see what works.

I got two pages of output, with one line in the middle of one them
overwritten several times. Reading it, maybe an array of arrays triggers
that? But overall it's a pretty cool program.

The long line appears to be an array called "Install", so probably not
too interesting anyway.

The InputAttributes dictionary is empty. Previous to running this, I
hadn't realized InputAttributes was a dictionary inside of
currentpagedevice. I know only a little Postscript programming.

All of the straight out of currentpagedevice Media* settings show up
as "--nostringval--". They are:

	MediaPosition
	MediaType
	MediaColor
	MediaWeight

Also, possibly relevant, OutputType is "--nostringval--".

In the Policies dictionary:

	<<
	 MediaWeight 1
	 PolicyReport
	 [pop ]
	 OutputDevice 0
	 PageSize 0
	 InputAttributes 1
	 PolicyNotFound 1
	 MediaType 1
	 MediaColor 1
	>>

And there's a 

	DeferredMediaSelection true

I'm going to guess all that means media (weight|type|color) can be used
to select a tray, but not media position.

Elijah
------
will try to look at the language reference PDF later today

[toc] | [prev] | [next] | [standalone]

#3227

In article <eli$1801191424@qz.little-neck.ny.us>, *@eli.users.panix.com 
says...

> I got two pages of output, with one line in the middle of one them
> overwritten several times. Reading it, maybe an array of arrays triggers
> that? But overall it's a pretty cool program.

An array of arrays is supposed to just dump the array, but I think I 
forgot to trigger a newline, so yeah that seems likely. Drat.
 
> The long line appears to be an array called "Install", so probably not
> too interesting anyway.

That's fortunate, all that does is contain procedures (packedaaray type) 
to set certain device-dependent graphics-state parameters. Most likely 
you can ignore everything there.
 
> The InputAttributes dictionary is empty. Previous to running this, I
> hadn't realized InputAttributes was a dictionary inside of
> currentpagedevice. I know only a little Postscript programming.

Well that's pretty sucky really. So the printer hardware isn't telling 
the PostScript interpreter anything at all that it knows about its 
configuration :-(

> 
> All of the straight out of currentpagedevice Media* settings show up
> as "--nostringval--". They are:
> 
> 	MediaPosition
> 	MediaType
> 	MediaColor
> 	MediaWeight
> 
> Also, possibly relevant, OutputType is "--nostringval--".
> 
> In the Policies dictionary:
> 
> 	<<
> 	 MediaWeight 1
> 	 PolicyReport
> 	 [pop ]
> 	 OutputDevice 0
> 	 PageSize 0
> 	 InputAttributes 1
> 	 PolicyNotFound 1
> 	 MediaType 1
> 	 MediaColor 1
> 	>>
> 
> And there's a 
> 
> 	DeferredMediaSelection true
> 
> I'm going to guess all that means media (weight|type|color) can be used
> to select a tray, but not media position.

Probably not, no. With InputAttributes being empty there's no (standard) 
way for a PostScript interpreter to select amongst different media. The 
interpreter thinks it only has one.

The only think I can suggest is brute-force experimentation.

I'm not clear how, at the moment, you switch between selecting media 
from the paper tray, the  manual feed, envelopes and your label printer. 
I guess I don't need to worry about envelopes and labels.

Are you pressing buttons on the front panel or something ?

The obvious thing to do is send something like this:

%!

<<
/MediaPosition 0
>> setpagedevice
showpage

<<
/MediaPosition 1
>> setpagedevice
showpage

<<
/MediaPosition 2
>> setpagedevice
showpage


and see where the printer pulls media from. Duplex is easy, that's 
absolutely standard:

%!

<<
/Duplex false
>> setpagedevice
showpage

So you might want to combine those as:

%!

<<
/Duplex false
/MediaPosition 0
>> setpagedevice
showpage
.....

If the printer pulls from different trays you can probably work out how 
to control it. If it doesn't then I'm forced to assume that Brother 
simply doesn't want to let you control the tray selection from 
PostScript. Which would, of course, explain the empty entries in the 
PPD......



			Ken

[toc] | [prev] | [next] | [standalone]

#3221

ken wrote:
> In article <eli$1801181424@qz.little-neck.ny.us>, *@eli.users.panix.com 
> says...
...
>> The presence of MediaWeight there gives me hope that I could use that
>> for selecting cover versus non-cover for task, if I can figure out how
>> to assign a weight to a tray. TraySwitch is also interesting.
> 
> Actually I find its presence there somewhat alarming, it should be in 
> the InputAttributes sub-dictionary, not the page device dictionary.

The /MediaWeight key in the page device
dictionary is just a placeholder.  Its
value is set by the job, and then compared
to the values in the /InputAttributes
dictionary to try to find a match.  This
means that if /MediaWeight is not a key in
any of the (numeric) sub-dictionaries in the
/InputAttributes dictionary then this
parameter can not be used to select media.

Ignore /TraySwitch.  It is a PostScript
Level 3 parameter that indicates the printer
can automatically switch to an alternate
paper tray should the selected tray become
empty.

> In reality what you want is the content of the InputAttributes 
> dictionary, and the values printed as well as the keys (dictionaries 
> contain key/value pairs).

Yep, this is the starting point.  The keys
in the numeric sub-dictionaries indicate
what parameters are available for media
selection.

> I presume you don't have 2 way communication with this printer ? It 
> would be a lto easier to capture the back channel than print the actual 
> data.
> 
> I'll see if I can come up with a program to print the key/value pairs 
> from the InputAttributes dictionary.

Nice program (I did say mine could be
much improved :-).

Eli needs to obtain a copy of the PostScript
Language Reference manual.  The Third
Edition is available for free as a 7.6 MByte
PDF file.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#3223

In comp.lang.postscript,
Martin Leese  <please@see.Web.for.e-mail.INVALID> wrote:
> Eli needs to obtain a copy of the PostScript
> Language Reference manual.  The Third
> Edition is available for free as a 7.6 MByte
> PDF file.

I have the Red Book in a copyright 1985 paper copy. Cover banner
proclaims "Includes detailed programming for LaserWriter(TM)". I've
noticed it doesn't have this stuff. :^)

Elijah
------
remembers when Laser Writers were new and cool

[toc] | [prev] | [next] | [standalone]

#3226

In article <eli$1801191333@qz.little-neck.ny.us>, *@eli.users.panix.com 
says...
> 
> In comp.lang.postscript,
> Martin Leese  <please@see.Web.for.e-mail.INVALID> wrote:
> > Eli needs to obtain a copy of the PostScript
> > Language Reference manual.  The Third
> > Edition is available for free as a 7.6 MByte
> > PDF file.
> 
> I have the Red Book in a copyright 1985 paper copy. Cover banner
> proclaims "Includes detailed programming for LaserWriter(TM)". I've
> noticed it doesn't have this stuff. :^)

That's language level 1, the current (and final) version is language 
level 3. All of the setpagdevice code was added in language level 2, 
back in 1990.


			Ken

[toc] | [prev] | [next] | [standalone]

#3228

Lots of good advice from the other posters. 

But also, if you are printing PDF, ensure that all your carefully-chosen PostScript preferences have been retained by the PS➝PDF converter.

[toc] | [prev] | [next] | [standalone]

#3229

jdaw1 wrote:
> Lots of good advice from the other posters. 
> 
> But also, if you are printing PDF, ensure that all your carefully-chosen PostScript preferences have been retained by the PS➝PDF converter.

A similar point occurred to me.  In one of
his posts, Eli stated that he saves
everything as PDF.  This raises the
possibility that when he has been listing
the contents of his Page Device dictionary,
he has been interrogating his software to
convert to PDF and *not* his printer.  This
would explain why his /InputAttributes
dictionary is empty.

This is how I tested my PostScript code; I
listed dictionaries inside Ghostscript.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#3234

In comp.lang.postscript,
Martin Leese  <please@see.Web.for.e-mail.INVALID> wrote:
> A similar point occurred to me.  In one of
> his posts, Eli stated that he saves
> everything as PDF. 

Slightly different: I said everything is *currently* saved as PDF.

When I've been running these test programs, I've been using lpr (on
a Mac) to send PS to the printer. I do not think that Mac OSX is taking
that postscript and converting it to PDF to convert to something else
to send to a printer it knows can print PS.

I could be wrong. I have printed PS with direct "telnet" to the printer,
and I think that "lpr" is just a friendly wrapper around that.

Sorry about radio silence for a while, I was distracted with other
problems.

Elijah
------
still open to printer suggestions for the next time

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web