I wasn't very clear in my previous note about UPDF and IPP Collaboration.
1. Firstly, there are lots more areas for collaboration that just fonts. It
should be possible for a driver that interprets a UPDF file to generate an
'application/ipp' MIME type payload for a Print-Job request that conforms to
IPP/1.1. Also a UPDF file for IPP/1.0. See (1)
<draft-ietf-ipp-model-v11-07.txt> and <draft-ietf-ipp-protocol-v11-06.txt>
and (2) RFCs 2566 and 2565, respectively.
2. For fonts, the area of collaboration is to have a semantic description of
the font attributes, such as the ones that describe the font and the ones
that describe the font metrics. This semantic description would have
several parts:
a. Attributes that are common to all fonts
b. Attributes that apply to a particular document format, such as
Postscript or PCL
3. Then these semantic description documents would have separate encoding
documents:
a. IPP encoding for use in the Get-Resource-Attributes, Get-Resource-Data,
and Get-Resources operation requests and responses.
b. XML encoding for use by font vendors when publishing their fonts and
for use in a UPDF file for use by Printer vendors when publish their UPDF
Printer Description files.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Saturday, July 08, 2000 12:39
To: upd
Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts
This note is an idea for possible collaboration of the UPDF and IPP work.
Attached is the first draft of an IPP extension for a Resource object and
operations to get the attributes and/or opaque data. The Get-Resources
operation includes a filter mechanism that uses the attributes defined for
the Resource.
Here is the Abstract:
This IPP Get Resource document specifies an extension to IPP/1.0
[RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document
extends the current closed IPP object model with a passive
polymorphic object that is intended to satisfy most needs for new
object types in the long-term evolution of IPP via an extensible
object framework.
This document defines: Resource object (passive polymorphic object);
Resource get operations (e.g., Get-Resource-Attributes); Resource
attributes (e.g., "resource-name"); new Printer attributes (e.g.,
"resource-type-supported"); Resource type of Driver (a morph of the
Resource object); methods for supporting 'driver download' to IPP
Client systems.
The Resource object has a number of REQUIRED and OPTIONAL attributes that
are independent of the resource type. We envision that one such resource
type would be 'font'. Each resource type would also define additional
attributes that are specific to that resource type. One of the Resource
attributes is resource-document-formats (1setOf mimeMediaType) which
indicates which document-formats each Resource instance is defined for,
e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client
could filter on the "resource-document-format" attribute to list, say, only
the PostScript fonts.
The resource data for a Resource object instance is envisioned being a
collection of files, packaged as a single file, using, say, zip. Thus font
metrics and font data could be separately represented. The IPP WG needs
review by the UPDF WG to see if the basic mechanism is a good foundation for
fonts and would meet your requirements for defining the 'font' resource
type. For example, the attributes for different types of fonts needs to be
different (we understand that the attributes for PostScript fonts and PCL
fonts have something in common, but a lot that is different).
Questions for the UPDF WG:
1. Is the basic framework sufficient for fonts?
2. Would you like to define the attributes for a 'font' resource-type?
3. For which document-formats?
4. What about other resources, such as device constraints?
<<UPDF and IPP - resource object.doc>>