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
>>