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
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.
Dave Polaschek -- Mac Guy -- LaserMaster Corp -- davep at leonardo.lmt.com
>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.
>> From stanmcc at cp10.es.xerox.com Thu Jun 5 12:12:50 1997
>>>> 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
>> >values listed.
>> >Did any other attributes retrograde?
>> >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.