Rob asks:
>>> Administrator <root at truespectra.com> 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.
> 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 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?