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 da=
ta.
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 completel=
y.
Rob Kline
robk at truespectra.com
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
Rob asks:
>>> Administrator <root at truespectra.com> 05/21 1:43 PM >>>
> On further reflection of some of the discussions and decisions made durin=
g
> 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:
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 interaction=
s
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=