print plugin stuff
I noticed this entry in the Gimp change log: 2000-09-15 Asbjorn Pettersen <[EMAIL PROTECTED]> * plug-ins/print/print-ps.c (ps_parameters): use g_strncasecmp() instead of strncasecmp(). More portable. If there's a portability problem in the print plugin, please report it to [EMAIL PROTECTED] rather than doing this. The next time Mitch copies over the gimp-print source, this change will get lost. Also, the code in this file cannot use anything except standard C library stuff. This file (along with print-pcl.c, print-escp2.c, print-canon.c, print-util.c, print-dither.c, print.h, and print-weave.c) is also used as part of a Ghostscript driver, and as part of a CUPS driver, and we cannot rely on any system having any of the g* libraries around. Also, is there a specific system that doesn't support strncasecmp()? We haven't received any reports on it. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: print plugin
On 23 Feb, Sven Neumann wrote: > I hate to note that, but hopefully this will teach the one who applied > that patch in request of someone else, to check patches more > carefully before applying them. If you want to know who is ment here, > read the ChangeLog. But I think you already guessed it... I think you shot yourself into the foot. I guess you meant me and Marc but in fact I never touched the print plugin but ChangeLog says: Mon Jan 31 22:43:48 CET 2000 Sven Neumann <[EMAIL PROTECTED]> * libgimp/gimpcolorspace.c * libgimp/gimpcolorspace.h: added INTENSITY() macro [ ripped off a few entries ] * plug-ins/print/print-util.c * plug-ins/rcm/rcm_misc.h: use INTENSITY() and other color_conversion_routines from libgimp. I'm not sure if I have tested all this properly (I tried to do), so if you are bored, please play around with the changed plug-ins. I guess this one introduced it. However it could also have been this one: Mon Feb 7 12:57:16 CET 2000 Stanislav Brabec <[EMAIL PROTECTED]> * plug-ins/common/sparkle.c, plug-ins/common/bumpmap.c, * plug-ins/common/gz.c, plug-ins/common/tileit.c, * plug-ins/common/oilify.c, plug-ins/maze/handy.c, * plug-ins/print/print-util.c, plug-ins/sinus/sinus.c, * app/channels_dialog.c, app/fileops_cmds.c, * app/nav_window.c, app/path_tool.c, app/scan_convert.c, * app/xinput_airbrush.c, app/airbrush_blob.c: On request of Martin Weber <[EMAIL PROTECTED]>. Remove obsoletted rgb<->hsv routines, purifications. -- Servus, Daniel
Re: print plugin
Hi, > I think I know why Michael got his solid black output, and it had > nothing (really) to do with the bug fixes I did for 3.0.7. The > problem was that someone ripped out the calc_rgb_to_hsv and > calc_hsv_to_rgb functions I put in print-util and replaced them with > gimp_calc_rgb_to_hsv4 without taking a closer look at what's going > on. My functions operated on unsigned shorts (16 bits), while the > libgimp versions operate on unsigned chars (8 bit). So whenever > anyone used a saturation other than 1.0, the top 8 bits were > effectively stripped off the rgb values, making them close to zero > (and hence the cmy values close to 1). I'm surprised that a lot more > people didn't stumble over this. > > There are good reasons for the print code to be 16 bit -- 8 bit output > resolution is insufficient for printing when you take into account the > gamma that is required to get decent output. The highlight tones > (light areas) are compressed into a very narrow range, and in some > cases even 16 bits of resolution results in two input levels (between > 0 and 255) mapping into identical output levels. Please don't be too > quick to gratuitously change code like that. I hate to note that, but hopefully this will teach the one who applied that patch in request of someone else, to check patches more carefully before applying them. If you want to know who is ment here, read the ChangeLog. But I think you already guessed it... Salut, Sven
print plugin
I will be sending Sven the 3.0.8 patches shortly. I think I know why Michael got his solid black output, and it had nothing (really) to do with the bug fixes I did for 3.0.7. The problem was that someone ripped out the calc_rgb_to_hsv and calc_hsv_to_rgb functions I put in print-util and replaced them with gimp_calc_rgb_to_hsv4 without taking a closer look at what's going on. My functions operated on unsigned shorts (16 bits), while the libgimp versions operate on unsigned chars (8 bit). So whenever anyone used a saturation other than 1.0, the top 8 bits were effectively stripped off the rgb values, making them close to zero (and hence the cmy values close to 1). I'm surprised that a lot more people didn't stumble over this. There are good reasons for the print code to be 16 bit -- 8 bit output resolution is insufficient for printing when you take into account the gamma that is required to get decent output. The highlight tones (light areas) are compressed into a very narrow range, and in some cases even 16 bits of resolution results in two input levels (between 0 and 255) mapping into identical output levels. Please don't be too quick to gratuitously change code like that. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Patch for print plugin
Date: Tue, 15 Feb 2000 14:18:37 +0100 From: Aaron Optimizer Digulla <[EMAIL PROTECTED]> On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote: >Here is a patch for the print plugin. The patch fixes an anoyance >with the print dialog: If you have lots of printers (we have about >50 here), it takes *several minutes* to open. Fix: Just use lpstat >-d -v (just list the names of the printers instead of checking if >they are enabled; the information is discarded anyway). Later, when >it becomes clear that we can use that info, we can reenable it >again (including some kind of caching and a progress report which >shows that Gimp is still doing something). Ok, then only the second word (for) seems to be stable (the third always seems to be the printer name). Any other systems around ? On our specific systems, yes. I don't trust that something else won't be different. If you can test on Linux with a wide variety of different print systems (there are quite a few out there), different versions of Solaris and AIX, and if there's a BSD system running a SysV spooler, and demonstrate that it works on all of them, I will accept the patch. Otherwise, I won't accept this. > In the longer run, a more general solution to the printing problem is > needed. I agree. But the patch should be included nonetheless because it makes printing with Gimp possible :-) It helps you, but at the risk of breaking other people and hence regressing from 3.0.6 and 2.0 (== Gimp 1.0). As the maintainer of the plugin, I consider this patch too high risk to accept. As I said, though, if you can arrange for system testing and prove that it works on all of them without being overly convoluted, I will consider accepting it, but not otherwise. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Patch for print plugin
On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote:
>Here is a patch for the print plugin. The patch fixes an anoyance
>with the print dialog: If you have lots of printers (we have about
>50 here), it takes *several minutes* to open. Fix: Just use lpstat
>-d -v (just list the names of the printers instead of checking if
>they are enabled; the information is discarded anyway). Later, when
>it becomes clear that we can use that info, we can reenable it
>again (including some kind of caching and a progress report which
>shows that Gimp is still doing something).
>
> That patch AS IS isn't going to work. On my system (using
> PrintPro/CUPS), lpstat -d -v prints out in a slightly different
> format:
>
> $ lpstat -d -v
> system default destination: epson
> device for epson: parallel:/dev/lp0
> device for epson-big: parallel:/dev/lp0
> device for foo: /tmp/out
> device for null: /dev/null
Ok, then only the second word (for) seems to be stable (the third always seems
to be the printer name). Any other systems around ?
> Note that it uses "device" rather than "system". If you want to
> figure out how to make it work in general, go ahead -- it's a
> reasonable idea for 3.0.
>
> In the intermediate term, we're considering getting rid of all of this
> stuff and using some kind of printer definition dialog, partly because
> we haven't found any robust programmatic way of determining the list
> of printers on the system and partly because it's reasonable for users
> to want to define virtual printers with different combinations of
> settings. Something like that's likely to make it into 3.2 (after
> having been in 3.1 for a while) as part of a general overhaul of the
> UI.
>
> In the longer run, a more general solution to the printing problem is
> needed.
I agree. But the patch should be included nonetheless because it makes
printing with Gimp possible :-)
>*** gimp-1.1.16/plug-ins/print/print.c~Mon Jan 31 03:32:25 2000
>--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
>***
>*** 3146,3152
> #endif /* LPC_COMMAND */
>
> #ifdef LPSTAT_COMMAND
>! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
>{
>char name[17];
>
>--- 3146,3152
> #endif /* LPC_COMMAND */
>
> #ifdef LPSTAT_COMMAND
>! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
>{
>char name[17];
>
>***
>*** 3153,3159
>while (fgets(line, sizeof(line), pfile) != NULL &&
> plist_count < MAX_PLIST)
>{
>! if (sscanf(line, "printer %s", name) == 1)
> {
> strcpy(plist[plist_count].name, name);
> sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
>--- 3153,3159
>while (fgets(line, sizeof(line), pfile) != NULL &&
> plist_count < MAX_PLIST)
>{
>! if (sscanf(line, "system for %[^:]s:", name) == 1)
> {
> strcpy(plist[plist_count].name, name);
> sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by
improving the algorithms rather than by
buying a faster machine."
Re: Patch for print plugin
Date: Tue, 15 Feb 2000 13:50:27 +0100
From: Aaron Optimizer Digulla <[EMAIL PROTECTED]>
Here is a patch for the print plugin. The patch fixes an anoyance
with the print dialog: If you have lots of printers (we have about
50 here), it takes *several minutes* to open. Fix: Just use lpstat
-d -v (just list the names of the printers instead of checking if
they are enabled; the information is discarded anyway). Later, when
it becomes clear that we can use that info, we can reenable it
again (including some kind of caching and a progress report which
shows that Gimp is still doing something).
That patch AS IS isn't going to work. On my system (using
PrintPro/CUPS), lpstat -d -v prints out in a slightly different
format:
$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null
Note that it uses "device" rather than "system". If you want to
figure out how to make it work in general, go ahead -- it's a
reasonable idea for 3.0.
In the intermediate term, we're considering getting rid of all of this
stuff and using some kind of printer definition dialog, partly because
we haven't found any robust programmatic way of determining the list
of printers on the system and partly because it's reasonable for users
to want to define virtual printers with different combinations of
settings. Something like that's likely to make it into 3.2 (after
having been in 3.1 for a while) as part of a general overhaul of the
UI.
In the longer run, a more general solution to the printing problem is
needed.
*** gimp-1.1.16/plug-ins/print/print.c~ Mon Jan 31 03:32:25 2000
--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
***
*** 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
{
char name[17];
--- 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
{
char name[17];
***
*** 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL &&
plist_count < MAX_PLIST)
{
! if (sscanf(line, "printer %s", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--- 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL &&
plist_count < MAX_PLIST)
{
! if (sscanf(line, "system for %[^:]s:", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
Patch for print plugin
Here is a patch for the print plugin. The patch fixes an anoyance with the
print dialog: If you have lots of printers (we have about 50 here), it takes
*several minutes* to open. Fix: Just use lpstat -d -v (just list the names of
the printers instead of checking if they are enabled; the information is
discarded anyway). Later, when it becomes clear that we can use that info,
we can reenable it again (including some kind of caching and a progress
report which shows that Gimp is still doing something).
*** gimp-1.1.16/plug-ins/print/print.c~ Mon Jan 31 03:32:25 2000
--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
***
*** 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
{
char name[17];
--- 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
{
char name[17];
***
*** 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL &&
plist_count < MAX_PLIST)
{
! if (sscanf(line, "printer %s", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--- 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL &&
plist_count < MAX_PLIST)
{
! if (sscanf(line, "system for %[^:]s:", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by
improving the algorithms rather than by
buying a faster machine."
Re: Usage of Gnome libs (was: Re: Print plugin)
On 1 Feb, Sven Neumann wrote: > This is supposed to be first class font-rendering and if it prooves to > be useful, I see no reason not to use it, even it has gnome printed > on it. Well, if it really is first class rendering, then I'd like to see it in GIMP I haven't yet seen this package, is it in the CVS? >> > gnome-canvas for the UI (he draw routines we use on the gimp >> > canvas are very difficult to handle, using objects that can be >> > connected to and emit signals would make our live much easier) >> I didn't really get your point here > Look into the code that handles the bezier_curves UI. A good part of > that code is doing nothing but checking if the mouse is on a > control-point. Now imagine the control-points were objects that emit > signals like enter, leave, clicked etc. Do you start getting my point? Now I do but AFAIK gnome-canvas is a fixed part of gnome-libs, or am I anybody working on seperating it? >> Okay, I wouldn't even mind to make libart mandantory... > Why? libart was developed explictely to work w/o gnome-libs. It's an > extremly useful library that fits perfectly to our needs. Uhm, maybe I just can't get no real English sentence out of my keyboard, in other words: Okay, go for it, link it to the GIMP :)) >> Optionally this would be okay, although I prefer Rastermans >> Imlib2... It may be that gdk-pixbuf focuses too much on the needs of >> a desktop or were there any other reasons to go away from Imlib? > All I know about Imlib2 is that is has a lot of features we will never > need. For example? Everything that is in Imlib2 so far would be also usable for the kind of actions you mentioned > I don't see why gdk-pixbuf looks desktop-centric to you, That's my conclusion from the GNOME team wlaking away from Imlib and Imlib2... why else should they do that? > but it certainly has a small memory-footprint, is fast and it > integrates nicely with GTK+. GTK+? You meant gdk I guess and so does Imlib as well >> I think the preferences dialog is very nice, anyway I'd prefer using >> XML as a save format for configureations and even for scripts. >> This would make macro recording possible... But having a centric >> configuration possibility for GIMP doesn't make any sense to me >> anyone out there who would like to configure it via GNOMEs >> control-center or via console? :)) > Did I say control-center? gconf is the new replacement for the control-center > Daniel, this is FUD! You talk about using XML. Sven, gconf uses gnome-xml for storing preferences data, and that's something I really like about it > Do you want to write your own parser? Why? It's already there... and I really like the idea of getting away from our current system... > I'm not advertising gnome-conf since I don't know much about it, I > just mentioned it as an example of stuff that might be of interest. Well, gconf is designed as a general purpose configuration system which can use several backends for storing it's data and several frontends for modifying preferences. > Let's argue about using GNOME. It does not make sense to turn your > head only if something has GNOME written on it. I don't have anything against GNOME... I like it in fact because the whole desktop environment has a small memory footprint and is fast compared with KDE. But I really doubt it is good for ANY big project which is not really related to GNOME to depend on it > And remember: this has > nothing to do with the desktop, the control-center or whatever. All we > are talking about is if we want to use selected parts of the > libraries that evolved around gnome. The good thing about these libs > is that they are maintained and integrate nicely with GTK+ and its > object system. Great, then we're on the same side > As said before, a lot depends on the will of the GNOME people to > release those libs in small packages without throwing too much > gnome-specific stuff into them. I think we would already use the > canvas now if it would have been released seperately. > (gnome-xml)<- not sure if we will need this one I think this could be very useful > With the execption of the canvas all this is AFAIK already available > outside of gnome-libs. Sven, I don't really know why you are arguing against me; It really seems like we do have the same things in mind so let's spend our time on realising them -- Servus, Daniel
Re: Usage of Gnome libs (was: Re: Print plugin)
On Tue, Feb 01, 2000 at 05:07:01PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > > gnome-canvas for the UI (he draw routines we use on the gimp > > I didn't really get your point here > > Look into the code that handles the bezier_curves UI. A good part of The problem with gnome is solely that its monolithic, without the need to be so. If that will be resolved (which seems naturally for me), no problem. In the past, however, the gnome people did not like to do that for us... > > Okay, I wouldn't even mind to make libart mandantory... > > Why? libart was developed explictely to work w/o gnome-libs. It's an > extremly useful library that fits perfectly to our needs. Thats probably the reason why he does NOT mind to make it mandatory ;) > Did I say control-center? Daniel, this is FUD! You talk about using XML. > Do you want to write your own parser? Nobody needs that. expat is available freely, small, extremely fats and portable. Most languages (python, perl) have already interfaces to it. And we could even use the "proprietary" gnome-xml package, if it is self-contained. BTW, the much more important problem (for me) of plug-in management would be helped a lot if a dependable xml parser were available (I'll just requite expat on developer machines), since I'd like to use the OSD (w3's open software description) format (an XML application) to store plug-in information. > evolved around gnome. The good thing about these libs is that they are > maintained and integrate nicely with GTK+ and its object system. As > said before, a lot depends on the will of the GNOME people to release > those libs in small packages without throwing too much gnome-specific That bad thing is that most of that stuff is monolithic. And the gnome people were very reluctant in the past to seperate their beloved gnome-libs into its conmponents. I don't believe this will change. > stuff into them. I think we would already use the canvas now if it would > have been released seperately. Exactly. > (gnome-xml)<- not sure if we will need this one I still wonder why they didn't use proven and fast technology (expat), and invented their own system (which is slower and has more bugs). > With the execption of the canvas all this is AFAIK already available > outside of gnome-libs. Then we should consider it. However, "outside gnome-libs" does not mean that these libraries do not require it. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Usage of Gnome libs (was: Re: Print plugin)
Hi, > > gnome-fontfor font-rendering (don't know if gnome-2.0 will have > > this) > > I doubt that this would be of any real use, we want to have first class > rendering into GIMP with no eye on speed and such opposing to the > font-rendering of applications where rerendering happens quite often... > This is supposed to be first class font-rendering and if it prooves to be useful, I see no reason not to use it, even it has gnome printed on it. > > gnome-canvas for the UI (he draw routines we use on the gimp > > canvas are very difficult to handle, using objects that can be connected > > to and emit signals would make our live much easier) > > I didn't really get your point here Look into the code that handles the bezier_curves UI. A good part of that code is doing nothing but checking if the mouse is on a control-point. Now imagine the control-points were objects that emit signals like enter, leave, clicked etc. Do you start getting my point? And there's a lot more you can do with the gnome-canvas... > > libartprovides convenient and optimized functions for all > > sorts of affine transformations > > Okay, I wouldn't even mind to make libart mandantory... Why? libart was developed explictely to work w/o gnome-libs. It's an extremly useful library that fits perfectly to our needs. > > gdk-pixbuf > > image-loading and simple (but fast) transformations (we may want > > to use this to implement a proper brush and patterns system > > since it integrates nicely with libart which would give us > > scalable, rotatable brushes/patterns for free) > > Optionally this would be okay, although I prefer Rastermans Imlib2... > It may be that gdk-pixbuf focuses too much on the needs of a desktop > or were there any other reasons to go away from Imlib? All I know about Imlib2 is that is has a lot of features we will never need. I don't see why gdk-pixbuf looks desktop-centric to you, but it certainly has a small memory-footprint, is fast and it integrates nicely with GTK+. > > gconf for configuration (have a look into the code for the > >preferences-dialog, it sucks badly ...) > > I think the preferences dialog is very nice, anyway I'd prefer using > XML as a save format for configureations and even for scripts. This would > make macro recording possible... > But having a centric configuration possibility for GIMP doesn't make > any sense to me anyone out there who would like to configure it via > GNOMEs control-center or via console? :)) Did I say control-center? Daniel, this is FUD! You talk about using XML. Do you want to write your own parser? I'm not advertising gnome-conf since I don't know much about it, I just mentioned it as an example of stuff that might be of interest. Let's argue about using GNOME. It does not make sense to turn your head only if something has GNOME written on it. And remember: this has nothing to do with the desktop, the control-center or whatever. All we are talking about is if we want to use selected parts of the libraries that evolved around gnome. The good thing about these libs is that they are maintained and integrate nicely with GTK+ and its object system. As said before, a lot depends on the will of the GNOME people to release those libs in small packages without throwing too much gnome-specific stuff into them. I think we would already use the canvas now if it would have been released seperately. My list of stuff that is IMHO definitely worth to be considered: libart gnome-canvas gdk-pixbuf gnome-print (gnome-xml)<- not sure if we will need this one gnome-font <- when it becomes available and looks suitable With the execption of the canvas all this is AFAIK already available outside of gnome-libs. Salut, Sven
Print plugin now in Source Forge
I have put the development version of the plugin (release 3.1.0) in SourceForge (http://sourceforge.net). This is a service provided by VA Linux Systems to the open source community for hosting development projects, among other things. I've decided to do this for the following reasons: 1) SourceForge provides a complete hosting solution, including disk space, shell accounts, CVS service, mailing lists, web sites, and much more that I'm only just beginning to explore. VA seems committed to this service, and they are backing it with substantial hardware and people resources. 2) I want to decouple the Print plugin development from Gimp development as a whole. Currently there is a stable branch (3.0) that will have occasional bug fixes and possibly minor enhancements that do not impact stability. I'm looking forward to a great 3.2 release, but that will require a fair bit of development, and I want to make it available to the widest possible audience without destabilizing the version in the Gimp (I think things will get very unstable for a while with support for some of the newer printers). If we get enough stable code in 3.1, we might back port it to 3.0 for inclusion into the Gimp. 3) SourceForge has a large development community of its own, and hopefully we can draw upon the efforts of a broader community. 4) The whole issue of high quality printing in Linux (and Unix in general) seems to be a real hash right now. Ghostscript lacks a lot of stuff that's required (such as two-way communication between the printer and the driver, and between the driver and the application). CUPS looks more promising technically, if the mindshare develops. I think that the Print plugin as any more than a glue layer and UI should eventually go away altogether. This is better addressed in an environment like SourceForge than within the Gimp alone. The Gimp has a lot to contribute in this area -- it's a sophisticated graphical application with demanding output requirements -- but a lot of this stuff needs to happen at a lower level. I'd like to invite everyone here to check out SourceForge, and register for an account. There are two mailing lists, gimp-print-devel and gimp-print-announce. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Print plugin
The current Gimp plugin (3.0.5) is a stable release at this point. I will accept bug fixes, and support for new printers only if these can be expressed in terms of functionality already in the plugin. I'm starting work on a new development release (3.1) that will lead to a 3.2 release. The goals for 3.2 currently are: 1) Support for more printers. I particularly want to support the current generation of Epson printers (440/640/740/900/750/1200) and Canon printers, since these seem to be among the more popular printers around, but if anyone wants to contribute a driver for something else, please feel free to do so. Note that my only printer is currently an Epson Stylus Photo EX, so I need help here. Testers will be welcome, but I'd like people who have one or more of these printers (in particular, the 740, 900, 750, or 1200) who are not afraid to dig into the innards. 2) Clean up the dialog. The dialog is currently a real mess. For one, the save settings stuff really doesn't work correctly. There are a number of other things I'm considering here. Anyone who actually understands human factors should feel free to contribute. 3) Start the process of decommissioning the plugin (more or less) altogether :-) In other words, this business of each application supplying its own printer driver is nuts, but I've read a lot of comments that Ghostscript's dithering is awful, and that that really isn't the fault of the individual output drivers within it... 4) Clean up the configuration process so that it really can be built as a standalone plugin or as part of the Gimp distribution. 5) Performance improvements consistent with high quality. I'm willing to consider high performance, reduced quality modes as long as the sacrifice in development effort isn't too high, but I think that for the Gimp the emphasis should be on high quality output rather than fast rendering time. 6) Support for 16 bit Gimp (let's lead the way rather than follow). 7) Work with printer manufacturers whenever possible, and try to sell them on opening their own drivers. 8) More separation between the rendering engine and the printer drivers. I've separated the drivers and engine from the UI in 3.0; in 3.2 I want to further break things down to make it easier to add new stuff. 9) Quality improvements. This is a matter of taste; with some printers I've seen that it's possible to improve quality in one dimension (e. g. speckling) at the expense of something else (tonality and hue continuity). I'm a photographer (serious amateur) myself, and my bias is toward good tonality and color at the expense of some grain, but others disagree. Perhaps this should be configurable if we can't come up with algorithms that allow us to do both well. I will be putting the 3.1 development tree on Sourceforge as soon as I get to a reasonably stable point (i. e. things compile). Note that early 3.1 releases may have lots of regressions; I'm working on multibit pixels right now... -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Update to the print plugin
Date: Fri, 29 Oct 1999 08:52:51 -0400 From: Michael Sweet <[EMAIL PROTECTED]> Robert L Krawitz wrote: > ... > The other part of the problem is that an equal mix of CMY doesn't > actually produce a neutral gray, particularly when the use of light > inks is taken into account. Right now I'm using a ratio of > > K = C + 9M/8 + 3Y/2 > > to get a reasonable gray balance, and of course this will vary with > different inks. That's where my color correction stuff comes in; you can control this fairly easily with a color transform matrix... Sounds good. > I've seen prints made with softweaving, and I think that the > 30-minute print job produces better quality than any softweave I've > seen thus far. I'd like to offer it as an option for someone who Even with the "real" EPSON drivers on the PC? They use softweaving exclusively for most of their printers now, and they do get "photo" quality with it (as long as you don't have a clogged jet, that is ;) Yup, even compared to Windows output, the "ultra-slow" stuff still shows less sign of microbanding or striping. This was not the same printer sample; it's conceivable that the other printer was in less than perfect condition.
Re: Update to the print plugin
Robert L Krawitz wrote: > ... > The other part of the problem is that an equal mix of CMY doesn't > actually produce a neutral gray, particularly when the use of light > inks is taken into account. Right now I'm using a ratio of > > K = C + 9M/8 + 3Y/2 > > to get a reasonable gray balance, and of course this will vary with > different inks. That's where my color correction stuff comes in; you can control this fairly easily with a color transform matrix... > ... > I've seen prints made with softweaving, and I think that the > 30-minute print job produces better quality than any softweave I've > seen thus far. I'd like to offer it as an option for someone who Even with the "real" EPSON drivers on the PC? They use softweaving exclusively for most of their printers now, and they do get "photo" quality with it (as long as you don't have a clogged jet, that is ;) -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: Update to the print plugin
BTW, I've put a new version on http://www.tiac.net/users/rlk/print.tar.gz. This one improves the smoothness of regions of mixed Cc and Mm (light and dark cyan and magenta); that's about the only difference. Date: Thu, 28 Oct 1999 15:37:26 -0400 From: Michael Sweet <[EMAIL PROTECTED]> Robert L Krawitz wrote: >4) The K->CMY code is distinctly tuned for the Stylus Photo EX > right now. Sorry, I don't have another color printer to play > with. > > This should be addressed, but it won't be unless we get testers. GCR and UCR can be a pain to get right. Here's a possible solution based on the CMYK generation code we're currently using in CUPS: ... This reduces the amount of black based on the saturation of the color (more saturated means less black), and uses a GCR function/lut to control the final amount of black. The intent of doing this isn't to improve saturation, but rather to minimize pixelation/graininess in bright (little ink) highlights. In fact, it's largely in UNsaturated regions (even light to medium grays!) that I want to eliminate the use of black altogether, to create a smooth texture. The other part of the problem is that an equal mix of CMY doesn't actually produce a neutral gray, particularly when the use of light inks is taken into account. Right now I'm using a ratio of K = C + 9M/8 + 3Y/2 to get a reasonable gray balance, and of course this will vary with different inks. A simple implementation might just use a cutoff level and ramp the values starting at the cut-off point, e.g.: int GCR[256]; int GCRlevel; for (i = 0; i < GCRlevel; i ++) GCR[i] = 0; for (; i < 256; i ++) GCR[i] = 1 + (i - GCRlevel) * 254 / (255 - GCRlevel); That's similar to my approach, although not with a lookup table (look for KDARKNESS_LOWER, which is your GCRlevel, and KDARKNESS_UPPER, which is an upper bound at which we simply use all black). Actually, kdarkness is a function of the other color intensities; the darker the other colors are, the more black mixes in. We're looking into doing something similar for CUPS 1.1 that will also provide a gamma (power) value for the GCR LUT. >5) The Stylus Photo printing has become very slow for some reason > (at least at 720 dpi). On the other hand, the > microweave-induced banding has entirely vanished, yielding > much (arguably spectacularly) better quality. I'm not > positive exactly what did this, but it's not at the top of my > list of priorities to "fix". If it takes 30 minutes to print a > really high quality full-page print that doesn't seem so bad. > > Not to be fixed, since this "problem" improves output quality > substantially in the highest quality output mode. 30 minutes is way too long. I'm still wrangling with EPSON over the softweave algorithm; hopefully we'll be able to include the code in a future print plug-in/CUPS driver, which lowers print times significantly. I've seen prints made with softweaving, and I think that the 30-minute print job produces better quality than any softweave I've seen thus far. I'd like to offer it as an option for someone who wants the absolute maximum quality. I have some softweave stuff generated from other applications; even if you can't include it, I may be able to reverse engineer it purely from generated output. I think someone already has for Ghostscript. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Update to the print plugin
[sigh... I wish I wasn't such a busy camper these days!]
Robert L Krawitz wrote:
> ...
>1) print.c is a real mess right now. All the settings-handling
> code is ad hoc and very ugly, and there's a lot of knowledge
> scattered about the code.
>
> Not directly necessary to fix for release (unless someone wants to
> :-)). However, cleaning this up may make fixing the save/load code
> easier to fix.
Actually, I've completely rewritten the GUI code so it can use the PPD
stuff from CUPS. My efforts are not yet quite finished, but I'll let
everyone know once I have something to play with.
>2) As noted, the settings save/load code isn't perfect. It's OK
> for beta (or development), but not really for a release.
>
> Should be fixed for release.
Doesn't look like it'll be too hard to fix.
>3) Printing at 360 dpi (on the Stylus Photo) yields slightly
> reddish grays. I'm not quite sure what to make of it. 360
> ...
>
> I don't have a strong opinion on this. I consider 360 dpi mode to
> be purely for proofing and I'm not overly concerned with details,
> but on the other hand if people find the color cast too
> objectionable it should be fixed.
I have some new color correction code that'll be going into the "real"
3.0 release :) that should take care of that.
>4) The K->CMY code is distinctly tuned for the Stylus Photo EX
> right now. Sorry, I don't have another color printer to play
> with.
>
> This should be addressed, but it won't be unless we get testers.
GCR and UCR can be a pain to get right. Here's a possible solution
based on the CMYK generation code we're currently using in CUPS:
c = 1 - r
m = 1 - g
y = 1 - b
k = min(c,m,y)
w = max(c,m,y)
k = GCR(k * k / w)
if (k < 1)
{
c = (c - k) / (1 - k)
m = (m - k) / (1 - k)
y = (y - k) / (1 - k)
}
else
c = m = y = 0
This reduces the amount of black based on the saturation of
the color (more saturated means less black), and uses a GCR
function/lut to control the final amount of black. A simple
implementation might just use a cutoff level and ramp the
values starting at the cut-off point, e.g.:
int GCR[256];
int GCRlevel;
for (i = 0; i < GCRlevel; i ++)
GCR[i] = 0;
for (; i < 256; i ++)
GCR[i] = 1 + (i - GCRlevel) * 254 / (255 - GCRlevel);
We're looking into doing something similar for CUPS 1.1 that will
also provide a gamma (power) value for the GCR LUT.
>5) The Stylus Photo printing has become very slow for some reason
> (at least at 720 dpi). On the other hand, the
> microweave-induced banding has entirely vanished, yielding
> much (arguably spectacularly) better quality. I'm not
> positive exactly what did this, but it's not at the top of my
> list of priorities to "fix". If it takes 30 minutes to print a
> really high quality full-page print that doesn't seem so bad.
>
> Not to be fixed, since this "problem" improves output quality
> substantially in the highest quality output mode.
30 minutes is way too long. I'm still wrangling with EPSON over the
softweave algorithm; hopefully we'll be able to include the code in
a future print plug-in/CUPS driver, which lowers print times
significantly.
--
__
Michael Sweet, Easy Software Products [EMAIL PROTECTED]
Printing Software for UNIX http://www.easysw.com
Update to the print plugin
I discovered a fairly nasty bug in 6-color mode in which there was a discontinuity at the point that 6-color mode kicked in. Depending upon the orientation of the gradient, the effect is either a dark line of the color in question (cyan or magenta) or a white line. I had thought it was a print head misalignment until I decided to take a closer look. There was a related bug in 4-color mode; the symptoms probably would be similar. In either event, there's a new version on my web site: http://www.tiac.net/users/rlk/print.tar.gz. As for the issues I identified in my last message, here is how I propose to handle them: Notable issues with the current code (I consider all of these minor). 1) print.c is a real mess right now. All the settings-handling code is ad hoc and very ugly, and there's a lot of knowledge scattered about the code. Not directly necessary to fix for release (unless someone wants to :-) ). However, cleaning this up may make fixing the save/load code easier to fix. 2) As noted, the settings save/load code isn't perfect. It's OK for beta (or development), but not really for a release. Should be fixed for release. 3) Printing at 360 dpi (on the Stylus Photo) yields slightly reddish grays. I'm not quite sure what to make of it. 360 dpi is proofing resolution, and I'm not all that worried about perfection there (I'm more concerned about a much smaller greenish or cyan cast at 720 dpi, and a possible slight blue-magenta cast in lighter tones). I don't have a strong opinion on this. I consider 360 dpi mode to be purely for proofing and I'm not overly concerned with details, but on the other hand if people find the color cast too objectionable it should be fixed. 4) The K->CMY code is distinctly tuned for the Stylus Photo EX right now. Sorry, I don't have another color printer to play with. This should be addressed, but it won't be unless we get testers. 5) The Stylus Photo printing has become very slow for some reason (at least at 720 dpi). On the other hand, the microweave-induced banding has entirely vanished, yielding much (arguably spectacularly) better quality. I'm not positive exactly what did this, but it's not at the top of my list of priorities to "fix". If it takes 30 minutes to print a really high quality full-page print that doesn't seem so bad. Not to be fixed, since this "problem" improves output quality substantially in the highest quality output mode. 6) Entirely get rid of the 8-bit rendering when the 16-bit rendering is tested for all of the various rendering functions on a reasonable variety of hardware. Remove this code at release. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Print plugin 3.0
I've made what I expect will be the last major changes to my version of the print plugin for a while, and renumbered it. It's at http://www.tiac.net/users/rlk/print.tar.gz. Notable changes: 1) All per-printer settings are now saved in the printrc file. This isn't perfect yet -- the settings for the File printer aren't saved now, and the scaling setting isn't correctly saved for printers that you haven't accessed (they default to 5% of the image size, which is just silly). 2) I've moved all glib, gimp, and gtk+ code into print.c -- print.h, print-escp2.c, print-ps.c, print-pcl.c, and print-util.c no longer have any references to anything not in standard C header files. The purpose of this is to improve portability if/when I or someone else wants to make this into a more general rendering engine. Everything is handled by means of (what amount to) method calls on Image objects, which encapsulate the actual GIMP calls. 3) I've removed all of the 8-bit rendering code -- it now does everything in 16 bit. This makes for much higher quality in some circumstances, particularly light tones. Actually, the 8-bit code was unused, but tonight I removed it (although there are still a few routines #ifdef'ed out in print-util.c). 4) I've updated all of the copyright notices to refer to Mike Sweet and myself, and bumped the version to 3.0 (which may be a bit presumptuous on my part :-) ). Notable issues with the current code (I consider all of these minor). 1) print.c is a real mess right now. All the settings-handling code is ad hoc and very ugly, and there's a lot of knowledge scattered about the code. 2) As noted, the settings save/load code isn't perfect. It's OK for beta (or development), but not really for a release. 3) Printing at 360 dpi (on the Stylus Photo) yields slightly reddish grays. I'm not quite sure what to make of it. 360 dpi is proofing resolution, and I'm not all that worried about perfection there (I'm more concerned about a much smaller greenish or cyan cast at 720 dpi, and a possible slight blue-magenta cast in lighter tones). 4) The K->CMY code is distinctly tuned for the Stylus Photo EX right now. Sorry, I don't have another color printer to play with. 5) The Stylus Photo printing has become very slow for some reason (at least at 720 dpi). On the other hand, the microweave-induced banding has entirely vanished, yielding much (arguably spectacularly) better quality. I'm not positive exactly what did this, but it's not at the top of my list of priorities to "fix". If it takes 30 minutes to print a really high quality full-page print that doesn't seem so bad. 6) Entirely get rid of the 8-bit rendering when the 16-bit rendering is tested for all of the various rendering functions on a reasonable variety of hardware. Notable things for the future (until it's replaced by a real printing architecture): 1) User-defined pseudo-printers (essentially, sets of settings) and default settings for newly-defined printers (currently it just uses defaults of 100% for everything). 2) Printer-specific settings. For example, for the Stylus Photo allow specification of microweave mode, and softweave if that's ever implemented (softweave is reasonably fast, but not especially high quality). This would solve the issue of slow printing, since the user would have more options to select from. 3) More general rendering methods (currently everything is scan-line-in/raster-out, which makes it harder than it should be to do clever dithering or print to devices that expect multiple raster lines grouped together). Currently extremely light tones show shadowing artifacts from the unidirectional error diffusion. I've improved it some by randomizing the print threshold, but it isn't perfect. 4) Text boxes for absolute size/positioning, rather than just scaling and a move-rectangle-in-box interface. 5) More devices! More devices! And dynamic loading of drivers (which might be overkill for this application, but it sure would be nice if Ghostscript could do it!) 6) Specific improvements in rendering quality are always a Good Thing (tm). 7) Merging dither_cmyk4_16 (4-color, 4-level) with dither_cmyk16 (6-color, 2-level). This will be required to properly support the Stylus Photo 750/1200 and probably some of the other new-generation photo printers. Likewise, dither_black4_16 with dither_black16. 8) Dark midtones show some splotching caused by mixing CMY and K. Generally this manifests itself as somewhat washed-out colors and pale dark grays, rather like a print from an underexposed negative. I've had enough beating my head against this for now. Notable issues for me: 1) I want to cut down on my
More print plugin improvements (substantially better quality!)
I got some significant improvements in print quality in the latest version on my web site. These improvements are probably specific to the Epson Stylus Photo printers; the gamma and density values were all wrong. There are some other changes, too: 1) A density control (this is multiplied by the printer's density value that feeds into the LUT computation). 2) The gamma control has been completely redone. It is now divided by the printer gamma correction factor to derive a true printer gamma. This means that you should always start with the gamma correction at 1.0 and adjust from there (it's now reasonable to start with ALL controls at 1.0). It also means that the gamma adjustment will have the opposite effect of what it previously had, but the new meaning is, I believe, correct. Another oddity I noticed tonight -- for some reason (I'm not sure what I changed), my printer's printing very slowly, but very high quality -- none of the usual microweave banding, it's perfectly smooth. That's OK by me. Printing at high resolution SHOULD yield the very best possible quality. I've also included a binary (for Gimp 1.1.0 and glibc 2.1) in the distribution package, to save people some effort. Regis, could you try this binary (it's the exact bits I'm using right now to print one of my favorite test patterns). http://www.tiac.net/users/rlk/print.tar.gz, as usual. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
More updates to the print plugin (need some testers)
I've updated the print plugin to do all dither calculations in 16 bits. Thus far I've been too cowardly to simply rip all of the 8-bit code out, but that might be my next step if I've actually done everything correctly. The 16 bit calculations significantly improve tonal reproduction in the highlights. In 8 bits, there's a lot of stair stepping caused by quantization, which goes away in 16 bits. The only downside is that it's about a factor of 2 slower. http://www.tiac.net/users/rlk/print.tar.gz, as usual. The current architecture isn't (IMHO) ideal, for a number of reasons. Right now I'm trying to simply get good quality output with the current system. Later on that can be revisited. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Print plugin update
I've put a new version of the print plugin on my web site -- this version includes two new features: a saturation control, and a "linear" scale mode. The linear mode is a hack to try to improve output to the Stylus Photo EX; the saturation control applies to everything. It's probably worth experimenting with. It's an attempt to get better tonality. Getting the tonal range correct is *hard*. It's on my web site, as usual, at http://www.tiac.net/users/rlk/print.tar.gz. It's still not reachable from my home page there (I'm rather embarrassed at how cheesy that page is, and I need to redo it from scratch one of these days). For the Epson Stylus Photo folks, the settings I'm using now are: brightness 106 gamma 0.59 contrast/red/green/blue: 100 saturation: 1.5-2.5 I suspect a slightly larger value for gamma (0.7) might work better, with brightness around 110-120 and saturation in the 2-3 range. However, I'm getting tired of running through ink cartridges, and my wife's getting tired of me "obsessing" in the basement. I'm also being a rather disloyal Red Sox fan :-) Varying the RGB balance even slightly tends to throw things off, but it's possible that a slight decrease in cyan (increase in red) might help a bit. With a third party ink cartridge I used once, though, it was necessary to reduce the green a bit. The Stylus Photo EX is the best supported printer in the plugin right now (no surprise, since it's what I have). It supports full 6-color mode (CMYKcm -- light cyan and light magenta), and it computes everything in 16 bits rather than 8 (this avoids a lot of quantization problems in the light tones). There are still plenty of things left to do here: 1) Support the rest of the printers (other Epson printers, PCL, and PostScript) in 16-bit mode (this shouldn't be hard; the infrastructure is already in place). 2) The Epson driver uses MicroWeave mode in high resolution (720 dpi). This isn't really optimal; it's very slow and it introduces a lot of micro-banding. There are supposedly other ways of doing it. I've been trying to read the GhostScript code to figure out how to do it, but I haven't made much progress. The non-MicroWeave method also allows 1440x720 printing (to the extent that the printer really does it, which is questionable). 3) Better separation of the rendering from the I/O. Currently the individual print drivers work by asking the rendering code to generate a line of output for each line of input, and send that line to the printer. This limits the available dithering algorithms, and makes it hard to implement (2). I'm thinking of a dataflow architecture whereby each line of input is passed to the rendering engine, which in turn feeds lines of output to the printing engine. 4) Do something, SOMETHING, to improve the tonal range! I can get good tonality in some parts of the scale, at the price of having problems elsewhere. For example, some settings give me good highlights and dark midtones, but poor light midtones and dark areas. This stuff is really dependent upon the particular characteristics of the inks and paper. 5) Better dithering algorithms, anyone? -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
