Subject: IPP>MOD May 14 MOD meeting

From: [email-masked] (Administrator)
Date: Wed, 21 May 1997 15:43:35 -0400

On further reflection of some of the discussions and decisions made during the MOD meeting at StarTech, I believe we may have been too hasty in deleting the Font parameter requirements and relegating them to the printer MIB. Fonts are not always a property of the printer and in many cases may be rendered by the OS or other software. I think that fonts are an installed capability no different from a stapler attachment, media type, sides, finishing capabilities and should be specifiable on job submission. Further, specifying font substitutions is not much different than saying to pint the letter size document on A4 or legal because thats what is available. 
Can we put this back in? Comments?

Rob Kline

---

From: Scott Isaacson <[email-masked]>
Date: Thu, 22 May 1997 09:31:30 -0600

Rob asks:

>>> Administrator <[email-masked]> 05/21 1:43 PM >>>
> On further reflection of some of the discussions and decisions made during

> the MOD meeting at StarTech, I believe we may have been too hasty in 
> deleting the Font parameter requirements and relegating them to the
printer 
> MIB. Fonts are not always a property of the printer and in many cases may
be 
> rendered by the OS or other software. I think that fonts are an installed 
> capability no different from a stapler attachment, media type, sides,
finishing 
> capabilities and should be specifiable on job submission. Further,
specifying 
> font substitutions is not much different than saying to pint the letter
size 
> document on A4 or legal because thats what is available. 

The two attributes are:
font-substitutions (setOf setOf font)
printer-fonts (setOf font)

In the area of fonts, I think the original goal was to be able to query the
printer to find out what it had (printer-fonts) or what it would do
(font-substitutions) but there were no Job attributes that were associated
with the Printer attributes that could take advantage of this information
(i.e., there is no "requested-font" Job attribute).  All of the interactions
between a job, document data, fonts, and the printer would all be done
within the PDL. Also, the fonts where just named, not typed.  Also, this
font information is not "relegated" to the Printer MIB, it is purposefully
ignored in the Printer MIB.

In light of this idea that as far as fonts are concerned, IPP was only very
minimally providing a part of the solution, it seems better to not
standardize on a less than half solution, but wait till a more complete
solution could be proposed and standardized.

In summary:  Do these two attributes  add a lot of overhead to implement?
Probably not.  Do they provided some information? Yes.  Do they solve the
whole problem?  Definitely not.  Would some implementations be confused and
mislead if they implmented these attributes?  Yes.  The PWG has touched on
this for years and has always ignored it or punted wrt to the Printer MIB,
so should IPP do the same for right now?  Yes.

Scott

1.1.1.1 fonts-substitutions (setOf setOf font)
 This attribute specifies an appropriate substitute for a font that is
advertised as supported in the fonts-supported attribute, even though the
Printer doesn't actually have the font available.
This attribute consists of a set of font pairs: a font name and the font to
use instead.
If this attribute is unspecified, the Printer does not perform any font
substitutions.
1.1.1.2 scheduling-algorithm (type3 keyword, MANDATORY)
 This attribute indicates the current scheduling algorithm for this Printer.
 
Standard values are: 
  'none':
'smallest-job-first':
'time-received':

1.1.1.3 printer-fonts (setOf font)
 This attribute specifies what fonts are available at the Printer or
accessible to the Printer.  Documents may use these fonts without requiring
that the fonts be downloaded with the document data. 
The standard values are font names.
ISSUE: Should the IPP model include all information that is currently
contained in printer definition files such as PostScript's printer
definition (ppd) files?

---

From: [email-masked] (Rob Kline)
Date: Fri, 23 May 1997 10:59:35 -0400

While I agree that what was proposed may not be a complete solution to the font problem, I do believe that it is still useful. Given that we have now come up with a nicer way to negotiate paramenters for clients before the job is submitted, this will allow applications to offer a better interface than just lobbing the fully processed PDF for the server to reject. It's also possible that the fonts may be available on the client and some prerendering may be done or the fonts may be sent to the server in some other (legal) way. Please remember that postscript is not the only model for descibing print data.

The question is then: why are there some job template attributes such as sides, number up, finishing,  that can also be specified in the PDL included in the model, and fonts are not? It seems to me that fonts are rather fundamental, and that we should  provide at least basic support in the model, rather than to put it off until someone else can solve the problem completely.

Rob Kline
[email-masked]

	Scott Isaacson <SISAACSON @ novell.com> 	22/05/97 12:59 PM
To: ipp <ipp @ pwg.org> @ Internet, Administrator
cc:  Subject: Re: IPP>MOD May 14 MOD meeting

> the MOD meeting at StarTech, I believe we may have been too hasty in > deleting the Font parameter requirements and relegating them to the
printer > MIB. Fonts are not always a property of the printer and in many cases may
be > rendered by the OS or other software. I think that fonts are an installed > capability no different from a stapler attachment, media type, sides,
finishing > capabilities and should be specifiable on job submission. Further,
specifying > font substitutions is not much different than saying to pint the letter
size > document on A4 or legal because thats what is available. > Can we put this back in? Comments?

The two attributes are:

Scott

 This attribute indicates the current scheduling algorithm for this Printer