[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] What's next
From:       Robert L Krawitz <rlk () alum ! mit ! edu>
Date:       2006-08-03 23:09:09
Message-ID: 200608032309.k73N99il010657 () dsl092-065-009 ! bos1 ! dsl ! speakeasy ! net
[Download RAW message or body]

   Date: Thu, 03 Aug 2006 22:41:25 +0100
   From: "Alastair M. Robinson" <blackfive@fakenhamweb.co.uk>

   Robert L Krawitz wrote:

   > Another problem is that a lot of the infrastructure's still
   > 8-bit, and if we're doing color management in 8-bit space we're
   > going to have a lot of problems with rounding error.  The newer
   > versions of CUPS do support 16 bit depth, which helps.

   It does indeed.  But another way of side-stepping that problem is
   client-side ripping - as currently done by both PhotoPrint and the
   print plugin...

Yup, although that potentially makes for gigantic spool files and has
other issues.

   > Apple seems to have some way to allow printer drivers to pop up
   > their own panels and such, even in a CUPS environment.  I wonder
   > if we could do something like that in a conventional environment
   > also.

   Well, in a conventional environment, I guess that could be done by
   replacing lpr with a GUI app.  This is something I've considered
   experimenting with...

That only works if applications use lp/lpr to print.  If they use IPP,
it doesn't help them.

   > I'm concerned about varying printer gamuts -- something like the
   > R800 or R2400, for example, has a much wider gamut than a lot of
   > low-end printers, and the Canon iP9000 and friends may well have
   > even wider gamuts.  But it's an interesting idea.

   I forget off the top of my head how many sets of tuning tables we
   currently have - but it may be feasible to have roughly the same
   number of profiles.  I'm not suggesting this would provide accurate
   colours for all printers, but it might allow for more "pleasing"
   photographic output.

It certainly is an interesting idea that we should think about.

   > Sounds like a replacement for libgutenprintui2?

   Yes, in a way - we discussed libgutenprintui a few month back.  As
   it stands its insufficient for building anything other than a
   replica of the print plugin's UI.  What I want to do is expose
   several different levels to developers - so developers can use a
   pre-built dialog, or just a widget, as they wish.

I'd rather replace libgutenprintui2 with something cleaner; it sounds
like you're doing that.

   > Some of this is already in libgutenprintui2.

   Yes, indeed - and I shall look into "borrowing" much of that!

You'll probably need to borrow at least some of the printrc code, for
back compatibility.

   >    * Some way the application (or the widget library) can tell which
   >    options will invalidate a profile if changed, and which won't.
   > 
   > How would we define something like that?

   Well, I guess it could be as simple as a flag in the option definition...

I'd like to do it in a binary back compatible way (at least for 5.0 --
for 5.2 we can break binary compatibility).

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
[prev in list] [next in list] [prev in thread] [next in thread]