There are probably even more combinations, since a Printer MAY support a
Media Type Name as the value of the IPP/1.1 "media" Job Template attribute
or the JDF UserMediaType attribute, so that a value of
media=stationery-recycled is another way to specify recycled in IPP
(UserMediaType=bond in JDF). The keywords aren't a closed list in either
IPP or JDF, right?
As you indicated in your message, the current IEEE-ISTO 5100.3-2001 "IPP
Production Printing Attributes - Set1" standard extension using the
"media-recycled" (type3 keyword | name(MAX)) member attribute of the
"media-col" (collection) Job Template attribute:
(see ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf section 3.13.11)
has a way to specify recycled or not for any media and section 3.13.2
defines the "media-type" member attribute which could use any of our Media
Type Names. IPP does not (yet) have a standardized way to specify bond.
Lets look at each problem of recycled and bond separately:
So is having multiple ways for specifying recycled a problem?
I think we are adding a burden to clients and printers which support a
protocol which allows multiple ways of specifying recycled media, such as
IPP and JDF. For protocols which only allow media-type, there is no problem
for either the client or the printer, such as UPnP, Microsoft Print RPC,
PJL, PostScript.
To help a user that has to select recycled, the client should support all of
the ways, but discover from the Printer which way or ways it is configured
for, but display only one way to the user (which ever way it thinks is best
for its users).
On the other hand, lets look that the same problem for another popular
MediaType: bond.
There is no standard defined way in IPP (or its extensions so far) to
specify bond. If we don't add stationery-bond to the MediaType names, then
there will be no standard way to indicate bond in any of: IPP, UPnP,
Microsoft Print RPC, PJL, PostScript. Only JDF has the StockType attribute
which has a value of bond.
So implementers will find non-standard ways to specify bond in each of these
protocols, if we don't add stationery-bond as a Media Type Name.
So which is worse: no standard way to indicate bond in any protocol, except
JDF or a standard way to define bond in all of these protocols?
Comments?
Tom
-----Original Message-----
From: Herriot, Robert
Sent: Wednesday, May 02, 2001 20:12
To: Hastings, Tom N; ipp (E-mail)
Cc: Mark VanderWiele (E-mail)
Subject: RE: IPP> Minutes of telecon to decide on PWG Media Size syntax,
Wed, May 2
Today we discussed adding media-type values, such as stationary-recycled and
stationary-bond.
If we add stationary-recycled, we have now created two ways to specify
recycled media: one with the media-recycled attribute and the other with a
new value of media-type.
This solution creates an interoperability nightmare.
Some clients will understand media-recycled=standard and not
media-type=stationary-recycled. Other clients will be the opposite. The same
is true for printers. So, even though both a client and a printer support
recycled media, they may be unable to communicate about it because they have
implemented recycled media in a way that the other doesn't support. If a
printer implements both, the following combinations must mean recycled:
media-recycled=standard and media-type=unspecified
media-recycled=standard and media-type=stationary
media-recycled=standard and media-type=stationary-recycled
media-recycled=none and media-type=stationary-recycled
media-recycled=unspecified and media-type=stationary-recycled.
Is this what we really want?
The same problem occurs with bond if it comes through JDF which has bond as
a value of media-stock. It is not a problem with IPP.
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Wednesday, May 02, 2001 4:30 PM
> To: ipp (E-mail)
> Cc: Mark VanderWiele (E-mail)
> Subject: IPP> Minutes of telecon to decide on PWG Media Size syntax,
> Wed, May 2
>>> Minutes of telecon to decide on PWG Media Size syntax, Wed, May 2
>> Attendees: Mark VanderWiele (IBM), Ron Bergman (Hitachi Koki Imaging
> Solutions), Melinda Grant (HP), Ira McDonald (High North), Bob Herriot
> (Xerox), Bill Wagner (NetSilicon), Carl-Uno Manros (Xerox),
> and Tom Hastings
> (Xerox)
>> We also had rankings of the media size alternatives from: Don Wright
> (Lexmark).
>> 1. Summary
>> We covered three issues:
>> A. The syntax for the Media Size Self Describing Names
>> We unanimously agreed to method a (iso-a4_210x297mm,
> na-letter_8.5x11in),
> since it does help the simple client with a simple fallback
> presentation to
> the user for unrecognized names and can still be easily
> parsed and processed
> by new client software.
>> B. Merging the Media Finish Names into Media Type Names (decision at
> Portland)
>> We did reaffirm that adding the 'photographic-xxx' type
> names, where 'xxx'
> is glossy, high-gloss, semi-gloss, satin, and matte, is ok.
>> C. Adding some commonly used Media Type Names, such as bond
> and recycled
>> We agreed to add stationery-bond and stationery-recycled to
> go along with
> stationery-inkjet.
>> We also agreed that a future project should attempt to
> produce a way to
> collect all of the media attributes, including MediaType, MediaSize,
> MediaColor, and others, like weight and imagable area (which is
> printer-dependent), into a single collection, perhaps using
> XML. So we did
> not want to add things to the Media Type which are kept
> separate in current
> systems.
>> We also agreed that we wanted to complete this standard in
> the next week or
> two, ready for final voting. Ron will publish the next
> version over the
> weekend and we will probably have one more version a week
> after that to be
> voted on. Because of the unanimity of the Media Size syntax
> decision, we
> feel that this decision will stick and that the standard can
> move forward.
>>> 2. Details of the syntax for the Media Size Self Describing Names
>> We considered the following 5 alternatives as published in the meeting
> announcement. No one had any additional alternative to add.
>> a. original UPnP/HTML way (but with _ field separator):
> iso-a4_210x297mm,
> na-letter_8.5x11in
> b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000
> c. Portland decision: iso_a4_210-297, na_letter_8.5-11
> d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400
> e. Units as a separate third field: iso-a4_210-297_mm,
> na-letter_8.5-11_in
>> We reaffirmed that the Media Size Self Describing Names are
> primarily for
> program to program communication, such as from a Printer to a
> client, a
> client to a Printer, or from a data description file to a
> client. Also that
> a recipient of a name need only do a straight string
> comparison to see if it
> recognizes the name; in comparisons of the dimension part it need not
> perform any unit conversion, rounding, or closest size match.
>> The dimension part of the Media Size Self Describing Names
> are not intended
> for internal use within a program. However, we also
> clarified that when a
> client receives a Media Size Self Describing Name that it
> does not recognize
> (either by parsing or straight string match), it is very
> useful for that
> client to be able to display the string to the user.
> Therefore, if the
> units are explicitly expressed, then the user will more
> readily understand
> the fallback presentation from the client.
>> Mark also explained that in his experience, the client does
> not bother to
> localize the Media Size Names for the user, except for the
> units, since the
> names are fairly independent of human language. So the
> client needs to be
> able to easily parse and convert the dimensions to the user's
> units for an
> unrecognized size name. Having the units expressly provided
> helps such
> fallback conversion no matter how many classes are added in
> the future.
> Also by having the units explicitly expressed, if there ever
> are new units
> added, they will not be confused with the two existing units
> (in and mm).
> Therefore, we agreed that only alternative a or e met the
> requirements.
>> We then unanimously agreed to method a, since it was more
> user friendly for
> the fallback display case and not much harder to parse than method e.
>> We also agreed that in order to be able to do a straight character for
> character string match of the entire Media Size Self
> Describing Names string
> including custom names, the fraction part must not have
> trailing zeros (and
> the decimal point must be omitted if there is no fraction part), i.e.,
> na-letter_8.5x11in, NOT na-letter_8.50x11.in
>> BTW, this syntax is the same as the original UPnP BasicPrint
> Template Media
> Size syntax, with the single change that the media name field
> is separated
> from the dimensions by the underline character (_) , instead of by the
> hyphen (-), providing a more straightforward parsing
> algorithm, since the
> media name field can have hyphens too. So the UPnP group
> should be happy
> with our decision as well.
>>> 3 Details of merging the Media Finish Names into Media Type
> Names (decision
> at Portland).
>> At Portland, we recognized that having separate Finish Names,
> while good for
> new standards, such as IPP Production Printing extension and
> JDF, which have
> separate attributes for front and back coating, it does not
> help existing
> implementations of print systems and protocols, which have
> only the Media
> Type, Media Size, and Media Color mechanism. Even IPP/1.1
> has only the
> "media" Job Template attribute mechanism which can carry both
> Media Type
> Names and Media Size Self Describing Names. So at Portland,
> we agreed to
> fold back the Finish Names into sub-types of the photographic
> Media Type,
> since we though that the primary use for the coatings
> (glossy, matte, satin,
> etc.) was for photographic paper. The definitions are:
>> stationery
> Separately cut sheets of an opaque material
>> stationery-coated
> Separately cut sheets of an opaque material with a coating of
> unspecified
> type
>> stationery-inkjet
> Separately cut sheets of an opaque material whose coating is
> designed to
> minimize the spread of liquid inks
>>> photographic
> Separately cut sheets of an opaque material to produce
> photographic quality
> images. The coating is unspecified.
>> photographic-glossy
> Separately cut sheets of an opaque material that has a
> "glossy" coating to
> produce photographic quality images.
>> photographic-high-gloss
> Separately cut sheets of an opaque material that has a
> "high-gloss" coating
> to produce photographic quality images.
>> photographic-semi-gloss
> Separately cut sheets of an opaque material that has a
> "semi-gloss" coating
> to produce photographic quality images.
>> photographic-satin
> Separately cut sheets of an opaque material that has a
> "satin" coating to
> produce photographic quality images.
>> photographic-matte
> Separately cut sheets of an opaque material that has a
> "matte" coating to
> produce photographic quality images.
>> photographic-film
> Separately cut sheets of film used to produce photographic
> quality images.
>> back-print-film
> Separately cut sheet of a translucent film that the user can
> view with or
> without backlighting.
>>> After discussing the criteria for adding a Media Type Name, there was
> general agreement that the criteria for adding a Media Type
> name should be
> one of:
>> a. If the client software or Printer can alter its actions
> based on a Media
> Type Name, then it is a candidate for addition. For example,
> if the way the
> ink is put down would be altered (in some implementations) by
> a proposed
> Media Type Name, then that name should be added.
>> b. If the user would like to choose between two different
> Media Type Names,
> even if the client or Printer does not behave any differently
> for the two,
> then that name should be a candidate.
>> Also extra weight should be given to a Media Type that is
> used in existing
> systems should be another criteria and we should not add
> theoretical values,
> if they aren't used in real systems.
>> ACTION ITEM (Tom): Check with office equipment stores to see
> if there are
> coatings for both photographic and for more ordinary paper.
> ACTION ITEM (Melinda): Check with HP experience in this area as well.
>>> There was some concern that there might be some use of the
> 'xxx' coating
> parameters defined for 'photographic' with the 'stationery'
> Media Type as
> well.
>> Bob pointed out that there will be a gateway mapping problem
> between systems
> that have only the Media Type mechanism and ones (like IPP Production
> Printing Extension - see IEEE-ISTO 5100.3-2001 and JDF), that keep the
> Finish attribute separately from the rest of the other Media
> Type values
> (and can keep them separate for front and back sides as well,
> where some
> media might have different finish for front and back).
>> However, these additional media attributes are only OPTIONAL
> for a Printer
> to support, so what happens when the Printer implements the Media Type
> attribute, but doesn't implement the "media-coating-back" and
> "media-coating-front" attributes? Can such implementations
> then use our
> photographic-glossy, photographic-matte, values, or does that
> mean that the
> Printer cannot represent the media finish at all? Is it
> better to have two
> standard ways to do something (so that gateways can be
> implemented), or only
> one way, but half the systems have to do something
> non-standard in order to
> get the required functionality? We agreed to keep the new
> 'photographic-xxx' values, because of their use in existing
> systems and
> emerging standards that don't have separate finish media attributes.
>>> 4. Details of adding some commonly used Media Type Names,
> such as bond and
> recycled
>> IBM has proposed a list of additional Media Type Names that
> they have found
> in various printers and print systems over the years. Two of
> them are also
> prevalent in other existing systems: bond and recycled.
>> We discussed adding them to the Media Type. We agreed that
> they should be a
> sub-type of stationery. While a person can buy recycled
> envelopes in a
> store, we did not know of a print system in which the user
> could select
> between 'envelopes' and 'envelopes-recycled'. Usually, the
> envelopes are
> either recycled or they aren't as decided by the system
> administrator, so we
> did not agree to add 'envelopes-recycled' to Media Type
> Names. Although
> there was the same concern over recycled and bond that was
> expressed above
> in finish that recycled should be a separate media attribute
> and bond should
> be a separate stock type media attribute. The IPP
> Production Printing
> Extension (IEEE-ISTO 5100.3-2001) has a separate
> "media-recycled" media
> attribute with keyword values. JDF has a separate Recycled
> media attribute
> with a boolean value and a Stock Type media attribute with
> values: Bristol,
> Cover, Bond, Newsprint, Index, Offset - this includes book
> stock, Tag, Text.
> In spite of this concern, we still agreed to add recycled and bond as
> sub-types of stationery, i.e., 'stationery-bond' and
> 'stationery-recycled'.
>> Tom and Ron
> editors of the PWG Media Standardized Names standard
>>