Subject: Re: IPP> printer-resolution standard values retrograded

From: Stan McConnell <[email-masked]>
Date: Thu, 5 Jun 1997 12:05:21 PDT

I have a couple of comments about printer-resolution.

1. The list is missing the multiples of 360 that are in fairly common use
in ink-jet printers.  And most of these printers, if not all, can have a
2-dimensional resolution, e.g., 360x720, ... , 720x1440, 1440x1440.  So the
list needs to be expanded to cover these.

2. Given the potentially large list of 2d values, there is an mxn problem
here, in addition to the need to register every new value with IANA.  It
seems more straightforward to simply replace the printer-resolution
attribute with two attributes, printer-x-resolution and
printer-y-resolution, each having an integer type which encodes the actual
resolution value.  Then there is no need to register the values.

We made the mistake in DPA of having only a single value to encode printer
resolution.  I have submitted a defect report to ISO to correct the
problem, and I hope IPP will fix the problem as well.

At 08:38 AM 6/5/97 PDT, Tom Hastings wrote:
>The 970512.doc had the following for printer-resolution, but the
>latest I-D 970603 has reverted to earlier text that didn't have any standard
>values listed.
>
>Did any other attributes retrograde?
>
>Tom
>
>6.2.12	printer-resolution (type2 keyword)
>This job attribute specifies the resolution that the Printer should use.
>The values are type2 keywords which represent single integers or pair of
>integers. The latter are to specify the resolution when the x and y
>dimensions differ. When two integers are specified, the first is in the x
>direction, i.e., in the direction of the shortest dimension of the medium,
>so that the value is independent of whether the printer feeds long edge or
>short edge first.
>The standard values are:
>normal
>res-100
>res-200
>res-240
>res-300
>res-600
>res-800
>res-1200
>res-1800
>res-100x200
>res-300x600
>res-600x300
>res-400x800
>res-800x400
>res-600x1200
>res-1200x600
>res-1800x600
>
>
>
>

---

From: [email-masked] (Robert Herriot)
Date: Thu, 5 Jun 1997 15:09:12 -0700

We consciously avoided having both a x and y printer resolution
attributes.  We didn't want a client or server to deal with all the
impossible combinations of x and y. We believed that the number of
combinations was sufficiently small that it was better to enumerate
them. The supported values is then an accurate list, unlike the x-and-y
solution where some combinations may be unsupported.  Furthermore, a
particular printer is unlikely to support more than a very few.

How many do you think there are with current technology? 25? 50?
What is the largest number any printer supports? 2? 3?

I still think we make the correct choice.

Bob Herriot
> From [email-masked] Thu Jun  5 12:12:50 1997
>

---

From: Dave Polaschek <[email-masked]>
Date: Thu, 5 Jun 97 18:40:28 -0500

I'd like to add my comments about printer resolution. I don't have a good 
solution, and I'm sorry if some of this has been covered before.

1. Any [reasonable] enumerated list is going to be lacking resolutions 
supported by existing printers. A type3 or type4 keyword is more 
appropriate than a type2 keyword.

2. Having only a one-dimensional resolution, even with provisions for 
two-number resolutions spooks me. Having worked for a company that's made 
many printers with non-square resolution, and gotten burned by far too 
many applications assuming the wrong thing has made me gun-shy.
Specifying resolutions as an integer-pair in all cases tends to prod more 
people into using both values.

3. Not all printer resolutions are integral. I don't think this is a huge 
issue, but I mention it lest people forget.

4. I'm a little nervous about the phrase:
>    When two integers are specified, the first is in the x
>    direction, i.e., in the direction of the shortest dimension
>    of the medium, so that the value is independent of whether
>    the printer feeds long edge or short edge first.
which doesn't seem to account for the case of a roll or cut-sheet-fed 
printer.

As an example, take a printer which has different x and y resolutions, 
and supports cut-sheet media of a size sufficently large that a user can 
mount a letter page in either of two orientations. When you ask for the 
resolution of the printer, do you want the answer to change based on 
which paper orientation is being used?

I believe that always specifying two-dimensional resolution is good, and 
stating that the first resolution is in the direction of head travel, and 
the second in the direction of paper-travel (or similar wording that's 
marking-engine-based, and not media-orientation-based) would make for a 
better description of printer resolution.

-DaveP
Dave Polaschek -- Mac Guy -- LaserMaster Corp -- [email-masked]
-----------------------------------------------------------------------