Re: Summary of the LSM Free Software Printing Summit

Roger Leigh wrote:
> ...
> of conflicts could be avoided.  With the CUPS web interface, could
> javascript be used to enforce constraints?

Yes, however that 1) wouldn't be 100% effective, since a lot of
people disable Javascript and unfortunately a lot of people still
use older versions of Netscape on obsolete OS's.  It might be
interesting for additional functionality, but we can't depend on
it.

That said, the web interface isn't what most users will use for
day-to-day printing, so I suspect it isn't a big deal - they just
have to click "continue" to see the constraints.

Also, if we *did* implement Javascript-based constraints in
addition to the current method, we would not gray the conflicting
options out but highlight them so that the user would know that
they will cause a conflict (in ESP Print Pro, we highlight
conflicting options and groups in red, on-the-fly).  Disabling or
graying out options can lead to option-lockout situations and is
also frustrating for users since there is no obvious indication
why they can't select it.  If you make them selectable in such
a way that the conflicting options/groups are also highlighted,
then it becomes fairly obvious which options need to be changed.

> > > ...
> > >  Note that for the translations of the main keyword it is used
> > >  as option keyword:
> > >  *InputSlot.French InputSlot/Papier source: ""
> > >  *InputSlot.German InputSlot/Papiereinzug: ""
> > >  This way it seems to work well for me - i.e. it passes cupstestppd
> > >  without any warning and it seems not to cause problems for
> > >  existing tools (i.e. the existing tools like xpp work exactly
> > >  as before - i.e. the added main keywords with the language
> > >  qualifiers are simply ignored).
> >
> > This sounds like a reasonable solution, however there are two
> > potential issues with it:
> >
> >     1. InputSlot and InputSlot.language share a common prefix;
> >        while this doesn't cause problems with CUPS, it *is* a
> >        violation of the spec - it just happens that the cupstestppd
> >        program doesn't test attributes for common prefixes at the
> >        moment...  I'm of the opinion that this is not a serious
> >        issue, and even if cupstestppd starts checking for common
> >        prefixes for attributes it can
>
>
> Is there any alternative that is compliant with the standard?

You could do:

    ll_CC.Keyword

which would be just as easy to lookup.

> >     2. The spec does not prevent a main keyword (option name)
> >        from having an option keyword (option choice) of the
> >        same name.
>
>
> Is this commonly used?

No, but it happens from time to time.

> ...
> > The major downside of PDF is that the support for printer-specific
> > job tickets is not standardized - that is something that PostScript
> > can do today.
>
>
> IIRC, I think it was mentioned that PPDs can be used to add PJL job
> options.  Are there any other alternatives?

That's the thing - Adobe has a PDF job ticket extension, but
currently it only supports a subset of the standard PS/PPD
options.  IIRC, Apple adds XML data containing the job options.

PPDs require some method of passing the option selections; you can
pass it in-line with the PDF file or externally.  Ideally, we'd
like to see the options in the PDF, since that keeps them with the
print data instead of external where they can be "lost" when passing
the job over non-IPP transports.

> ...
> Excellent.  The only disadvantage is that the location of the profile
> needs to be known in advance, so we can't (in the filter) look at all
> of the selected parameters and choose the most appropriate file
> ourselves, and inform the RIP of our choice (somehow).

The idea is that the PPD file expresses the ideal profile to use
for specific combinations of options - this information will
already be known at driver compilation time, so what is the point
of the driver telling the RIP at run-time?  Also, for user-defined
profiles, the profile name and/or data can be passed in with the
job, in which case the RIP filter will be told what the user
requested.

> The profiles might also have the potential to simplify our own colour
> and channel code, since I believe that the channel splitting could be
> done entirely by the RIP using our destination profile.

That is possible, however at present neither Ghostscript nor
Apple's Quartz-based filters nor the CUPS imagetoraster filter
can do N-channel, color-managed separations.  The approach we
are taking is to still do the CMYK->Device transform in the
driver (thus you have linear CMYK from the driver, and then the
profiles manage the source colorspace to linear CMYK part)

All of the current RIPs support CMYK, and providing a calibrated
CMYK colorspace in the driver makes it easier for users and
driver developers to effectively use their own color management
tools...

> ...
> > Backchannel support is in CUPS 1.2, coming soon to a server near
> > you! :)
>
>
> Yay!  Does this leave the parsing of the backchannel data entirely to
> the filter, or does the backend process it at all?

The filter, port monitor (new filter-like program to handle protocol
stuff like 1284 packet mode, TBCP encoding on PS printers, etc),
or backend can process it.  The standard CUPS backends don't
process the data, just pass it back.

> > > Paper handling
> > > - --------------
>
>
> > I would recommend a local message catalog with "generic" unit
> > strings as well as the standard sizes so that custom sizes can
> > be correctly expressed in multiple languages (e.g. 8.5x11" for
> > NA sizes and 210x297mm for the rest of the world...)
>
>
> I'm not sure what you mean here?  I don't intend the translatable
> strings to contain dimensions.  The sizes can be stored in whatever
> the ISO/US/UK/whatever spec defines them in and converted to the
> user's locale UoM at run-time and merged with the translations.

I am saying that na.letter can be "US Letter" (or whatever the
localized name is), but a na.custom.* size should be localized
using the dimensions, e.g. Custom 4x5".

--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click