[Printing-architecture] Re: [printing-driver] FSG Printer Wor
king Group conference call 03/26/03
TAYLOR,BOB (HP-Vancouver,ex1)
bobt at hp.com
Tue Mar 25 11:14:33 PST 2003
see inline -
bt
> -----Original Message-----
> From: Robert L Krawitz [mailto:rlk at alum.mit.edu]
>
> + Should we use
> - one existing standard
> PWG well known values (
> http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
> - two or more existing standards
> PWG and/or JDF
> - a new standard
>
> I don't like the fixed values at all; they basically try to
> force all papers into specific niches. For example, Epson
> offers a number of different photographic papers (Photo
> Paper, Premium Glossy Photo Paper, Premium Semiglosss, etc.),
> and each one has different characteristics. There are a lot
> of third party papers as well, and these also have different
> characteristics. Having the MediaTypeExtensionPattern is
> fine, but on Epson (and other inkjet) printers,
> "photographic-glossy" simply isn't a very useful description;
> there are enormous differences between different
> photographic-glossy papers, and it's important for the user
> to specify the precise paper by name. Subtle differences in
> the coating (which users generally can't distinguish except
> by name) require great differences; for example, when
> printing to Premium Glossy on the Stylus C80, it's important
> to not use black ink, which is formulated differently and
> doesn't adhere correctly to the paper. Other glossy photo
> papers should be printed with black ink, however.
<bt>
Agreed - and note that this is a good example of why we need to be able
to pass localized UI strings through the capabilities interface as well.
I don't think it's a reasonable expectation that all of these
rapidly-evolving
vendor-specific media types will be registered, much less actually supported
with localized strings in most clients.
</bt>
>
> * can there be default job properties or must every
> property be set?
>
> Defaults should be allowed. For example (using a Gimp-print
> property), a user should not have to specify the ink type;
> the driver should pick it automatically.
<bt>
Agreed - though we have found the need for a device/service to declare
that certain features !must! be specified - e.g., a fax phone number.
</bt>
>
> * should we have an interface to query the printer's job dialog?
> This will allow for programmatic support of
> setting/querying the JPs.
>
> Yes. This actually maps very well to Gimp-print,
> particularly in 4.3. It's a lot more flexible than a static
> file; expressing constraints using boolean logic can get
> extremely complex.
<bt>
Although we may want to provide an extension mechanism to get to a printer's
job dialog, I'd much rather see the core dialog be data driven. We've yet
to
find "extremely" complex constraints - in most cases they're pretty
reasonable.
Note that you end up defining these constraints someplace anyway - the
question
is whether you do it in code that's bound to an implementation or in a data
structure that can be evaluated in many implementations.
</bt>
More information about the Printing-architecture
mailing list