Subject: Re: IPP> Resolutions

From: [email-masked] (Robert Herriot)
Date: Fri, 6 Jun 1997 17:06:30 -0700

The IPP solution using keywords is nearly the same as the text solution
you are proposing. Since the protocol implements keywords as character
strings, the only difference between your text proposal and the current
IPP solution is that someone has to register each new resolution as a
type2 keyword.

Perhaps, what you are saying tacitly is that because the format for
such keywords is Int or IntxInt where each Int value has a well defined
meaning, we could just as well define resolution as a new syntax type and
allow printer vendors to use new values of Int without the need to
register them.

Comments?

Bob Herriot

> From [email-masked] Fri Jun  6 16:42:36 1997
> 
> At 01:44 PM 6/6/97 PDT, Neil Joffe wrote:
> >You will need to specify the following pairs:
> >x-res=300, y-res=300
> >x-res=300, y-res=600
> >x-res=600, y-res=600
> >
> >or maybe
> >
> >x-res=600, y-res=600
> >x-res=300, y-res>=xres
> 
> 
> Maybe I am too simplistic here, but it seems that everybody in this
> discussion is assuming that the values have to be numeric and hence we have
> to a x-value and a y-value.
> 
> Why not stay with a simple approach of using ASCII text strings, and just
> define ONE attribute with the value for the attribute being a simple text
> string allowing values like:
> 
> "300x300"
> "300x600"
> "600x600" etc
> 
> with an additional rule that what comes before the "x" is the x-value and
> what comes after it is the y-value.  
> 
> This could also allow for cases like:
> 
> "300"
> 
> which would be semantically equivalent to:
> 
> "300x300"
> 
> Comments?
> 
> Carl-Uno
> 
> 
> 
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: [email-masked]
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 6 Jun 1997 17:37:46 PDT

>allow printer vendors to use new values of Int without the need to

I was thinking about the latter case, that there should not be necessary
to go and register every value before you can use it.  The alternative would 
be to define a list containing all the values that we are aware of now, and
let vendors with odd values register their own later, but that is
definately more messy.

Defining a separate syntax seems the simpler way to solve this. Also, an
XxY syntax may well come in handy for other attributes in the future.

Carl-Uno

Carl-Uno Manros