[Desktop_architects] Presentation slides - with attached templates

[Till Kamppeter]

Michael Sweet wrote:
> Till Kamppeter wrote:
> 
>> ...
>>      Perhaps distros should somewhere document for which config they
>>      have opted (for now one sees at least the settings in the config
>>      tool).
> 
> 
> PLEASE! :)
> 
> Actually, the new on-line help support in CUPS 1.2 allows you to just
> stick a HTML file (or files) in /usr/share/doc/cups/help which provides
> those details.  The files are automatically searchable and indexed...
> (somewhat primitive right now - you need to add anchors for all of the
> things you want to search/index, but easy to do!)
> 
> Perhaps we should include a template file in the CUPS distribution which
> can be patched by the distro packagers for the local changes?
> 

I did not know about that function. So I will make use of it for 
Mandriva 2007.

>>    – Poorly tested/integrated addons
>>      (cupsconfigdaemon,
>>      printconf, Foomatic)
>>
>>     -->
>>      Do not know anything about config daemon, which distro? Foomatic is
> 
> 
> Red Hat and SuSE both have cups-config-daemon.
> 

Mandriva does not use a config daemon for CUPS. USB printer hot-plugging 
is done by triggering a script with UDEV.

>>      needed for legacy printer support, as many drivers existed already
>>      before CUPS and there is no one volunteering to convert them to
>>      CUPS DDK. And there are vector drivers which cannot be converted
>>      to CUPS DDK. I would appreciate much if we reach a situation where
>>      there are no GhostScript built-in drivers any more (except plug-in
>>      interfaces "cups" and "ijs"). Foomatic was developed in times where
>>      there was active development on many spoolers, nowadays all except
>>      CUPS died, so now for new raster drivers it is really best to
>>      develop them with CUPS DDK.
> 
> 
> I'd *really* like to see Foomatic tie back into the CUPS 1.2 driver
> interface (I'll add a sample program soon that you can start with)
> so that driver discovery can happen in one place.
> 

I am looking forward for this. Sounds interesting.

>>    – Poor integration with iptables and SELinux
>>
>> ● Common tasks, e.g. add/delete/modify/share
>>   printers, are buried in strange places that are
>>   hard to find and/or use
>>
>>  -->
>>   Do you mean that every distro has its own config tools, with different
>>   user interfaces? Some more sophisticated some more basic? The same
>>   problem then also occurs for network, scanner, firewall, ...
> 
> 
> Yes, plus "standard" KDE and GNOME applications are exposed in
> different places.  This makes it very difficult for printer
> manufacturers to support more than a few Linux distros...
> 

If a driver is nicely integrated with CUPS (PPD file in 
/usr/share/cups/model, CUPS filter, CUPS backend if there are fancy 
bi-di features ...), EVERY printer admin tool should be able to set up 
the printer. Most manufacturers show how to proceed with web interface 
then, as it is always available.

>> CUPS: Dependencies
>> ------------------
>>
>> (projects and needs from each)
>>
>> ● List here – org name and what you need
>>    – GNOME, OpenOffice: Developer contact to improve
>>      printing support
>>
>>     -->
>>      OpenOffice really looks nice, at least all available queues can get
>>      selected and the PPD options are accessible, what misses are the
>>      CUPS-specific pstops options like N-up, etc.
> 
> 
> Right - right now simple things like printing a presentation N-up
> are not supported...
> 
>>      GNOME needs really improvement, they have a CUPS-supporting
>>      add-printer wizard, but they miss the PPD options in the "File" ->
>>      "Print" dialog (Owen Taylor is maintainer of this and should be
>>      contacted).
> 
> 
> Can you email us both (off-line) to do the intros?  Thanks!
> 

Someone please tell me the mail address of Owen Taylor, either in 
personal mail or protected (@ --> at).

>>    – KDE: Fix implementation of CUPS interface to work
>>      properly with domain sockets and IPv6
>>
>>     -->
>>      Contact the current KDE Print maintainer, Cristian Tibirna, tibirna
>>      at kde dot org.
> 
> 
> I already have bug reports in for the KDE issues and have been talking
> with them.
>

Great.

>>    – Linux distributors: Reliable developer contacts to
>>      come up with a common standard configuration that
>>      everyone can live with and have documented
>>    – linuxprinting.org: Stop using Ghostscript for
>>      PostScript printers!
>>
>>     -->
>>      Use of GhostScript for PostScript printers is not standard with
>>      linuxprinting.org. It is an exception, only being done if the
>>      printers is of a lower PostScript level than the PostScript input
>>      coming from the applications. It must be manually activated
>>      (usually GhostScript is not called) and is only needed for very old
>>      printers. The strategy applied by foomatic-configure and
>>      foomatic-ppdfile (current CVS) is to use manufacturer-supplied
>>      PPDs as they make all functionality and options of the printer
>>      available to the user. Only if there is no manufacturer-supplied
>>      PPD a generic PPD generated by Foomatic is used (so that at least
>>      printing works). With a manufacturer-supplied PPD GhostScript is
>>      never used with a generic PPD GhostScript is only used if the user
>>      explicitly tells that he wants it to be used.
> 
> 
> OK, that sounds different than the experiences a lot of users are having
> on the CUPS forums.
>

Can you post some links? Perhaps some people use a PostScript printer 
with a PCL driver.

>>
>>
>>
>> CUPS: Follow on Meetings
>> ------------------------
>>
>> (list of orgs and topics)
>>
>> ● Printing Summit 2006?
> 
>  > ...
> 
>>   The place and time when it should take place should be chosen that as
>>   many important people as possible would participate (suggestions?).
> 
> 
> Many of us are on the East coast, and the next LinuxWorld Expo is
> April 3-6 in Boston...  Perhaps we can set something up around that
> time?
> 

Good idea.

>>    – CUPS standardization between Linux distros?
>>
>>     -->
>>      The best way between "Everything equal" and the philosophies of the
>>      individual distros
> 
> 
> Not sure what this means; I'll be happy if the configurations are
> documented and there is some standardization on basic admin UI...
> 

Will document our config as shown above. Problem of common admin UI is 
mostly that every distro has added fancy features which are not 
available in web interface (Printerdrake: Plug'n'Print for USB printers 
with auto-generated queue names never longer than 12 characters, network 
scanning for TCP/Socket printers, some kind of "intelligence" to make 
manufacturer PPDs automatically be used whenever possible, ...). 
Printerdrake is free software, perhaps I should through all these 
features somewhere into the Foomatic CVS.

>>    – 32/64bit
>>      library support
>>    – Common printing tools and drivers to be shared
>>      amongst all distros?
>>
>>     -->
>>      Drivers used are already the same in all the distros, but the Grand
>>      Unified Printing Setup tool is still missing.
> 
> 
> I'm hoping that the new web interface will satisfy most users.
> 

It has great features, like the basic cupsd.conf options and the 
discovery of not yet configured local printers and two-click queue setup.

>>    – Also: ESP Ghostscript, CUPS DDK, CUPS
>>      Windows printer driver, CUPS PPD repository
>>
>>     -->
>>      GhostScript and drivers should be really separated from each other,
>>      using CUPS raster, IJS, and/or the OpenPrinting driver APIs, to
>>      make a change of the GhostScript generations less painful and to
>>      make adding drivers (both open and closed source) as easy as
>>      possible. If drivers are separate one can also make XPrint or
>>      Cairo talk directly to the drivers for a lightweight WYSIWYG
>>      infrastructure on embedded systems.
> 
> 
> Agreed!
> 
> All of the resources listed offer that separation, BTW...
> 

We need volunteers to separate out all the drivers which are currently 
compiled into GhostScript.

    Till