Re: swap files
Date: Mon, 11 Oct 1999 23:04:44 -0700 From: Jay Cox [EMAIL PROTECTED] Marc Lehmann wrote: A normal user has nothing to do with the swap file, except that he will find that his disk is full and many hours later he might even find the reason It will be much more difficult for the user to find the cause if we unlink the file as soon as we create it. The normal programs used to find wasted space like "du" and "find" will not be able to locate the unlinked gimp swap file. This would be a bad thing, particularly on multiuser systems. Or (again, particularly on a multiuser system) the system administrator. Because it works. Doing it in the signal handler doesn't. If the gimp doesn't crash there is no problem. If it does crash the signal handler often isn't called at all. I can't remember the last time gimp crashed on me without the signal handler being called. I have had it hit infinite loops though... The most common infinite loop I've seen, in fact, is that when I run the Gimp in the background (I often run it as (gimp) so it doesn't become a background task I might accidentally kill) and it hits the signal handler, it goes into an infinite loop asking me to tell it what to do (continue, dump core, debug, or whatever). It shouldn't try more than a couple of times, and if it can't get any input from the user, die appropriately. In some cases, you do not have the choice. On several machines that I use at work, I have to put the swap file on NFS because all writable partitions are mounted over NFS (except for /tmp but it is too small). unlink also works over nfs. I think someone else posted in this thread a way in which unlink could actually get rid of the file before the file is closed if the file resides on an NFS volume. What usually happens is that on the server there's something spawned by cron that periodically goes around and looks for files named .NFS* which it nukes if they're too old (usually measured in days). It's possible that other NFS servers do things differently. Clients that do anything like this are completely broken. In any event, a kernel crash on the client will result in these files not being removed. The handling of removed-but-still-open files is not one of NFS's strong points. -- 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
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
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.
Print 3.0.3
I've release print 3.0.3. This will be the last release of the year unless some dramatic new bug pops up. It's at http://www.tiac.net/users/rlk/print-3.0.3.tar.gz. It is now on my web site: http://www.tiac.net/users/rlk. It has various improvements; color fidelity should be better, output is less grainy due to bidirectional scanning (it alternates scan direction), and there are a few bug fixes in the soft weave code. The soft weave itself should look better, and there are a few additional options to improve the output quality with soft weave in use (I recommend "1440x720 highest quality" for best results). Big thanks to Thomas Dorris for lots of feedback over the last release cycle. He really beat up on me over the issue of smoothness. The improvement isn't as dramatic as I'd like, but the bidirectional scanning in concert with a few other things does improve matters a good bit. -- 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: Print 3.0.3.1
Experimental release 3.0.3.1 is now on my web site. My printer currently has a partially clogged magenta head that I have not yet been able to clear, so colors don't print true (this is why the "experimental"). Nonetheless, I have been able to make some improvements: 1) Dark midtones should print smoother. 2) Performance improvements. 3) Minor bug fix in PostScript printing, from Salvador Pinto Abreu. 4) Support for softweave for more Epson printers (VERY EXPERIMENTAL -- I cannot test this to any significant degree, although I do have unit tests for the weave code!). Also, some code restructuring to generalize the softweaving, at least within the Epson code. I've received requests for support for the 440/640/740 printers. They don't look too hard (they appear on first reading to be fairly generic printers), but I don't have this equipment available... -- 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: Print 3.0.5
Well, I had to do a 3.0.5, due to a bug that Dave Hill spotted last night. This bug causes a null pointer dereference on any attempt to print in color to a printer that only supports CMY (not CMYK) printing, such as the Epson Stylus Color 1500 (or the HP Deskjet 600 that he uses). This bug has been in the code for a while. Dave has also gotten the plugin to work with Gimp 1.0; when I get the patch I'll put it in. This bug is critical enough for people with the right printer that I want to do a release now. Depending upon the complexity of the patch I'll decide whether to do 3.0.6 for it. Olof, this one's also good for the CVS tree when you get a chance. -- 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: opinion of end-users
Date: Mon, 17 Jan 2000 18:56:42 +0100 (CET) From: David Monniaux [EMAIL PROTECTED] PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). What exactly are the problems? There are some fixes for HP printers in Print 3.0.5 (on my web site), but I'm curious as to the exact problems they've observed. -- 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: opinion of end-users
Date: Mon, 17 Jan 2000 19:04:20 +0100 (MET) From: Avi Bercovich [EMAIL PROTECTED] PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). adjusting the gamma of the image works really well for me. Maybe the print dialog should offer some 'standard' gamma settings. The print plugin does have standard gamma and density settings for different printers. The adjustments in the print dialog box are relative to these (e. g. a gamma setting of 100 in the dialog box is multiplied by the default gamma recorded for that printer). Things changed quite a bit in 1.1.15; there are a lot more settings to play with 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
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: Speaking of additional plug-ins
From: Dean Johnson [EMAIL PROTECTED] Date: Tue, 25 Jan 2000 16:00:23 -0600 (CST) Cc: [EMAIL PROTECTED] (Garry R. Osgood), [EMAIL PROTECTED] (Gimp Developer's Newslist) Marc Lehmann spontaneously blurts out: Failing that, I will set up a gimp server on a local machine (in germany), but I can't promose that (I iwll need to find a free disk, but maybe in one or two weeks I can spare 2GB for it). This has SourceForge written all over it! Its easy an convenient to start projects and manage stuff. I heartily endorse it! Indeed. I've been using SourceForge for about a week for the Print plugin (the gimp-print project), and it's really good. It takes some time to learn, though. -- 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: hsv to rgb
Date: Thu, 27 Jan 2000 04:14:49 -0800 From: "Martin Weber" [EMAIL PROTECTED] I removed the rgb to hsv (and hsv to rgb) routines from several plugins because this routines are now in libgimp. But there are still some plugins like compose, decompose and flame where I din't found the time to do so. Can someone other do this? Just a comment about the print plugin (I don't know if you've actually done it) -- I suppose it's no disaster to do that to 3.0, but the intent is that the core of the print plugin live standalone without the Gimp, e. g. in Ghostscript, or as a CUPS filter, or whatnot. -- 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: Print plug-in
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 27 Jan 2000 14:17:48 +0100 Just a comment about the print plugin (I don't know if you've actually done it) -- I suppose it's no disaster to do that to 3.0, but the intent is that the core of the print plugin live standalone without the Gimp, e. g. in Ghostscript, or as a CUPS filter, or whatnot. We might also choose to use the upcoming Gnome Print System if it turns out to fit our needs and appears to be portable to non-Linux systems. As long as it doesn't require actually running Gnome (works with bare X, KDE, etc.) and its footprint is reasonably light, that sounds like a reasonable thing to do. BTW: Could you please provide a patch that upgrades the Print plug-in in CVS to the most recent 3.0.x version? Sure, in a separate message.
Re: Print plug-in
Date: Fri, 28 Jan 2000 18:03:32 -0500 From: Federico Mena Quintero [EMAIL PROTECTED] CC: [EMAIL PROTECTED] If a GNOME program does not run under "bare" X or KDE, then it is broken and should be fixed. Do you have any examples of such programs? No; I just wanted to make certain that the GNOME print system wasn't tied to GNOME. (As for footprint, well, the GIMP is not terribly lightweight either) :-) That's true, too :-) The GIMP hammers my system (256 MB DRAM) far harder than GNOME. -- 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: Print plug-in
From: "Michael J. Hammel" [EMAIL PROTECTED] Date: Tue, 1 Feb 2000 09:44:47 -0700 (MST) Thus spoke Robert L Krawitz From: Sven Neumann [EMAIL PROTECTED] IMHO having two different UIs to perform the same task is a stupid idea. Actually, it's an eminently sensible idea. For KDE, having an image editing program that follows the KDE UI guidelines and all the other good stuff would be completely logical, especially since they wouldn't have to maintain the core, just the UI. But they wouldn't have to maintain anything if they just left the UI alone. I'm with Sven on this one. Two UI's accomplishes little. After all, the whole point of modern desktops is to personalize them, not make them all look the same. Exactly. And that's why I think it's reasonable to have other UI's for the Gimp.. The basic idea here is consistency. Look at it from the standpoint of someone just coming over from Windows: why should the Gimp work differently from all of their other KDE apps, which work consistently? Because it can. A little wave in the pond adds depth to a smooth surface. Why, FROM THE STANDPOINT OF USERS WHO WANT ALL THEIR APPS TO WORK THE SAME, should the Gimp work different from their other apps? "Linux doesn't dictate how I work, I dictate how Linux works." Interesting sig, considering you're argument about uniformity in user interfaces. Enforced uniformity in user interfaces? Hardly. However, if that's what the KDE folks want to do, that's between them and their users. It isn't stopping anyone from using any other interface. -- 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: Plugins at Sourceforge
Date: Sat, 5 Feb 2000 12:33:38 -0800 From: "Michael J. Hammel" [EMAIL PROTECTED] I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Furthermore, look at it from the standpoint of someone trying to package a Linux distribution (especially vis a vis esoteric file formats and other things that depend upon external software). If our jpeg plugin is part of the core (as an example, I don't want to debate jpeg per se), then installing the gimp requires installing jpeg. If we start forcing a unitary build, then eventually we have everything depending upon everything else, and we get into the Windows mess all over again. It *must* be possible to build and install plugins separate from the Gimp tree. Now, that doesn't mean that anything should change *right now*. It's entirely too close to the release, as many people have pointed out, to change something fundamental even if it means an improvement. It seems to me that right now everyone except people working on advanced development should focus on the release. (And yes, however good Print 3.1 becomes, and even if 3.2 is ready before Gimp 1.2 is, Gimp 1.2 will contain Print 3.0. At some point down the road we might want to put Print 3.2 into a Gimp 1.2 refresh or point release, but that's another matter.) -- 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
Patch for print 3.0.6
I'm having to release a Print 3.0.6 due to a fairly serious bug found
by Panos Katsaloulis. The specific bug is that monochrome printing in
grayscale does not work properly. The patch is enclosed below.
cvs diff: Diffing .
Index: README
===
RCS file: /src/repository/rlk/print/README,v
retrieving revision 1.6.2.2
retrieving revision 1.6.2.3
diff -u -r1.6.2.2 -r1.6.2.3
--- README 2000/01/13 23:41:34 1.6.2.2
+++ README 2000/02/11 23:44:39 1.6.2.3
@@ -1,4 +1,4 @@
-Print plugin for the Gimp. Version 3.0.5 by Robert Krawitz
+Print plugin for the Gimp. Version 3.0.6 by Robert Krawitz
[EMAIL PROTECTED] based on version 2.0 by Michael Sweet
[EMAIL PROTECTED].
Index: print-escp2.c
===
RCS file: /src/repository/rlk/print/print-escp2.c,v
retrieving revision 1.39.2.1
retrieving revision 1.39.2.2
diff -u -r1.39.2.1 -r1.39.2.2
--- print-escp2.c 2000/01/13 03:32:34 1.39.2.1
+++ print-escp2.c 2000/02/11 23:44:39 1.39.2.2
@@ -1,5 +1,5 @@
/*
- * "$Id: print-escp2.c,v 1.39.2.1 2000/01/13 03:32:34 rlk Exp $"
+ * "$Id: print-escp2.c,v 1.39.2.2 2000/02/11 23:44:39 rlk Exp $"
*
* Print plug-in EPSON ESC/P2 driver for the GIMP.
*
@@ -31,6 +31,15 @@
* Revision History:
*
* $Log: print-escp2.c,v $
+ * Revision 1.39.2.2 2000/02/11 23:44:39 rlk
+ * 3.0.6
+ *
+ * Revision 1.13 2000/01/26 16:00:47 neo
+ * updated print plug-in
+ *
+ *
+ * --Sven
+ *
* Revision 1.39.2.1 2000/01/13 03:32:34 rlk
* silliness
*
@@ -1040,7 +1049,11 @@
if (output_type == OUTPUT_GRAY)
{
dither_black(out, x, image_height, out_width, black);
-escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
+ if (use_softweave)
+ escp2_write_weave(prn, length, ydpi, model, out_width, left, xdpi,
+ cyan, magenta, yellow, black, lcyan, lmagenta);
+ else
+ escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
}
else if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
{
@@ -1128,7 +1141,11 @@
if (output_type == OUTPUT_GRAY)
{
dither_black(out, y, image_width, out_width, black);
-escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
+ if (use_softweave)
+ escp2_write_weave(prn, length, ydpi, model, out_width, left, xdpi,
+ cyan, magenta, yellow, black, lcyan, lmagenta);
+ else
+ escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
}
else if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
{
@@ -1564,6 +1581,7 @@
/* quality) */
static int vmod; /* Number of banks of passes */
static int oversample; /* Excess precision per row */
+static int is_monochrome = 0;
/*
* Mapping between color and linear index. The colors are
@@ -1867,7 +1885,7 @@
{
for (j = 0; j 6; j++)
{
- if (lineoffs[k].v[j] == 0)
+ if (lineoffs[k].v[j] == 0 || (j 0 is_monochrome))
continue;
if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
fprintf(prn, "\033(r\002%c%c%c", 0, densities[j], colors[j]);
@@ -2145,6 +2163,10 @@
cols[3] = y;
cols[4] = M;
cols[5] = C;
+ if (!c)
+is_monochrome = 1;
+ else
+is_monochrome = 0;
initialize_row(lineno, width);
@@ -2201,5 +2223,5 @@
}
/*
- * End of "$Id: print-escp2.c,v 1.39.2.1 2000/01/13 03:32:34 rlk Exp $".
+ * End of "$Id: print-escp2.c,v 1.39.2.2 2000/02/11 23:44:39 rlk Exp $".
*/
Index: print-pcl.c
===
RCS file: /src/repository/rlk/print/print-pcl.c,v
retrieving revision 1.14
retrieving revision 1.14.2.1
diff -u -r1.14 -r1.14.2.1
--- print-pcl.c 2000/01/08 23:30:56 1.14
+++ print-pcl.c 2000/01/15 14:33:02 1.14.2.1
@@ -1,5 +1,5 @@
/*
- * "$Id: print-pcl.c,v 1.14 2000/01/08 23:30:56 rlk Exp $"
+ * "$Id: print-pcl.c,v 1.14.2.1 2000/01/15 14:33:02 rlk Exp $"
*
* Print plug-in HP PCL driver for the GIMP.
*
@@ -32,6 +32,9 @@
* Revision History:
*
* $Log: print-pcl.c,v $
+ * Revision 1.14.2.1 2000/01/15 14:33:02 rlk
+ * PCL and Gimp 1.0 patches from Dave Hill
+ *
* Revision 1.14 2000/01/08 23:30:56 rlk
* Y2K copyright
*
@@ -426,6 +429,7 @@
char *resolution = v-resolution;
char *media_size = v-media_size;
char *media_type = v-media_type;
+ char *media_source = v-media_source;
int output_type = v-output_type;
int orientation = v-orientation;
floatscaling = v-scaling;
@@ -687,15 +691,15 @@
else if (strcmp(media_type, "Transparency") == 0)
fputs("\033l4M", prn);
- if
resend
--- Start of forwarded message --- Date: Sun, 13 Feb 2000 09:53:37 -0500 Message-Id: [EMAIL PROTECTED] X-Authentication-Warning: rlkppp: rlk set sender to [EMAIL PROTECTED] using -f From: Robert L Krawitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] In-reply-to: [EMAIL PROTECTED] ([EMAIL PROTECTED]) Subject: Re: [Gimp-print-devel] need progress bar? References: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Sun, 13 Feb 2000 17:19:23 +0900 Hmm, my home university seems to have dropped off the face of the net for the past 24 hours... I'm reading the list off the archive. The Gimp puts its own progress bar on the image you`re printing. Do we really need our own progress bar? Yeah, I know about the one that the gimp puts under the image. It's small and very unobtrusive. It's very easy to miss. Even though I know it's there, I just didn't think to check it. I don't know. I generally hold the opinion that I'm not quite a complete idiot, so, when a UI presents something to me and I miss it, then I tend to think that something in the UI is lacking. The thing that sets the print plug-in apart from most other gimp plugins is that it doesn't modify the image at all. If I'm waiting for a plugin that will change my stick figure drawings into a photorealistic image, then I can clearly see that the transformation is not finished and there is no need for a pop-up window with a progress bar. The little one under the image is perfect. But for printing, especially to a file, I think something a little more obvious is in order. shrug I'm not really going to push for this, if there's a general consensus against it, but, if we don't do this, is there some way of telling the gimp that we're still working in such a way that the gimp would throw up an "Are you sure?" box if the user attempts to quit before printing is finished? It just seems to me that "fire up gimp; load image; print image; quit gimp" might be a fairly common thing for Joe user to do, so, this could become a FAQ. So one thing that springs to mind here is if the Gimp itself were to warn if you attempt to exit while a plug-in is in progress of execution. Gimp folks, would that be feasible? That would seem useful for other long-running things (and some of the filters take a long time to run). - -- 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 --- End of forwarded message ---
Re: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)
From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 26 Feb 2000 02:37:02 +0100 just do make my position clear: I was not critizing your decision. My feeling was just that we could have built a similar framework on available resources with substantial interest and a little effort. As long as it helps Gimp development I'm all for it. (That's why I pointed Dirk to your project). Possibly, but is it worth the effort? VA Linux Systems is backing SourceForge with some fairly serious hardware (see https://sourceforge.net/docs/site/hardware.php) and staffing resources; they have 5 people managing the site. They have a dozen machines that I'd guesstimate are about $50K-$100K of hardware (RAID boxes and fast tape drives aren't cheap), and they've put a lot of programming effort behind it. They're basically running a small scale data center operation. I have yet to see any sign of downtime on the entire system. I'd argue if anything that it would be worthwhile for the Gimp to move *its* operation to SourceForge, just to save on the system administration and backup headaches. It's always possible to mirror the CVS repository and other important stuff elsewhere (I'm taking a snapshot of gimp-print's repository every night as insurance myself). -- 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: gimp_image_get_resolution/gimp_image_get_unit/release timetable
Date: Sat, 19 Feb 2000 22:43:41 +0100 From: Michael Natterer [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Robert L Krawitz wrote: I'm experimenting with gimp_image_get_resolution(). It appears (in 1.1.17, at any rate) that whatever I set the units to I always get a resolution back that's expressed in dots per inch. Is this behavior correct? Absolutely correct. Thanks. If so, did it work this way in 1.0 also? This is so I can investigate its use with the Print plugin. 1.0 has no resolution info at all. BTW, do you really want to support 1.0? It may be quite hard to make use of the help system and the libgimp ui stuff (i.e. sizeentries which may be useful for the print plugin) if you want to keep the print plugin running with 1.0... Well, thus far we've had very little trouble supporting 1.0. Even the configure script works properly. 1.0 is still the stable release of the Gimp. -- 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: gimp_image_get_resolution/gimp_image_get_unit/release timetable
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 20 Feb 2000 03:18:53 +0100 Don't underestimate the importance of the resolution info for the print plugin. The following task may not be very professional, but it is certainly something the average gimp user does frequently: Scan in an image, retouch it, collage it, whatever, then print it. When doing this with gimp-1.1.x all parts of the data stream support the resolution information. The scanner plug-in uses it, the application gives you the necessary infos in realsize units, you may even save and load your image in between in a variety of formats. But when you choose to print the image, that information carried along all the way is useless, since it is simply ignored. We have added the image resolution in 1.1 only to make Gimp better suited for printed graphics. CYMK support is still missing, but I thought we'd at least manage to integrate the resolution info completely. Pending a general way to scale images separately on X and Y axes, what would be your (collective) suggestions about how to handle an image with different X and Y resolutions? -- 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: gimp_image_get_resolution/gimp_image_get_unit/release timetable
Date: Sun, 20 Feb 2000 22:36:11 + (GMT) From: Austin Donnelly [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Saturday, 19 Feb 2000, Robert L Krawitz wrote: Pending a general way to scale images separately on X and Y axes, what would be your (collective) suggestions about how to handle an image with different X and Y resolutions? This happens so rarely that I would (for the moment) ignore it. Assume the Y resolution is the same as the X resolution. OK, the next version (3.0.7) will have a button called "Set Image Scale" next to the other two scaling buttons (percent and PPI). It will immediately set the image to PPI mode and set the resolution to the Y resolution of the image. This may not be ideal, but it's quick and easy to test. Anything else is likely to be fairly high risk. This is already checked into the development mainline. It's strictly a GUI hack, and has no effect on the rest of the system. I'm going to hold 3.0.7 until Michael J. Hammel and I can get his printing issue resolved, and someone else can test a softweave change I made for the Stylus Color 800 (which is really a fairly general issue). Those are important but almost surely very local bugs. -- 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
print 3.0.7
I'm just waiting right now for Michael J. Hammel to sign off on a couple of bug fixes (which isn't absolutely a sure thing), then I'll release 3.0.7. To whom should I send the patch when it's ready? I'm hoping to do 3.1.0 this evening; I'll also send that announcement to this list. I'll be very interested in comments on that 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] 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
ANNOUNCE: gimp-print 3.1.0
This is the first version on the 3.1 (development) series. It is available at http://gimp-print.sourceforge.net. In addition to the plug-in for the Gimp, the same source base is used as the nucleus of a GhostScript driver to support Epson Stylus printers. Gimp developers, should I send these announcements to gimp-developer, or should individuals simply subscribe to gimp-print-announce? Also, any other suggestions about where I should send this announcement? The release notes follow: This is the Print plugin for the Gimp, version 3.1.0. This is a development release, the first on the 3.1 branch. If this software causes your print head to zoom off the end of your printer, spilling ink all over your 1000 year old Persian rug, don't blame us. Remember, you installed the software. This software also comes with a GhostScript driver for Epson Stylus printers. The support for Epson Stylus printers in the GhostScript driver is identical to the support for these printers in the Print plugin -- they use the identical code base. This plugin can be compiled against either Gimp 1.1 or 1.0. Print 3.1.0 contains the following user-visible improvements over Print 3.0.5, the version distributed with the Gimp 1.1.17: 1) Preliminary support for Canon BubbleJet printers (specifically the BJC6000). 2) Preliminary support for the Epson Stylus Color 440/640/740/900 and Stylus Photo 750/1200 printers. These printers should in theory work in all modes, although that has not been comprehensively tested. 1440 dpi mode on the 900 in particular may not work. There is also pre-preliminary support for the Stylus Photo 870 and 1270 based on the published specifications. This driver is completely untuned for these printers at present. 3) Ability to position the image on the page to the point (1/72", or about .35 mm), along with a more accurate depiction of the positioning on the page. 4) One-click ability to scale to the image resolution (Gimp 1.1 only). 5) Much better handling of the saved state (printrc file), including saving of parameters related to file output. 6) Utilities (in various states of completion) to reconstitute an image from a print file. 7) Bug fixes for density in indexed and gray modes, and for excess pseudo-black printing in general. There are additional improvements over Print 2.0.2 (the version distributed with Gimp 1.1.11 and earlier) too numerous to list here. -- 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
3.0.8
I did a 3.0.7 this evening, and then decided to port a few of the juicier GUI features over from the mainline (specifically the separation of printrc save from cancel and print, the positioning entry boxes, and the correct sizing computations), so I quickly did a 3.0.8. I sent Sven the patches from 3.0.6, and in addition put it up on Sourceforge. 3.0.6-3.0.7 contains some important bug fixes, in addition.
Print 3.0.9
I put 3.0.9 up on gimp-print.sourceforge.net, and Sven checked the equivalent into the Gimp proper. This will be the last standalone release on the 3.0 branch. The standalone code is getting too far out of sync with the Gimp CVS repository to make this very easy, and the real action is happening in 3.1, anyway. There may still be updates to 3.0, either bug fixes or new features (probably just new UI stuff; 3.1 has changed fairly extensively internally, and bringing the new printer stuff back would be too much effort and too risky). -- 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 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);
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: print plug-in problems
From: "Michael J. Hammel" [EMAIL PROTECTED] Date: Sun, 20 Feb 2000 11:56:17 -0700 (MST) I loaded the 1.1.17 release the other day and today I did a print job. All I get is a solid black output. I'm using an Epson Stylus Color 500 and the printer worked fine in 1.1.15 (I didn't try 1.1.16). Rob: if you need more info, let me know. I've heard of similar things with the 800 in microweave mode, so there does seem to be a problem. It would be very interesting to know if it worked in 1.1.16, since that had an intermediate version of the code. What you could do to help me is to print out something small to a file in both 1.1.15 and 1.1.17 and send me a URL (or, in a pinch, a mail message) with the contents of both output files. Then it should be easy to track down. -- 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 plug-in problems
From: "Michael J. Hammel" [EMAIL PROTECTED] Date: Sun, 20 Feb 2000 11:56:17 -0700 (MST) I loaded the 1.1.17 release the other day and today I did a print job. All I get is a solid black output. I'm using an Epson Stylus Color 500 and the printer worked fine in 1.1.15 (I didn't try 1.1.16). Rob: if you need more info, let me know. BTW, what print mode were you using (360, 720 microweave, 720 softweave...)? I assume 720 microweave since that's what the other person who reported all-black output was using. If you want to try 3.1, you can get the CVS tree from sourceforge.net. There are differences, and it's possible that you'll get different results (that would be helpful in terms of back porting whatever makes the difference). Don't feel obligated to, though -- generating print files from 1.1.15 and 1.1.17 would be helpful. -- 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 plug-in problems
From: "Michael J. Hammel" [EMAIL PROTECTED] Date: Sun, 20 Feb 2000 11:56:17 -0700 (MST) I loaded the 1.1.17 release the other day and today I did a print job. All I get is a solid black output. I'm using an Epson Stylus Color 500 and the printer worked fine in 1.1.15 (I didn't try 1.1.16). Rob: if you need more info, let me know. Actually, the fact that it worked in 1.1.15 may be enough information...that already had one of my versions of the plugin. I'll let you know if I need more.
Re: running ldconfig
Date: Tue, 7 Mar 2000 16:45:59 +0100 From: Marc Lehmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Sun, Mar 05, 2000 at 02:16:04PM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: When the Gimp is installed, the make install should run ldconfig (on Elf-based systems, at any rate) so that ld.so picks up the new shared libraries. I don't think so: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. 2. only root can run ldconfig (without errors, that is) And make install normally installs software into areas that can only be installed into by root. 3. not all systems have ldconfig or the same concept of shared libraries as linux (elf or not...) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". -- 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: gimptool
Date: Fri, 3 Mar 2000 11:54:48 +0100
From: Marc Lehmann [EMAIL PROTECTED]
($plugins = `$GIMPTOOL -n --install-admin-bin /bin/sh`) =~
s{^.*\s(.*?)(?:/+bin/sh)\r?\n?$}{$1}}
(I only need it in the testsuite, which is not run when we're inside the
gimp source tree)
Which will work for essentially any general purpose Linux system,
since every distribution I know of comes with perl, but...
What does the output look like in 1.0?
--
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: gimptool
Date: Fri, 3 Mar 2000 17:44:55 -0800 From: Manish Singh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Fri, Mar 03, 2000 at 08:48:29PM -0500, Robert L Krawitz wrote: Date: Fri, 3 Mar 2000 11:49:14 -0800 From: Manish Singh [EMAIL PROTECTED] gimptool --prefix and gimptool --exec-prefix will give you these dirs. All they give me is /usr/local; they don't tell me where the Gimp is really installed (I have to know a lot about the Gimp's structure to use this output). (and as it happens, in 1.1 the Gimp library directory is /usr/local/lib/gimp/1.1, and so forth. Not very friendly to a version-agnostic plugin.) What do you need exactly? We could extend gimptool to provide values for the whole gamut of autoconf installation path variables... The print plugin will at some point have auxiliary files. I'm thinking of moving the printer descriptions out of the plugin (where they're compiled into presently) and into some kind of text file describing their capabilities, and I want somewhere to put those files. -- 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: gimptool
Date: Sat, 4 Mar 2000 03:56:18 -0800
From: Manish Singh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
On Fri, Mar 03, 2000 at 09:01:01PM -0500, Robert L Krawitz wrote:
(and as it happens, in 1.1 the Gimp library directory is
/usr/local/lib/gimp/1.1, and so forth. Not very friendly to a
version-agnostic plugin.)
Well, 1.0 and 1.1 plugins are incompatible at the binary and protocol
level.
Right, but they can be made compatible at the source level with a very
small amount of #ifdef'age. It's important for build scripts.
What do you need exactly? We could extend gimptool to provide values
for the whole gamut of autoconf installation path variables...
The print plugin will at some point have auxiliary files. I'm
thinking of moving the printer descriptions out of the plugin (where
they're compiled into presently) and into some kind of text file
describing their capabilities, and I want somewhere to put those
files.
Like, say, $(datadir) (typically ${prefix}/share) ?
That's the right idea, although /usr/local/share isn't specific enough
-- presumably it's more like /usr/local/share/gimp/plugindata or some
such.
--
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: gimptool
Date: Sat, 4 Mar 2000 14:09:49 -0800
From: Manish Singh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
On Sat, Mar 04, 2000 at 09:18:57AM -0500, Robert L Krawitz wrote:
Date: Sat, 4 Mar 2000 03:56:18 -0800
From: Manish Singh [EMAIL PROTECTED]
Right, but they can be made compatible at the source level with a very
small amount of #ifdef'age. It's important for build scripts.
gimptool --install-admin-bin foo-plugin
That's how I install the plugin, yes.
That's the right idea, although /usr/local/share isn't specific enough
-- presumably it's more like /usr/local/share/gimp/plugindata or some
such.
So gimptool could provide a $(gimpdatadir) (like ${prefix}/share/gimp) and
you'd go from there?
That would suffice, yes.
--
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
Print 3.1.1
Print 3.1.1 is out. Please see http://gimp-print.sourceforge.net or ftp://download.sourceforge.net/pub/sourceforge/gimp-print/print-3.1.1.tar.gz. This is a development release. The usual caveats apply. We still don't guarantee that the print head won't be launched from the printer with *ahem* unpredictable results. Print 3.1.1 contains the following improvements over Print 3.1.0: 1) Faster dithering speed. 2) Improved support for many Epson Stylus printers. 3) Some UI improvements. 4) Numerous bug fixes. -- 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
running ldconfig
When the Gimp is installed, the make install should run ldconfig (on Elf-based systems, at any rate) so that ld.so picks up the new shared libraries. -- 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: running ldconfig
Date: Sun, 12 Mar 2000 21:44:49 +0100 From: Marc Lehmann [EMAIL PROTECTED] On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. On _some_ systems, like linux. Many systems do not even have the notion of ldconfig. That's true, but not particularly germane. Where it does exist, it's a standard part of installation: ldconfig should normally be run by the super-user as it may require write permission on some root owned directo- ries and files. It is normally run automatically at bootup, from /etc/rc, or manually whenever new DLL's are installed. I interpret "manually" as "whatever does the installation", i. e. make install. It is an absolute must, however, that even normal users can install the gimp (remember the long thread on this subject?) Agreed, but that doesn't mean that make install shouldn't attempt to run ldconfig. If users do their own installation and have to set LD_LIBRARY_PATH that's their lookout. System installations should not be subject to this. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). The hard part is figuring out where ldconfig lives -- on my Linux box it's in /sbin; it doubtless lives elsewhere on other platforms. If the makefile just contains -$(LDCONFIG) it will simply print out a warning message and continue if it doesn't have permission. -- 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: running ldconfig
Date: Mon, 13 Mar 2000 17:22:50 +0100 (MET) From: [EMAIL PROTECTED] (Raphael Quinet) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) It's happened with at least 1.1.17 and 1.1.18. The fact that you're using Solaris explains why you don't have a problem. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. All that ldconfig -n does is create the links. It doesn't update the cache. ld.so (at least on Linux) needs the cache: ld.so(8) ld.so(8) NAME ld.so/ld-linux.so - dynamic linker/loader DESCRIPTION ld.so loads the shared libraries needed by a program, pre pares the program to run, and then runs it. Unless explicitly specified via the -static option to ld during compilation, all Linux programs are incomplete and require further linking at run time. The necessary shared libraries needed by the program are searched for in the following order o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the executable is a setuid/setgid binary, in which case it is ignored. o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. o In the default path /usr/lib, and then /lib. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. My ld.so.conf is correct (if it weren't, running ldconfig wouldn't solve the problem). I agree that make install should not attempt to edit ld.so.conf. Botching that will trash the system. -- 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: running ldconfig
Date: Tue, 14 Mar 2000 18:10:32 +0100 (MET) From: [EMAIL PROTECTED] (Raphael Quinet) Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. If somebody reads the install output carefully enough, and understands what that means, maybe (although I went back to the emacs shell that I did the install in and didn't see any such message). But it's buried in a stack of output, if it's there at all. In practice, I start it, go off to do something else, and simply check that it completed successfully. I suspect that this is the common state of affairs. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. Actually, I think libtool should have some kind of "libtool --postinstall"
Re: HP DeskJet 9xx support?
Date: Sat, 18 Mar 2000 13:05:44 -0500 (EST) From: Eddie Maddox [EMAIL PROTECTED] I'm new to GIMP. I also just bought an HP DeskJet 952C printer. All the 9xx models support 2400x1200 resolution and the use of both premium and real photographic paper. The GIMP 1.0.4 print config does not have the HP 900 series listed. So, I found that the 600 series is, for now, the next best to select. But it only has 600x600. Nor does it list photographic paper, only plain and premium. Does HP publish the PCL (Printer Control Language) docs still? Or a Technical Reference Manual? How may I obtain such? (I can't write code, but I write little shell scripts some times.) So, when can we expect the next stable GIMP release with HP DeskJet 9xx support? Eddie, I've forwarded this to [EMAIL PROTECTED], where we're working on the next generation Gimp print plugin. -- 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: Question about XCF format
From: Tor Lillqvist [EMAIL PROTECTED] Date: Sun, 30 Apr 2000 23:02:43 +0300 (FLE Daylight Time) I got now several emails from users with the wish to add XCF reading support in my viewer. I don't know if that is a good idea. XCF is really the GIMP's own private format for saving images between editing sessions, it is not intended for interoperability with other applications. Or what do you folks on gimp-developer think? The last thing the world needs is more undocumented, proprietary file formats. I realize that "proprietary" has a subtly different meaning from the closed source world, but it's the same idea. It does nobody any good if the file can't be read without firing up the Gimp.
Re: Question about XCF format
Date: Sun, 30 Apr 2000 23:21:35 +0200 From: Marc Lehmann [EMAIL PROTECTED] And, in the future, when the format *might* (or might not...) be extended so it is easily mmapable (large images) or aquires other similar features, the idea of "reading/writing xcf images form outside the gimp" might become totally unfeasible. Why? If the format's specified well enough, why shouldn't it be possible for it to be accessed? -- 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: EPIPE
Date: Wed, 10 May 2000 19:15:57 -0500 (CDT) From: Tim Mooney [EMAIL PROTECTED] cc: Raphael Quinet [EMAIL PROTECTED], [EMAIL PROTECTED] In regard to: Re: EPIPE, Michael Natterer said (at 12:40am on May 11, 2000): This is what currently happens (ok, it happens in the handler, but WNOHANG *should* be absolutely safe). However, a signal handler can do whatever it likes with the app's structures as long as it uses atomic data access (which can be a pointer, as pointers have the same size as integers, which are atomic. This is true at least on all processors which have a GNU libc port and finding a processor where pointers are not atomic looks very unlikely to me). Finding a processor/OS combo where sizeof(pointer) != sizeof(int) is pretty easy, however. How does this change your thinking? For example, UltraSPARC in 64-bit mode under Solaris. -- 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
Gimp-Print 3.1.5 release
This is a development release. Usual caveat about aerodynamic print heads and fine Oriental rugs apply. This is a fairly substantial release. The .tgz file is much bigger than before because of new dithering matrices. Print quality should be greatly improved. 1) Greatly improved print quality. In particular, ordered dithering and adaptive dithering methods are now much better than ever before. We recommend ordered dithering for four-color printers and either adaptive hybrid or adaptive random dithering for six-color printers. 2) If a print job is canceled from within the Gimp, the partial file will not be sent to the printer. 3) Support for additional Canon and Hewlett-Packard printers. 4) Epson Stylus printers can now print much closer to the edge of the page. They can print to the extreme top edge and much closer to the bottom than before, although there is some loss in quality close to the edge. 5) Greatly improved black quality. 6) The preview window now shows the borders of the printable area in addition to the borders of the page. In addition, the offsets are now from the true edge of the page rather than from the edge of the printable area. 7) 720 dpi highest quality and 1440x720 dpi highest quality are now supported on the new generation Epson printers. 8) Epson printers will now print faster on sparse pages and in pure black and white. This is of particular interest for the Ghostscript driver. -- 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
Gimp-print 3.1.7 Release
This is an emergency release due to a GhostScript compile failure that slipped through the cracks. However, I did slip a little goodie in there just the same. 1) Emergency GhostScript bug fix. 2) escputil program now retrieves ink level from the printer. -- 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
ANNOUNCEMENT: Gimp-Print 3.1.8 Release
This is a development release of Gimp-Print. This will probably be the last release until after the Printing Summit in two weeks. Print 3.1.8 contains the following improvements over 3.1.7: 1) The entries for printer model and paper size have been greatly improved. There are many additional paper sizes offered. 2) Print quality using adaptive, hybrid, and ordered modes is improved at 1440x720 DPI. 3) The UI now offers a choice of metric or English units for measurements. 4) The print preview is much larger, affording easier viewing of the placement of the image. An arrow is used to indicate the top of the paper, and the size of the arrow gives an indication of the actual paper size. 5) It is now possible to specify the output width or height directly. 6) Dragging the preview image with a button other than the left moves the image in units of points rather than screen pixels, affording finer placement control. 7) A new emulated 1440x2880 mode has been added for highest quality printing on Epson Stylus printers. It is of most use on the Stylus Photo 750, 1200, 870, and 1270. 8) Experimental improvements for the Canon BJC-8200. 9) The plug-in should operate correctly with the plp spooling system. 10) Support for the Epson Stylus Photo 720 and Stylus Color 480. Also correct the Stylus Color 860 and 1160 entries. 11) Support for the HP 540C printer. 12) Correct treatment of saturation adjustment, and allow saturation of 0. This allows printing a color image in black and white using color inks for maximum smoothness. 13) Allow choice of four and six color printing on six color printers. This is useful for economy (normal printing uses much more light cyan and magenta than dark), and may improve saturation for graphics. 14) Bug fixes for Ghostscript driver. Also, Ghostscript driver now offers choice of ink type. 15) Some improvement in Epson Stylus Photo, Photo 700, and Photo EX output quality. -- 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
ANNOUNCE: gimp-print 3.1.9
All users of the GhostScript stp driver should upgrade, due to a critical bug that causes an infinite loop to occur with some combinations of printer choice, compiler used, and possibly other factors. Other users may want to upgrade due to the print quality improvements. One user has reported an apparent crash or corrupt output from the plugin. We have not been able to reproduce this. I am working with that user to try to understand what's happening. If that turns out to be real, 3.1.10 will be released when a fix is available. Print 3.1.9 contains the following improvements over Print 3.1.8: 1) A bug in the GhostScript driver would cause the driver to go into an infinite loop on some systems with some printers, depending upon details of the compiler and so forth. All users of the GhostScript driver should immediately update. 2) Substantial quality improvements across many printers: * Output across printers and resolution modes is much more closely matched (except probably 360 DPI). The saturation may be somewhat less than before, however. * 720 DPI is greatly improved on Epson Stylus Color 860/1160 and Stylus Photo 870/1270. The 750/1200 may not show this improvement. * Artifacts in the adaptive hybrid and adaptive random dithering modes have been eliminated. Please see the README for more information. -- 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: Gimptool in Gimp 1.0.4
Content-Type: text/plain; charset=us-ascii Date: Tue, 1 Aug 2000 11:07:44 +0100 (BST) From: Austin Donnelly [EMAIL PROTECTED] On Tuesday, 1 Aug 2000, Marc Lehmann wrote: On Mon, Jul 31, 2000 at 09:29:01PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Any suggestions? Is Red Hat broken, or is it our configure script? Obviously, if gimptool is missing the rpm source (e.g. the distro) is broken, as is the usual case. Most likely the users have not installed the gimp-devel package. They claim to have done so. Nick Lamb suggested (offline) that the users in question run rpm -q -i gimp-devel to find out what's really going on. -- 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: [gimp-devel] Gimptool in Gimp 1.0.4
Date: Tue, 1 Aug 2000 09:34:10 -0400 From: Zachary Beane [EMAIL PROTECTED] This was a legitimate screw-up in one version of Red Hat, IIRC. They did not include the gimptool script in either gimp or gimp-devel RPMs. This became an issue on IRC for several people, until we finally figured it out. What was the recommended solution? -- 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: gimptool using --prefix for install?
Date: Tue, 1 Aug 2000 23:56:55 +0100 (BST) From: Austin Donnelly [EMAIL PROTECTED] Some work needs to be done on gimptool before 1.2 can release. In particular, we need to be able to use it to automate the building of DLL modules without using a gimp build tree. As long as we're on this subject, it would be very handy for there to be a way to install (and deinstall) auxiliary files. We (gimp-print) don't have any as of yet, but that's largely because we have no handy way of installing them. In the future (not in 3.2, which is what we hope to release in a few months), we'll probably want to ship printer definitions, color profiles, possibly dither matrices, and such as separate files rather than compiled in to the binary. -- 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: gimptool using --prefix for install?
Date: Wed, 2 Aug 2000 14:43:30 +0200 From: Marc Lehmann [EMAIL PROTECTED] On Wed, Aug 02, 2000 at 07:56:35AM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: hope to release in a few months), we'll probably want to ship printer definitions, color profiles, possibly dither matrices, and such as separate files rather than compiled in to the binary. I think it's not a good idea to put knowledge about printer files (or any plug-in-specific data) into gimptool. What's wrong about just using $gimpdatadir/gimp-print? I don't think that gimptool should know anything about specific plugins. At the very least I want agreement on conventions about what goes where. -- 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
ANNOUNCE: gimp-print 4.0a1 release!
This is the first alpha release along the way to 4.0. It is not 4.0. Gimp-Print 4.0a1 contains the following improvements over Gimp-Print 3.1.9: 1) The Ghostscript driver has been extensively revised. IN PARTICULAR, THE OPTIONS HAVE CHANGED TO A DEGREE MAKING IT IMPOSSIBLE FOR ANY USES OF THE OLD DRIVER FROM WORKING WITH THE NEW ONE. Please read Ghost/README for a full explanation of the new options. 2) The Ghostscript driver now supports all printers supported by the Gimp plug-in, including PCL and Canon printers in addition to Epson Stylus inkjets. 3) Photo mode has had major improvements in its color generation in corner cases. It is slower than it used to be, unfortunately. 4) The inks have been retuned for 6-color Epson printers; they should now better match those of 4-color printers. 5) It is now possible to print to the very edge of the top, left, and right on Epson Stylus 870 and 1270 printers. 6) An experimental CUPS driver is now in place in the Cups subdirectory. It is not based on the current source base. It will be redone before 4.0 release. 7) Printing near the top and bottom of the paper is substantially improved on Epson Stylus printers. 8) Printing on PCL printers is fixed. 9) Epson Stylus printers have more flexible tuning than previously, allowing specification of smaller dot sizes in some cases, which will yield better output quality. 10) Ghostscript driver bug whereby only half the page was printed in certain resolutions is now fixed. 11) Adaptive hybrid dithering is now the default. ERRATA: 1) The PDQ and CUPS descriptor files are not updated for the latest change to the Ghostscript driver. 2) The Epson Stylus 850 apparently does not print to the very top of the page. 3) Not all printers have been fully calibrated, so color and density matching may be significantly off in some cases. Also, for some printers it may be possible to use smaller dot sizes than currently, which will produce higher quality output. 4) Photograph image type is known to work improperly with at least EGCS 1.1.2, due to problems with inlining in that compiler. -- 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: [Gimp-print-devel] libgimp COMPAT_CRUFT now disabled by default
Thanks! -- 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: api break before release
Date: Fri, 25 Aug 2000 01:08:42 +0200 From: Sven Neumann [EMAIL PROTECTED] There were no API changes at all. All of the names that are standard now have been around for a long time and the only thing we did was to reverse the logic of the COMPAT_CRUFT defines. What was #ifndef GIMP_DISABLE_COMPAT_CRUFT before, has become #ifdef GIMP_ENABLE_COMPAT_CRUFT now. That's it! Nothing else changed!! So, in effect, the recent undiscussed changes completely break the API and make it impossible to maintain a plug-in for both 1.0 and 1.2 versions. Are you sure? Why does it work for the gimp-print plug-in then? We've been using the old names. I ran Sven's conversion script to generate the new names, and put a whole stack of #define's in the one UI-related file that's shared between the 1.0 code and the 1.2 code. It does make it harder to maintain the plugin for both releases, although not all that much so. -- 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
ANNOUNCE: gimp-print 4.0a3
This is the third alpha release (and hopefully the last before beta) for gimp-print. This is a major update. There are two problems beyond those noted in the release notes: 1) Printing position is incorrect on the Epson Stylus Color 800 (the same issue we had on the 850). 2) The Ghostscript driver documentation refers to a -Dither option. That is incorrect; it is -sDither. Here are the release notes: 1) The brightness, contrast, and color level controls have changed incompatibly in both the plugin and the Ghostscript driver. The controls now adjust cyan, magenta, and yellow levels. In addition, all controls are now arbitrary values centered around 1, rather than some being centered around 1 and some being integer values centered around 100. Furthermore, the action of the color level controls is now much more what would be expected. The cyan, magenta, and yellow controls can be used to balance the printer grayscale. Plug-in users: please be sure to check the color values in the Adjust Color window before printing or reporting a problem. Use the Set Defaults button to bring them back to reasonable defaults. Ghostscript users: please see the Color Balancing Values section of Ghost/README for details. 2) The MediaSource argument in the Ghostscript driver has been renamed InputSlot, to conform to the PPD standard. Therefore, any uses of Ghostscript that use this argument must change. 3) There is a new Fast dither algorithm. This produces greatly improved speed at some cost in image quality. It gives poor results on 6-color printers when used in 6-color mode. In black and white mode, the results are generally quite acceptable. 4) Performance has been improved to some degree in all modes. This will probably be most noticeable when printing text, and when printing at a higher resolution than the source image is sampled at. 5) Density is now computed correctly in 1440x720 mode on Canon printers. 6) Positioning should now be correct on the Epson Stylus Color 850 and similar printers. 7) The inlining problems with egcs 1.1.2 are now fixed properly, so inlining is re-enabled. 8) The problem with blank splotches is now fixed. It was closely related to the other inlining problems (which weren't really inlining problems at all). 9) Ink densities and other color parameters have been tuned for additional paper types. In particular, plain paper and generic ink jet paper should now work reasonably well. 10) Monochrome mode prints with correct density on variable dot size printers (it was printing too light or entirely incorrectly). 11) The Gimp-based GUI (usable only with Gimp 1.1.22+) has been extensively reorganized. 12) Monochrome (fast black-only) mode works correctly on variable dot size printers. 13) HP printers with multiple input sources now print correctly by default (using the standard paper source rather than the manual feed). 14) Bug fixes to the Canon driver for certain printers. 15) Preliminary support for the Epson Stylus Photo 2000P, Stylus Color 880, and Stylus Color 980. The 880 and 980 should work reasonably well. The 2000P has not been tuned. 16) Performance and print quality on the Epson Stylus Color 900 is improved. 17) There have been some miscellaneous improvements (or at least changes) in color generation. 18) Images will now print to their exact specified size. In previous versions, if percentage scaling was used, the scale was effectively rounded down to the next percentage point. 19) The height/width entries are more accurate, and do not automatically set the scaling mode to PPI. 20) Preliminary support for the Epson Stylus Color 880 and 980 printers. 21) Miscellaneous bug fixes for certain Epson Stylus printers. ERRATA: 1) The PDQ and CUPS descriptor files have still not been updated. 2) Printers other than Epson Stylus printers are in an unknown state of tuning. Unless testers step forward, the these printers will not be tuned in the final release! 3) Documentation is still almost nonexistent. 4) Red Hat 6.1 users cannot configure the plug-in. The problem is that neither the gimp nor the gimp-devel rpm's in that release include gimptool, which is necessary for configuration to work. The recommended solution is to recompile the Gimp from source (either 1.0.4 or the latest 1.1/1.2 release). That will install gimptool, and you will then be able to build the plug-in. This does not affect the Ghostscript driver. This is not planned to be fixed in the 4.0 release. 5) In some cases, when the scaling has been set to PPI mode, the plugin will start at the minimum PPI allowed for the image (maximum permitted image size). It is not understood why this is happening. 6) There are some known color generation problems. In particular, greens (particularly weakly saturated greens) tend to be
ANNOUNCE: gimp-print 4.0b1
This is the first beta of gimp-print 4.0. This is a major release, and has many important changes over all previous versions. In particular, the format of the printrc file has changed incompatibly with all earlier versions of the print plug-in. The new plugin can read old printrc files but not vice versa. There are also major changes with the Ghostscript driver, a new CUPS driver, and full support for Grant Taylor's Foomatic printer configuration system. Please test this rigorously, and report all problems, major and minor, to [EMAIL PROTECTED] I expect that there will be one more beta before the final 4.0 release. However, I do not currently anticipate any further incompatible changes between now and final release. There are no guarantees, of course. Here is a summary of changes: 1) For Gimp plug-in users: the format of the printrc file has changed in a way that is incompatible with older versions of the plugin. This version of the software can read old printrc files, but older versions of the plugin cannot read the new format. The new format uses a keyword-based approach that is far superior to the old format, and will be much more amenable to future changes that may become necessary. 2) Support for the HP Deskjet 800 series has been changed incompatibly. The "pcl-800" driver (HP Deskjet 800 series) no longer exists, since the 800 series printers fall into two distinct groups, the older 850/855/870/890 printers which supported 4-level dithering (HP calls this C-RET) at 300x300 DPI, and the newer 810/812/840/842/895 printers which do not support C-RET at 300x300 DPI (these are the same as the Deskjet 600 series). If you are using the gimp plugin, re-select your 800 series printer from the combo box and re-save the settings. If you are using the Ghostscript driver, choose from one of the pcl-8xx values detailed in Ghost/README. If you have an 800 series printer that is not on the list, please try both the old C-RET driver (choose model 890) and the non C-RET driver (choose model 895) and see which one works at 300x300 dpi. Also, please let us know; the address is in the README file. 3) The HP Deskjet 1220C has been grouped with the 900 series. 4) The HP PhotoSmart P1000 and P1100 have been added, they are like the HP 900 series. 5) Online documentation for the print plugin finally exists. 6) Support for CUPS, through a choice of a native CUPS driver or Cups-o-Matic. 7) Support for the Foomatic printer configuration system, greatly simplifying configuration and use with lpd, CUPS, and PDQ. 8) The preview window in the plugin now shows a low-resolution representation of the actual image. The color adjustment window shows an thumbnail that reflects the effect that color adjustments have on the output. 9) The old GTK-based interface is now disabled by default when used with the Gimp 1.1. It can be enabled by running configure with --enable-maintainer-mode. 10) The plugin now detects the spooling system at runtime, so it need not be compiled specifically for use with Berkeley lpd, System V lp, CUPS, or LPRng. 11) Substantial quality improvement for many Epson Stylus printers in in 1440x720 DPI modes. The price is that printing takes much longer. If you need high quality with better performance, use 720x720 DPI Highest Quality. The specific printers that are affected are the Epson Stylus Color 600, 800, 850, 900, 1520, and 3000, and the Epson Stylus Photo 700 and EX. The effect in all cases will be smoother output that is particularly visible in pale tones. 12) The Fast dither algorithm has been slightly tweaked, and a Very Fast dither algorithm has been added. 13) Most menus have been converted to combo boxes. 14) The printrc code has been fixed to set reasonable defaults if an old printrc file with now-invalid parameter settings is read. 15) It is now possible to print in seascape and upside down portrait mode. 16) The support for the Stylus Photo 2000P has been fixed and should now be correct. 17) Printer names may now be up to 127 characters. 18) Additional performance improvements over earlier versions of this package. 19) A number of miscellaneous bugs have been fixed. Errata: 1) The higher resolutions of the HP Deskjet 900/1220C and the HP PhotoSmart P1000/P1100 have been disabled as they do not work. Investigation into these modes (Photo-Ret III) is continuing. -- 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
ldconfig nonsense
I've complained about this for a while (the Gimp install procedure
doesn't do an ldconfig at the end). The effect that that has is that
you can't run configure in gimp-data-extras, and the message isn't
helpful.
[2(rlk)||{!284}rlkppp/mnt1/sandbox/gimp-data-extras-1.1.26]
$ ./configure
loading site script /usr/local/share/config.site
Processing GNUstep site configuration
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gimptool... /usr/local/Tools/gimptool
checking for GIMP - version = 1.1.26... no
*** Could not run GIMP test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GIMP was incorrectly installed
*** or that you have moved GIMP since it was installed. In the latter case, you
*** may want to edit the gimptool script: /usr/local/Tools/gimptool
configure: error: Test for GIMP failed. See file 'INSTALL' for help.
--
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
Expanding the Palette
To the Editor of Popular Photography: In your article "Expanding the Palette" in the October 2000 issue, you listed several software products available for image editing and painting in a box on page 62. I was disappointed not to see The GIMP not included in this roundup. This is a very high quality, rich software package that currently runs on Linux/UNIX and OS/2, with a Windows port currently in progress. While The GIMP does not currently have all of the high end prepress capabilities of Photoshop, it comes with an extensive library of tools and plug-ins. It's completely free, and the source code is just as completely free for anyone to experiment with. Most Linux distributions include The GIMP, and those who don't have it, who want to experiment with the latest and greatest, or are simply interested should take a look at http://www.gimp.org. -- 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: Expanding the Palette
Date: Sun, 24 Sep 2000 22:36:05 -0500 From: Jon Winters [EMAIL PROTECTED] Robert L Krawitz wrote: To the Editor of Popular Photography: In your article "Expanding the Palette" in the October 2000 issue, you listed several software products available for image editing and painting in a box on page 62. I was disappointed not to see The GIMP not included in this roundup. snip In contrast, the October 2000 issue of Web Techniques magazine has a cover story titled "Tools of The Trade" where they interviewed developers and designers of some of the net's hottest web sites. Here is what one developer had to say about the Gimp: Web image editing is much lower resolution than photo editing/print image creation. More interesting for this purpose would be people who use the Gimp for fine art or such. -- 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: TODO for 1.2 release
Date: Mon, 25 Sep 2000 20:21:45 +0100 From: Nick Lamb [EMAIL PROTECTED] Enough hilarity. If you know of something which must be done before 1.2.0 please follow on to this mail. If you know of a reason why we should unfreeze Gimp instead, feel free to let loose. I would like to get gimp-print 4.0 in. Currently we're at beta 1 stage, and I'm being pretty hard nosed about what's going to be allowed in (I personally favor the 2x4 approach to release engineering :-) ). There's only one obvious showstopper for us right now; there are some problems with the HP driver that are being sorted out, but other than that it's very close to what 4.0 is going to be, particularly insofar as the print plug-in proper goes. -- 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
ANNOUNCE: gimp-print 4.0b2
This is the second (and hopefully last) beta release of gimp-print 4.0. It is not the final 4.0 release, but it is very close. We anticipate that the final 4.0 will happen in a few weeks, after more testing and any necessary bug fixes. In addition, we expect support for the Epson Stylus Color 777 and Stylus Pro 7500 to be present in the final release. That will bring the number of supported printer models to 90. Gimp-Print 4.0b2 is primarily a bug fix release. Please read the release notes carefully, as usual. The release notes are rather long, and are not included in this announcement. However, most of the changes are relatively minor. -- 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
ANNOUNCE: gimp-print 4.0.3
Gimp-print 4.0.3 is a stable release in the 4.0 line. Ghostscript users and users of the HP DeskJet 1200C should take this update; it is optional for others. Gimp-Print 4.0.3 contains the following fixes over Gimp-Print 4.0.2: 1) The fix to the GhostScript driver in 4.0.2 broke the handling of printer-specific variables. This is now fixed. 2) The documentation in Ghost/README contains more information on the color settings. 3) The HP DeskJet 1200C should now operate correctly in color mode. 4) The CUPS utility named 'calibrate' has been renamed 'cups-calibrate' because of name collisions on some systems. -- 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
ANNOUNCE: Gimp-Print 4.0.4
This is an emergency release due to a bug in the configure script. This bug was fixed in beta, but reappeared due to a system upgrade that replaced the fixed file. There is another quality fix. All users should take this upgrade. Gimp-Print 4.0.4 contains the following fixes over Gimp-Print 4.0.3: 1) The gimp-print configure script failed on version of the Gimp older than 1.1.20 or thereabouts, give or take a few versions. That should now work correctly. This bug was present in 4.0b2 and was fixed in 4.0b3; it reappeared due to a system upgrade on the build system. 2) A bug in the color conversion routine caused very serious posterization effects in certain images (specifically, in regions of very low saturation) in Photograph mode. -- 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: 1.2 and beyond
From: Sven Neumann [EMAIL PROTECTED] Date: 10 Dec 2000 18:50:36 +0100 As Mitch already pointed out, bug fixes will go into the 1.2.x branch. The issue's not bug fixes, but feature enhancements -- new printers, quality improvements, and such, as we're already working on our 4.1. Should we plan on just doing our own releases, as we've done thus far, or will there be some kind of update release train that we can sync up to prior to 1.4? I don't expect an answer right now; this is an important issue of release strategy that shouldn't be answered quickly, but it's something that needs to be considered given how large a package the Gimp is. -- 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: How much longer do I have to put up with this... (miles o'neal)
Date: Mon, 11 Dec 2000 21:34:12 +0900 (JST) From: [EMAIL PROTECTED] You can ignore "bad language" in the first one, because you can still perfectly understand the issues raised there. If you think they are issues in the first place. Apparently, some people don't. You could have also written that note more professionally and saved yourself a lot of the anger in response. -- 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: [gimp-devel] Menus, shortcuts, and internationalization
Date: Tue, 12 Dec 2000 15:31:07 +0100 From: Simon Budig [EMAIL PROTECTED] Dont argue with speed: Pressing Alt-F + x to exit a program is definitely more complicated than pressing Ctrl-Q. This goes double for nested menus. In this *particular* instance, faster != better IMHO. Exiting the program is a sufficiently destructive act (even if all of the files are saved -- you lose the undo information, the clipboard, etc.) so that it shouldn't be that easy to do unless the user wants it to be that way. That said, in emacs I've bound C-xC-c to a function that prompts me for whether I want to exit, but in the shell I unset ignoreeof (so that C-d exits me). It's a matter of personal taste here. However, I don't like that fact that C-q exits and C-w closes windows in a lot of applications (and exits if that was the last open window). It's probably due to emacs being in my fingers. This is a rather specific comment, and deliberately doesn't address the general issues surrounding accelerators.
ANNOUNCE: gimp-print 4.1.0
This is gimp-print version 4.1.0, the initial development on the 4.1 line. This plugin can be compiled against either Gimp 1.1 or 1.0. After 1.2 is released, we anticipate dropping support for Gimp 1.0 and older versions of Gimp 1.1 (probably 1.20 and earlier, although that is not guaranteed). Print 4.1.0 contains all fixes through the 4.0.4 release. In addition, it contains the following user-visible differences over Print 4.0.4: 1) Greatly improved color quality in Photograph mode. In particular, red, green, blue, and violet colors are much more accurate. This is done by means of hue and luminosity adjustments based on input hue and saturation. This only works in Photograph mode; Line Art and Solid Colors have not changed. 2) Preliminary support for the Lexmark Z52 inkjet printer. 3) Support for 2880x720 on Epson Stylus printers that support that resolution. The visible quality difference will probably be little if any. 4) Fine black detail in color mode is greatly improved. 5) Many new resolutions have been added for Epson Stylus printers, mostly supporting better print quality at 180, 360, and 720 DPI. 6) There is preliminary support for 600x600 C-RET mode on the HP 840. 7) The foomatic package is not currently being distributed with gimp-print. The main issue is synchronizing the foomatic database with the rapidly evolving state of gimp-print. We have not determined yet whether it will be practical to continue distributing foomatic with gimp-print. 8) The PPD's generated as part of the native CUPS driver are incompatible with the PPD's in the 4.0 version of the native CUPS driver. This requires reinstalling your printers after running 'make install' in the cups subdirectory. 9) The defaults with the native CUPS driver are now identical to the defaults with the Ghostscript stp driver and the Gimp Print plugin. 10) Ordered dithering is now smoother on 6 color printers, at some loss of color fidelity.
1.1.31 build problem
From gimp-1.1.31.tar.bz2 on ftp.gimp.org. Making all in po-plug-ins make[2]: Entering directory `/mnt1/sandbox/gimp-1.1.31/po-plug-ins' make[2]: *** No rule to make target `../plug-ins/common/spheredesigner.c', needed by `gimp-std-plugins.pot'. Stop. make[2]: Leaving directory `/mnt1/sandbox/gimp-1.1.31/po-plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt1/sandbox/gimp-1.1.31' make: *** [all-recursive-am] Error 2 -- 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
GUI idea...
There's a certain kind of correction that we're using in gimp-print that I'd like to be able to create a GUI element for. In order to get more accurate colors, I've come up with with a color correction technique in HSL space based on hue mapping and luminosity mapping. It's based on the following two transforms: Ho = F(Hi) F is a map (currently 48 points, with linear interpolation) Lo = pow(Li, S * G(Ho)) G is another map (no quibbles about RGB vs. CMY space for now, please) That is, first the output hue is computed from the input hue, and then the gamma is adjusted based on the hue, scaled by the saturation. Somewhat to my surprise, it actually does a halfway decent job. I'm not entirely sure what this GUI element would look like. It has something in common with a curves adjustment, but it would be useful to display the result somehow. Currently the F and G maps are embedded in the code, but clearly they need to be adjustable somehow. Having a useful way for people to fiddle with them would be particularly handy. There also need to be standalone utilities that can generate the necessary maps for the Ghostscript and CUPS drivers, as well as for the print plugin. Hopefully a well-designed widget could be used for all three applications. -- 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: Request to make a UltraFractal clone
Please feel free to write this plugin. -- 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
ANNOUNCE: Gimp-Print 4.1.1
This is gimp-print version 4.1.1, a development release on the 4.1 line. Print 4.1.1 contains the following fixes and improvements over 4.1.0: 1) Further improvements in quality (we believe) in Photograph mode. 2) A problem whereby black letters and other black detail had a hollow appearance under some circumstances is fixed. 3) The Canon S450 is now supported. 4) The Epson Stylus Color 640 and 660 should print correctly. 5) escputil now uses readline when available. -- 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: Optional background window ?
Date: Sat, 6 Jan 2001 11:56:22 -0800 (PST) From: Matts Kivik [EMAIL PROTECTED] I have showed the Gimp to driven photoshop users, and they all complained at one thing, the fact that gimp does not have a "root" window, like photoshop in windows have. As long as no one's *forced* to use an MDI interface, thank you.
ANNOUNCE Gimp-Print 4.1.2
All users of the Epson driver should take this release, particularly if you've had problems with the very bottom of the print not printing out and the page not ejecting (this is accompanied by a segmentation violation if it happens). The next release of gimp-print will include a major reorganization that puts it more in line with GNU packaging standards. This is a somewhat emergency release because of large numbers of reports of problems with 4.1.1. Print 4.1.2 contains the following fixes and improvements over 4.1.1: 1) We believe this release contains an important bug fix that in some cases caused the Epson driver to seg fault upon completion. This resulted in the page being slightly incomplete at the bottom, and in addition the page was not ejected. 2) Further improvements in quality (we believe) in Photograph mode. 3) Correct sizing for extremely tiny images in the Print plugin. 4) First cut at roll feed printing for the Epson Stylus Photo 870/1270. 5) Support for custom paper sizes in the Print plugin. 6) Initial support for the Lexmark 3200, and other improvements in the Lexmark driver. 7) Preliminary support for the Epson Stylus Photo 790/890/1290 (followons to the 870/1270). 8) Fixes to the Debian installation. 9) Preliminary support for the Canon BJC-55 and BJC-85. 10) The Ghostscript Makefile snippets now contain a proper dependency on gdevstp-print.h. 11) Many internal changes to prepare for a major code reorganization that is coming up shortly. These changes should be completely invisible at user level. -- 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
