Subject: IPP> Fonts, Job Redirection, and Protocol

From: Bill Hastings <[email-masked]>
Date: Wed, 10 Dec 97 16:40:11 -0800

I'm fairly new to IPP so please excuse any "dumb" questions.

1) How can a client determine what fonts are available (built-in) in a 
PostScript Printer?

2) Is there an appropriate mechanism for redirecting a job after it has 
been sent to a printer? The only thing I can come up with is to save a 
copy of the job data on the client side, cancel the current job in 
progress, and resend the job to a new printer.

3) In the latest protocol document (dated 12/8/97), section 10.7 (example 
Get-Jobs Response) the last "localized-name" attribute is a compound 
attribute, but its format doesn't match the description given in section 
3.1. Which is correct?

Bill Hastings                               
RBI Software Systems
[email-masked]

---

From: Randy Turner <[email-masked]>
Date: Wed, 10 Dec 1997 20:50:31 -0500

> 1) How can a client determine what fonts are available (built-in) in a

Yeah! What ever happened to the GET-FONTS operation ;)

> progress, and resend the job to a new printer

Redirection of a job after it has been sent to the
printer must be done "out-of-band" to IPP 1.0. It might
be something to consider on a future rev. of the protocol.

..snip..

Randy

---

From: Tom Hastings <[email-masked]>
Date: Thu, 11 Dec 1997 09:58:24 PST

>1) How can a client determine what fonts are available (built-in) in a 

While we said that fonts were outside the scope of IPP V1.0, we could
add it using the registration mechanism after V1.0 is approved.

Now that we have the "document-format" as an input parameter to the
Get-Attributes operation, it would be very useful to have a
Printer Description attribute of "font-supported".  Then the proper
PostScript fonts could be returned when the "document-format" input
parameter was 'application/postscript' and would be the PCL fonts
when the input parameter was 'application/vnd.hp-PCL' would return
the PCL fonts.  Presumably the attribute syntax would be:

     font-supported (1setOf name)

Such an attribute would be a good candidate to propose to the PWG as
an attribute for registration as an extension following the procedures
for registering extensions in the Model document.

ISSUES:

We could even make it a Job Template attribute, like the current
"orientation" attribute which is only for document formats, like
'text/plain' that don't embed the font specification in the document
data.  Such an attribute may be more important for Asian countries where 
the document format is: 'text/plain; charset=utf-8' or 
'text/plain; charset=ISO-10646-ucs-2' (i.e., Unicode)
and they want to select a particular font.

snip...