Subject: Re: static libgimpprintui - msg#00157

Previous Message by Date: click to view message preview

Re: static libgimpprintui

Am 27.05.04, 08:16 -0400 schrieb Michael Sweet: > That's not quite correct; drivers can communicate with applications > (although we don't recommend it for security and network transparency > reasons) and drivers control what kind of color information is > provided to them based upon options provided in the PPD file. > You can even ask for CIE XYZ or Lab color data from the RIPs... PPD - Postscript Printer Description. Can they contain all options available in an RIP and communicate them? So the print gui could show all PPD options, set them, give dependencies attention and send the job. Where can I find an startpoint to read more about PPD generation and handling? -- Kai-Uwe Behrmann ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Next Message by Date: click to view message preview

Re: static libgimpprintui

Robert L Krawitz <rlk@xxxxxxxxxxxx> writes: > From: Roger Leigh <roger@xxxxxxxxxxxxxxxxxxxxxx> > Date: Thu, 27 May 2004 00:46:55 +0100 > > Kai-Uwe Behrmann <ku.b@xxxxxx> writes: > > > Am 25.05.04, 23:09 +0100 schrieb Roger Leigh: > > > >> Robert L Krawitz <rlk@xxxxxxxxxxxx> writes: > > [static libgimpprintui] > >> I think I will probably just disable libgimpprintui being built for > >> now, and not package it. When libgimpprintui-gtk2 is ready for use, > >> that can be properly built and packaged. > > > > Why disabling and dont packaging libgimpprintui? It seems to work the old > > way. > > There are a few reasons, which I've attempted to detail below: > > There are actually two versions of the Debian packaging: the > version in the release tarballs, and the "official Debian version" > which goes into Debian proper. This might have a few extra > patches, and more restrictive dependencies. I try to keep them as > close in sync as possible, so this is not generally a problem. > > Again, it's inappropriate to make packaging decisions about Gimp-Print > based on the release processes of a specific distribution. It's up to > the distribution maintainers to do the distribution-specific packaging > within their distribution. Agreed. I've reverted the libgimpprintui change. The Debian packaging itself does need to take account of the current state of Debian, though--the build dependencies must be satisfiable or else it won't build. > Debian 3.1 "sarge" will come with 4.2.6 and that release will be > current for at least 1Â-2 years. > > Will it be possible to upgrade that to 4.2.7 when we do that? If it's prior to the freeze I think this will be possible. I certainly want to do so if possible. So far there's a couple of simple fixes from 4.2.7 in the 4.2.6 Debian diff (margins). > Since a few weeks ago, GIMP 1.2 was removed from unstable and so > the Print plugin is no longer buildable. With the current unstable > there is no need for libgimpprintui, and the current unstable is > always my target for development releases. > > So for the time being I'd prefer to leave it out--it's easier to add > later than it is to remove, and I don't want to add something that's > already obsolete. > > So you may want to take that out of the Debian packaging, but work > with Kai-Uwe on the Cinepaint aspects of this, since they need the 1.2 > version. Sure. The current cinepaint in Debian (0.18.3-3) does not have any dependencies on gimp-print packages. Can this version can use libgimpprintui if available? If so, libgimpprintui can be packaged prior to its inclusion in Debian proper if required. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_idï66&op=click

Previous Message by Thread: click to view message preview

Re: static libgimpprintui

Am 27.05.04, 08:16 -0400 schrieb Michael Sweet: > That's not quite correct; drivers can communicate with applications > (although we don't recommend it for security and network transparency > reasons) and drivers control what kind of color information is > provided to them based upon options provided in the PPD file. > You can even ask for CIE XYZ or Lab color data from the RIPs... PPD - Postscript Printer Description. Can they contain all options available in an RIP and communicate them? So the print gui could show all PPD options, set them, give dependencies attention and send the job. Where can I find an startpoint to read more about PPD generation and handling? -- Kai-Uwe Behrmann ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Next Message by Thread: click to view message preview

Re: static libgimpprintui

Date: Thu, 27 May 2004 14:57:18 -0400 From: Michael Sweet <mike@xxxxxxxxxx> Kai-Uwe Behrmann wrote: > Am 27.05.04, 08:16 -0400 schrieb Michael Sweet: > > >>That's not quite correct; drivers can communicate with applications >>(although we don't recommend it for security and network transparency >>reasons) and drivers control what kind of color information is >>provided to them based upon options provided in the PPD file. >>You can even ask for CIE XYZ or Lab color data from the RIPs... > > > PPD - Postscript Printer Description. Can they contain all options > available in an RIP and communicate them? So the print gui could show all > PPD options, set them, give dependencies attention and send the > job. The PPD format handles most types of user options; the missing types are text and numeric fields, however you can list common values and allow the user to pick from them. A future release of CUPS will support an extended option syntax that is backwards-compatible with the current PPD spec which will allow a user/application to know when an option can accept arbitrary input. The big missing feature is really curves; we have an acceptable (if ugly) workaround for floating point numbers. We have an XML representation for the curve data type, and adjusting the linearization curves may be very important. -- Robert Krawitz <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx Project lead for Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click