Since email with attachments is blocked by the IPP reflector (even small
ones), the attachment that I refer to below is also posted at:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni
ts-for-font-size-requested.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni
ts-for-font-size-requested.doc
This is RESEND 1 or 2 for tomorrow's IPP WG telecon, July 19. (Yes, the "S"
and "P" are switched in the file name, sorry).
Tom
_____
From: Tom Hastings [mailto:tom.hastings at verizon.net]
Sent: Sunday, July 18, 2010 12:56
To: ipp at pwg.org; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald'
Cc: Daniel Bell; Gary Brown; Daniel Manchala; Peter Zehler; 'Tom Hastings'
Subject: Toward resolving Apple's IPP WG Last Call comment on changing the
units for "font-size-requested" from points to decipoints
Since the font, highlighting, and indentation will be smashed when this mail
message is turned to plain text, I've attached a 47 KB .pdf which is much
more readable, complete with line numbers to make it easier to discuss at
the telecon.
For the IPP WG telecon, tomorrow, Monday, July 19, here is input for the
agenda topic:
> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July
> -
>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl
> ean.pdf
> (ended Monday 12 July 2010)
>
> (6) Next Steps
> - IPP WG - Monday 26 July
> - IPP JPS2 into PWG Last Call?
Apple had made the following IPP WG Last Call comment:
2. The "font-size-requested" attribute uses points as the units, however it
should probably use a higher-precision unit (at least decipoints, or 1/720th
of an inch) to avoid issues with getting common fixed-width font spacing
right (e.g. 17 characters per inch with a standard Courier font would need a
point size of 5.293...) [And apologies for the late notice on this - I
haven't read through the older material in a while...]
I had the action item to contact Xerox about whether or not it had
implemented the "font-size-requested" based on the draft submitted to the
PWG in 2002. I had suggested the following possible alternatives to Xerox:
If Xerox hasn't really implemented the "font-size-requested" Job Template
attribute, Xerox should just agree to make the units be decipoints.
However, if Xerox has implemented the "font-size-requested" Job Template
attribute, what should the PWG do? Alternatives:
1. Xerox could argue that for real printing, the font size is
specified in the document data, NOT in the IPP protocol. In the document
data, the size of the font can be specified in finer units than points. So
as the description says, this attribute is only used with 'text/plain', or
'text/html' (when there is no font size specified in the html), so the need
for higher precision is not really needed.
2. Xerox could change its implementation.
3. Xerox could keep its implementation and ignore the PWG IPP standard
in this respect.
4. Xerox could make it an installation option or configurable setting
whether the Printer uses points or decipoints for this attribute.
5. Add a Printer attribute to the PWG spec that says what the units
are for "font-size-requested", say, "font-size-requested-units" (type2
keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT
supported, clients MUST assume the units are: 'decipoints'.
6. Add a Printer attribute to the PWG spec that says what the units
are for "font-size-requested", say, "font-size-requested-units" (type2
keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT
supported, clients MUST assume the units are: 'points'.
Any other suggestions?
The IPP WG Last Call comment period has been extended from June 21 (today),
to Friday July 9, so we have a little time to decide what to do and what to
recommend to the PWG.
Thanks,
Tom
Dan Bell responded that Xerox had a long standing implementation and would
be unlikely to change its implementation. He indicated his alternatives in
order of decreasing desirability, including adding an additional suggestion
#3 below:
Tom,
Thanks for the insights.
Xerox HAS implemented support for "font-size-requested", and it's been in
existence for a long time. I don't know how extensively it's used, but it's
there.
I would say it's highly unlikely that Xerox would be willing to change its
long-time existing implementation at this point.
For the proposed options of adding a "font-size-requested-units" attribute,
another option would be to make it a job-template attribute and have it
passed in the job along with "font-size-requested". Then a
"font-size-requested-units-supported" attribute could advertise what the
printer supports. And if a job is submitted with no
"font-size-requested-units" then either the device assumes it's points, or
uses the "font-size-requested-units-default" value.
In my opinion the acceptable options, in order of preference, would be:
1. Xerox could argue that for real printing, the font size is
specified in the document data, NOT in the IPP protocol. In the document
data, the size of the font can be specified in finer units than points. So
as the description says, this attribute is only used with 'text/plain', or
'text/html' (when there is no font size specified in the html), so the need
for higher precision is not really needed.
2. Add a Printer attribute to the PWG spec that says what the units
are for "font-size-requested", say, "font-size-requested-units" (type2
keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT
supported, clients MUST assume the units are: 'points'.
3. Add a Job template attribute to the PWG spec that what the units
are for "font-size-requested" for the job, say, "font-size-requested-units"
(type2 keyword) = 'points', 'decipoints'. If
"font-size-requested-units-supported" is NOT supported on the Printer,
clients MUST assume the units are: 'points'. If the job does not contain
"font-size-requested-units", the Printer's default value is used.
4. Xerox could keep its implementation and ignore the PWG IPP standard
in this respect.
To further support alternative #1, I urge the IPP WG to remember that the
very few "xxx-requested" Job Template attributes are ones that request the
Printer to do something, as long as the document data is silent on that
feature. If the document data does specify something, then the document
data takes precedence. The "font-size-requested" is one of the 3 Job
Template attributes whose precedence is lower than the document data.
Others are "font-name-requested" [JPS2] and "orientation-requested"
[RFC2911].
So the question is how likely is it that an application generates document
data in which it can supply font size in the data but fails to do so?
Or how likely is it that a user (1) received such a document or (2) received
a plain text document from somewhere that the user wants to specify the font
to a size more precisely than one point?
Here is the current full text of the "font-size-requested" Job Template
attribute which clearly describes these lower precedence attributes which
are intended only for text/plain and text/html document formats or
situations where the application could not or did not include the font size
in the document data:
7.3 font-size-requested (integer (1:MAX))
7.3.1 font-size-requested-default (integer (1:MAX))
7.3.2 font-size-requested-supported (1setOf rangeOfInteger (1:MAX))
The OPTIONAL "font-size-requested" Job Template attribute enables an IPP
client to specify what default font size the printer MUST use to print a job
if the document data is in a format that does not have inherent font
information (e.g., 'text/plain'). For document formats which have inherent
font information (such as PostScript), this attribute will be ignored and
will NOT override that information.
For some document formats (such as 'application/postscript'), the desired
default font size of the print-stream pages is specified within the document
data. This information is generated by a device driver prior to the
submission of the print job. Other document formats (such as 'text/plain')
do not include the notion of desired font size within the document data. In
the latter case it is possible for the Printer object to bind the desired
font size to the document data after it has been submitted. It is expected
that a Printer object would only support "font-size-requested" for some
document formats (e.g., 'text/plain' or 'text/html') but not others (e.g.,
'application/postscript'). This PDL-dependent behavior is no different than
any other Job Template attribute since a Printer object may support or not
support any Job Template attribute based on the document format supplied by
the client. However, a special mention is made here since it is very likely
that a Printer object will support "font-size-requested" for only a subset
of the supported document formats.
The "font-size-requested" units are points, equivalent to 1/72nd of an inch.
This attribute can be specified as a Document Override that affects the
Input-Document. The use of this attribute on a Page override basis is not
supported since changing the font characteristics can affect the pagination.
NOTE: The use of the "xxx-requested" pattern for attribute names indicates
that the value of the attribute is to be used ONLY in the case when a value
for the attribute is not contained within the source document. This value
will override the printer's default value but will not override the source
document's value. See the description of the "orientation-requested" Job
Template attribute in [RFC2911].
At the meeting tomorrow and/or on the mail list, the IPP WG needs to
consider the alternatives for resolving Apple's IPP WG Last Call comment.
Thanks,
Tom
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Sunday, July 18, 2010 09:06
To: ipp at pwg.org; Michael R Sweet; Paul Tykodi; Tom Hastings; Ira McDonald
Subject: Re: IPP Agenda - 4pm EDT Monday 19 July 2010
Hi,
REMINDER of tomorrow's IPP WG telecon
Cheers,
- Ira
On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald <blueroofmusic at gmail.com>
wrote:
> Hi,
>
> [rescheduled from 12 July - apologies for missing agenda posting]
>
> Reminder of our next IPP WG call:
>
> Monday 19 July - 1-2pm PDT / 4-5pm EDT
>
> Call-in toll-free number (US/Canada): 1-866-469-3239
> Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
> Call-in toll number (US/Canada): 1-408-856-9570 (Backup)
>
> Attendee Access Code: *******#
> Attendee ID Code: # (empty)
>
> If you need the Attendee Access code, please email me a request.
>
>
> *** Main Objective - move IPP JPS2 into PWG Last Call ***
>
> Agenda:
>
> (1) PWG IP Policy and Minute Taker
> - Mike?
>
> (2) Approve IPP minutes from last meeting
> -
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf
>
> (3) Status of IPP Version 2.0 Second Edition (Ira)
> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf
> (or later draft if available)
>
> (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira)
> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf
> (ended Monday 12 July 2010)
>
> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July
> -
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clean.pd
f
> (ended Monday 12 July 2010)
>
> (6) Next Steps
> - IPP WG - Monday 26 July
> - IPP JPS2 into PWG Last Call?
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic
>http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic at gmail.com
> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100718/121c7864/attachment-0001.html>