Gimp batch mode
Please reply to me directly via email as I am not on the mailing list. I am trying to get batch mode working with script-fu-old-photo. However I cannot get it working despite my attempts to follow the docs on adrian.gimp.org. Does anyone have any suggestions on how I can get this working or of another program which will allow me to do this. I need to edit ~500 images and it would save me a lot of time if i can get it done automatically. Thanks for your time, David Burley [EMAIL PROTECTED] -- Spruce: happier than a pig in shit
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: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > One of us defintely works too much and too fast. Uhm, but who? I think its you... :)) Sven, you are doing great work > I have just checked > in a working solution which gets rid of the annoying > iterate-through-all-domains problem. Great > Sorry, but when I had the idea how it could work (actually Mitch > helped a little) I just had to try it. Since the changes are so small > and no new files are necessary at all, I just had to check them in. > The overall idea is of course still yours and we owe you much for > solving the i18n problem. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, > Back to work: > > New patch, also containing a proper cleanup function and the necessary > call in app_procs.c appended. One of us defintely works too much and too fast. I have just checked in a working solution which gets rid of the annoying iterate-through-all-domains problem. Sorry, but when I had the idea how it could work (actually Mitch helped a little) I just had to try it. Since the changes are so small and no new files are necessary at all, I just had to check them in. The overall idea is of course still yours and we owe you much for solving the i18n problem. Salut, Sven
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: >> I sent a newer patch in my last mail. It should do everything we >> need for now. > No, it will most likely crash the Gimp (explanation of the usage > of GSList in a private mail) No, it won't. Since g_slist_append COULD change the value of the the beginning but does not. Anyway, I have had it in my code the recommended way but it got lost while cutting and pasting. No it's there again. > and it won't work the first time the plug_in is started. That's right, was a braino, is changed now. > I'll check my code in in a few minutes. Should provide a framework > to add the rest upon. Great. > Ok, I'll try: Right now we will have to iterate through all domains > when trying to translate the menus. Since we know what domain the > plugin is in, we are able to choose the right one when its procedures > try to install the menupath. Since that is done from plug_in.c it > would be possible to pass the domain to the menu_item_factory code. Of > course we will still have to bind to all domains in our list. Hm, makes sense to me. Will look at this later. I'd also recommend getting rid of this "let's add the submenus for the plugins" hack. I have something more dynamic in mind which will also work for external plugins and possibly reduce code size and bugprobability. > PS: BTW, I did not ment you and Marc in my comment about the print > plugin. Okay, sorry then. > Why do you think so? Well, you are quite offensive in the last time concerning me and you mailed Marc and me concering a patch which was wrong not too long ago. Back to work: New patch, also containing a proper cleanup function and the necessary call in app_procs.c appended. -- Servus, Daniel diff33.gz
Re: Crash in Gimp 1.1.7 on Solaris 8.
In regard to: Re: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said...:
>Tim Mooney wrote:
>
>> In regard to: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said (at...:
>>
>> >signal BUS (invalid address alignment) in color_pixels at 0x177858
>> >color_pixels+0x110: ld [%l0], %i1
>>
>> You don't say what architecture you're running on, but Solaris 7 or later on
>> an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment
>> would be indicative of incorrect alignment of a pointer. I'm not certain,
>> but odds are good that pointers in Solaris 8 must be aligned on 8-byte
>> boundaries, as opposed to ints which could be aligned on 4-byte boundaries.
>>
>
>SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
>UltraSPARC-IIi
>
>But I haven't compiled with the 64 bit flag on !
>
>A simple program like this :
>main(){
>printf("%d\n", sizeof(unsigned char *));
>}
>
>returns 4 !
Then my guess about what the problem is (for you, anyway) isn't correct.
It's still a problem for LP64 OSes, though.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Re: Crash in Gimp 1.1.7 on Solaris 8.
Tim Mooney wrote:
> In regard to: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said (at...:
>
> >signal BUS (invalid address alignment) in color_pixels at 0x177858
> >color_pixels+0x110: ld [%l0], %i1
>
> You don't say what architecture you're running on, but Solaris 7 or later on
> an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment
> would be indicative of incorrect alignment of a pointer. I'm not certain,
> but odds are good that pointers in Solaris 8 must be aligned on 8-byte
> boundaries, as opposed to ints which could be aligned on 4-byte boundaries.
>
SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
UltraSPARC-IIi
But I haven't compiled with the 64 bit flag on !
A simple program like this :
main(){
printf("%d\n", sizeof(unsigned char *));
}
returns 4 !
Ludovic.
>
> > register unsigned char c0, c1, c2;
> > register guint32 *longd, longc;
> > register guint16 *shortd, shortc;
>
> I can't tell by the code what the intent is, but these definitions have
> longd as a pointer (an 8-byte quantity on LP64 machines) while longc is
> an unsigned 32-bit quantity (*not* a pointer). Ditto for shortd and shortc.
>
> > switch (bytes)
> > {
> > case 1:
> > memset(dest, *color, w);
> > break;
> > case 2:
> > shortc = ((guint16 *)color)[0];
>
> This is probably also a problem here -- shortc isn't big enough to hold
> an address.
>
> > shortd = (guint16 *)dest;
> > while (w--)
> > {
> > *shortd = shortc;
> > shortd++;
> > }
> > break;
> > case 3:
> > c0 = color[0];
> > c1 = color[1];
> > c2 = color[2];
> > while (w--)
> > {
> > dest[0] = c0;
> > dest[1] = c1;
> > dest[2] = c2;
> > dest += 3;
> > }
> > break;
> > case 4:
> > longc = ((guint32 *)color)[0]; Crash here !
>
> longc is a 32 bit quantity, which isn't big enough to hold an address on
> LP64 machines. That's probably why you're getting the crash. I bet I
> would get the same result (or at least an "unaligned access" warning) on
> my Tru64 Unix box.
>
> > longd = (guint32 *)dest;
> > while (w--)
> > {
> > *longd = longc;
> > longd++;
> > }
> > break;
> > default:
> > {
> > int b;
> > while (w--)
> > {
> > for (b = 0; b < bytes; b++)
> > dest[b] = color[b];
> >
> > dest += bytes;
> > }
> > }
> > }
> >}
>
> I'm not sure what the right fix is, being I haven't looked long enough at
> the code to decipher what's going on. The problem is almost certainly a 32 bit
> vs. 64 bit issue, though.
>
> Tim
> --
> Tim Mooney [EMAIL PROTECTED]
> Information Technology Services (701) 231-1076 (Voice)
> Room 242-J1, IACC Building (701) 231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > No, that won't work. Of course you need to hook somewhere into > plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins > won't be able to register their domain on the first call. Of course you are right, just a braino. >> The only thing missing now is the pluginrc write code. > Huh? The info is already written into the pluginrc! I didn't say what I mean (TM), I meant the PDB code. New patch appended. -- Servus, Daniel diff32.gz
bug squashes little girl
I've had the pleasure on several visits over the last year to watch a friend's little girl grow up, from age three to four. On the first visit, she saw me use gimp, and was facinated by Wilber. She began talking often of "gimp" and "the character". On each subsequent visit, she has insisted on grabing my Wacom pad and engaging in freestyle drawing. A couple of visits ago, she started using keyboard shortcuts, which I admit I found kind of scary ... But she always asks to watch for the latest picture of Wilber during runtime. She's even made a game out of looking for "hidden" Wilbers. Unfortunately, I made the mistake of running the latest CVS for her just yesterday. She shrieked when she saw the dead bug.
Re: Coding style (was: PROPOSAL: New i18n solution)
Glyph Lefkowitz wrote: > On Wed, 23 Feb 100, Miles O'Neal wrote: > > [snip thought GNU style was bad but it's OK] > > > I still don't. Two spaces just isn't enough. Three > > or four is much better. And I like space before the > > paren only if it isn't after a function or procedure > > name. > > And I firmly believe that if God had intended we format our code with > spaces, He would have made them wider. In my own projects, I use a > one-tab-per-indent style. (I have no idea if my style is analagous to > someone else's; I wrote my own .emacs files.) This drives some of my > developers nuts, but it's my perogative, just as it's the GIMP community's > perogative to enforce GNU style. Quantitative studies have shown that from 2 through 6 spaces is optimal. -- "My new computer's got the clocks, it rocks But it was obsolete before I opened the box" - W.A.Y.
Re: PROPOSAL: New i18n solution
Hi, > I'd recommend gimp_plugin_domain_add (gchar *domain_name) > and gimp_plugin_domain_add_with_path (gchar *domain_name, > gchar *domain_path) > > because it IMHO fits better into the namespace and is more obvious > than to have just 1 function with two meanings. Ok, I'll change it then and provide two wrappers for one PDB call. > I sent a newer patch in my last mail. It should do everything we need > for now. No, it will most likely crash the Gimp (explanation of the usage of GSList in a private mail) and it won't work the first time the plug_in is started. > I totally agree with this solution, so let's finalize it and get it > into the tree. I'll check my code in in a few minutes. Should provide a framework to add the rest upon. > > While working on the code I came across a new idea which would > > simplify things quite a bit eventually: The plugins create their > > menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why > > not use the knowledge about the domain_name the translated string is > > to be found in and only look it up in that domain by passing it to > > menus_create_item_() ? You'd only have to change the code to iterate > > through the plug_in_defs instead of proc_defs since the domain is > > stored with the plug_in definition. > > I'm afraid I don't understand that. Could you please explain it again? Ok, I'll try: Right now we will have to iterate through all domains when trying to translate the menus. Since we know what domain the plugin is in, we are able to choose the right one when its procedures try to install the menupath. Since that is done from plug_in.c it would be possible to pass the domain to the menu_item_factory code. Of course we will still have to bind to all domains in our list. Salut, Sven PS: BTW, I did not ment you and Marc in my comment about the print plugin. Why do you think so? But I might be at least partly guilty ...
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > gimp_plugin_add_locale_domain (gchar *domain_name, > gchar *domain_path) > and can only be called in the query function of a plug-in. The > domain_path may optionally be NULL. Proposals for a better name are > welcome. I'd recommend gimp_plugin_domain_add (gchar *domain_name) and gimp_plugin_domain_add_with_path (gchar *domain_name, gchar *domain_path) because it IMHO fits better into the namespace and is more obvious than to have just 1 function with two meanings. > Daniel, if we can agree on this solution, I would like to check this > code in, so that you can work on adapting your code to the framework. I sent a newer patch in my last mail. It should do everything we need for now. I totally agree with this solution, so let's finalize it and get it into the tree. > While working on the code I came across a new idea which would > simplify things quite a bit eventually: The plugins create their > menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why > not use the knowledge about the domain_name the translated string is > to be found in and only look it up in that domain by passing it to > menus_create_item_() ? You'd only have to change the code to iterate > through the plug_in_defs instead of proc_defs since the domain is > stored with the plug_in definition. I'm afraid I don't understand that. Could you please explain it again? -- Servus, Daniel
Re: print plugin
On 23 Feb, Sven Neumann wrote: > I hate to note that, but hopefully this will teach the one who applied > that patch in request of someone else, to check patches more > carefully before applying them. If you want to know who is ment here, > read the ChangeLog. But I think you already guessed it... I think you shot yourself into the foot. I guess you meant me and Marc but in fact I never touched the print plugin but ChangeLog says: Mon Jan 31 22:43:48 CET 2000 Sven Neumann <[EMAIL PROTECTED]> * libgimp/gimpcolorspace.c * libgimp/gimpcolorspace.h: added INTENSITY() macro [ ripped off a few entries ] * plug-ins/print/print-util.c * plug-ins/rcm/rcm_misc.h: use INTENSITY() and other color_conversion_routines from libgimp. I'm not sure if I have tested all this properly (I tried to do), so if you are bored, please play around with the changed plug-ins. I guess this one introduced it. However it could also have been this one: Mon Feb 7 12:57:16 CET 2000 Stanislav Brabec <[EMAIL PROTECTED]> * plug-ins/common/sparkle.c, plug-ins/common/bumpmap.c, * plug-ins/common/gz.c, plug-ins/common/tileit.c, * plug-ins/common/oilify.c, plug-ins/maze/handy.c, * plug-ins/print/print-util.c, plug-ins/sinus/sinus.c, * app/channels_dialog.c, app/fileops_cmds.c, * app/nav_window.c, app/path_tool.c, app/scan_convert.c, * app/xinput_airbrush.c, app/airbrush_blob.c: On request of Martin Weber <[EMAIL PROTECTED]>. Remove obsoletted rgb<->hsv routines, purifications. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, > I added a few lines to your modified gimprc.c to support that. No, that won't work. Of course you need to hook somewhere into plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins won't be able to register their domain on the first call. > The only thing missing now is the pluginrc write code. Huh? The info is already written into the pluginrc! Salut, Sven
Re: PROPOSAL: New i18n solution
Hi, I have some working code that does use the pluginrc to store the additional locale info for plugins (as described in my earlier mail). Additionally the framework for setting the domain (and optionally a path) from a plugin through a PDB call is complete and tested. The new PDB call would be (in its wrapped form): gimp_plugin_add_locale_domain (gchar *domain_name, gchar *domain_path) and can only be called in the query function of a plug-in. The domain_path may optionally be NULL. Proposals for a better name are welcome. Daniel, if we can agree on this solution, I would like to check this code in, so that you can work on adapting your code to the framework. While working on the code I came across a new idea which would simplify things quite a bit eventually: The plugins create their menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why not use the knowledge about the domain_name the translated string is to be found in and only look it up in that domain by passing it to menus_create_item_() ? You'd only have to change the code to iterate through the plug_in_defs instead of proc_defs since the domain is stored with the plug_in definition. Salut, Sven
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > You will find the patch at > http://sven.gimp.org/files/locale_parse.patch. OK, looks fine to me. I changed my files accordingly. libgimp/gimpdomain.* is now futile. And the gimpgettext.* file were changed to support that scheme. I added a few lines to your modified gimprc.c to support that. The only thing missing now is the pluginrc write code. I added the libgimp and gimp-std-plugins to the default domains, so no need to specify them elsewhere. Also everything works fine like before. Patch against CVS gimp and Sven's patch appended. -- Servus, Daniel diff31.gz
Re: Coding style (was: PROPOSAL: New i18n solution)
On Wed, 23 Feb 100, Miles O'Neal wrote: [snip thought GNU style was bad but it's OK] > I still don't. Two spaces just isn't enough. Three > or four is much better. And I like space before the > paren only if it isn't after a function or procedure > name. And I firmly believe that if God had intended we format our code with spaces, He would have made them wider. In my own projects, I use a one-tab-per-indent style. (I have no idea if my style is analagous to someone else's; I wrote my own .emacs files.) This drives some of my developers nuts, but it's my perogative, just as it's the GIMP community's perogative to enforce GNU style. [snip consistent style important] > I use to feel this way. But now, so long as each file has a > consisten, reasonable style (or preferably, package of files, say a > directory), I'm happy. If it's a requirement of a project that one adhere to a specific coding style, I think it's pretty rude to ignore such a request in contributions to that code, regardless of one's personal beliefs on the matter. > I handle perl as closely as possible to how I handle C. I think Perl should standardize on only 10 or 20 different ways to write a loop before you start worrying about indentation. And people wonder why Python has the whitespace enforcement rules... ::runs from Marc :-):: __ __ __ _ _ _ | | \_/ |_] |_| |_| |_ || | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
Re: Crash in Gimp 1.1.7 on Solaris 8.
In regard to: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said (at...:
>signal BUS (invalid address alignment) in color_pixels at 0x177858
>color_pixels+0x110: ld [%l0], %i1
You don't say what architecture you're running on, but Solaris 7 or later on
an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment
would be indicative of incorrect alignment of a pointer. I'm not certain,
but odds are good that pointers in Solaris 8 must be aligned on 8-byte
boundaries, as opposed to ints which could be aligned on 4-byte boundaries.
> register unsigned char c0, c1, c2;
> register guint32 *longd, longc;
> register guint16 *shortd, shortc;
I can't tell by the code what the intent is, but these definitions have
longd as a pointer (an 8-byte quantity on LP64 machines) while longc is
an unsigned 32-bit quantity (*not* a pointer). Ditto for shortd and shortc.
> switch (bytes)
> {
> case 1:
> memset(dest, *color, w);
> break;
> case 2:
> shortc = ((guint16 *)color)[0];
This is probably also a problem here -- shortc isn't big enough to hold
an address.
> shortd = (guint16 *)dest;
> while (w--)
> {
> *shortd = shortc;
> shortd++;
> }
> break;
> case 3:
> c0 = color[0];
> c1 = color[1];
> c2 = color[2];
> while (w--)
> {
> dest[0] = c0;
> dest[1] = c1;
> dest[2] = c2;
> dest += 3;
> }
> break;
> case 4:
> longc = ((guint32 *)color)[0]; Crash here !
longc is a 32 bit quantity, which isn't big enough to hold an address on
LP64 machines. That's probably why you're getting the crash. I bet I
would get the same result (or at least an "unaligned access" warning) on
my Tru64 Unix box.
> longd = (guint32 *)dest;
> while (w--)
> {
> *longd = longc;
> longd++;
> }
> break;
> default:
> {
> int b;
> while (w--)
> {
> for (b = 0; b < bytes; b++)
> dest[b] = color[b];
>
> dest += bytes;
> }
> }
> }
>}
I'm not sure what the right fix is, being I haven't looked long enough at
the code to decipher what's going on. The problem is almost certainly a 32 bit
vs. 64 bit issue, though.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Re: Fixed?
On 23 Feb, Tuomas Kuosmanen wrote: > I get this gdk error: > Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) > serial 37493 error_code 9 request_code 14 minor_code 0 > ** WARNING **: wire_read: unexpected EOF (plug-in crashed?) > the it burns to ashes. However it might be related to something else, > I have had a lot of crashes in the last week or so. In random places, > trying to figure out where. Some seem to be related to undo stuff. Strange. Could you please send me a stacktrace? -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > Ok, one shouldn't just bitch about other people's code, so here is my > patch that adds an optional locale_domain and locale_path to the > plugin structure and extends the pluginrc code to read and write that > information from/into the pluginrc. This code is obviously a few > lines longer than what Daniel proposes, but it seems to work very > well here. Great! I'll have a look. > The locale information is optional and if the locale_domain is given, > there _can_ be an additional locale_path entry. The code handles the > case that pluginrc registers the locale_domain twice (by using the > last given entry), but that should never happen unless the user edits > the pluginrc by hand. Hm, I don't really now whether this assumption is safe, but anyway it's a thing we don't have to fiddle with right now. > You will find the patch at > http://sven.gimp.org/files/locale_parse.patch. > It only contains the code to read, store and write the locale info for > the plug-ins. This will have to be extended to do build a list out of > this entries (eventually checking for the existence of the given > paths). Other necessary parts can be taken from Daniels patch. The code for building the list is also there. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: > Huh? Daniel, stop spreading FUD and read the code. The parser in > gimprc is actually pretty flexible. No, it isn't. It supposes a fixed order and fixer number of arguments (except the pdbargs of course), that anything but flexible. A tag based system on let's say XML would be a lot more flexible and allow us to save some bytes in the pluginrc. > Well, I have no problem to discuss the arguments, I just had the > impression that you simply ignored them... No, I wouldn't ever do that. > A PDB call is actually no harm. IMO libgimp should not fiddle with > configuration files at all. Since the localisation of the menuentries > is a problem in the core and not one of each and every plugin, putting > the functionality into libgimp is actually bad style. But simple. I have no problem with a more complex solution as long as is seems reasonable and maintainable in a "frozen" tree. > I am proposing exactly the same solution, with a little difference: > Instead of doing the work in libgimp which is not suited to work > with configuration files, make the libgimp call be a PDB wrapper > and let the application handle the dirty work. Okay. > The advantage I see is that we will not need another configuration > file and we have the information about a plugins gettext-domain > in the plugin structure where it belongs and where it is automatically > kept in sync with the list of installed plug-ins. Let's sync our ideas. We add two optional entries after the PDB args in pluginrc which get's parsed by the normal parser and inserted in a list and then my code does the rest. -- Servus, Daniel
Re: print plugin
Hi, > I think I know why Michael got his solid black output, and it had > nothing (really) to do with the bug fixes I did for 3.0.7. The > problem was that someone ripped out the calc_rgb_to_hsv and > calc_hsv_to_rgb functions I put in print-util and replaced them with > gimp_calc_rgb_to_hsv4 without taking a closer look at what's going > on. My functions operated on unsigned shorts (16 bits), while the > libgimp versions operate on unsigned chars (8 bit). So whenever > anyone used a saturation other than 1.0, the top 8 bits were > effectively stripped off the rgb values, making them close to zero > (and hence the cmy values close to 1). I'm surprised that a lot more > people didn't stumble over this. > > There are good reasons for the print code to be 16 bit -- 8 bit output > resolution is insufficient for printing when you take into account the > gamma that is required to get decent output. The highlight tones > (light areas) are compressed into a very narrow range, and in some > cases even 16 bits of resolution results in two input levels (between > 0 and 255) mapping into identical output levels. Please don't be too > quick to gratuitously change code like that. I hate to note that, but hopefully this will teach the one who applied that patch in request of someone else, to check patches more carefully before applying them. If you want to know who is ment here, read the ChangeLog. But I think you already guessed it... Salut, Sven
print plugin
I will be sending Sven the 3.0.8 patches shortly. I think I know why Michael got his solid black output, and it had nothing (really) to do with the bug fixes I did for 3.0.7. The problem was that someone ripped out the calc_rgb_to_hsv and calc_hsv_to_rgb functions I put in print-util and replaced them with gimp_calc_rgb_to_hsv4 without taking a closer look at what's going on. My functions operated on unsigned shorts (16 bits), while the libgimp versions operate on unsigned chars (8 bit). So whenever anyone used a saturation other than 1.0, the top 8 bits were effectively stripped off the rgb values, making them close to zero (and hence the cmy values close to 1). I'm surprised that a lot more people didn't stumble over this. There are good reasons for the print code to be 16 bit -- 8 bit output resolution is insufficient for printing when you take into account the gamma that is required to get decent output. The highlight tones (light areas) are compressed into a very narrow range, and in some cases even 16 bits of resolution results in two input levels (between 0 and 255) mapping into identical output levels. Please don't be too quick to gratuitously change code like that. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: PROPOSAL: New i18n solution
Hi, Ok, one shouldn't just bitch about other people's code, so here is my patch that adds an optional locale_domain and locale_path to the plugin structure and extends the pluginrc code to read and write that information from/into the pluginrc. This code is obviously a few lines longer than what Daniel proposes, but it seems to work very well here. The locale information is optional and if the locale_domain is given, there _can_ be an additional locale_path entry. The code handles the case that pluginrc registers the locale_domain twice (by using the last given entry), but that should never happen unless the user edits the pluginrc by hand. You will find the patch at http://sven.gimp.org/files/locale_parse.patch. It only contains the code to read, store and write the locale info for the plug-ins. This will have to be extended to do build a list out of this entries (eventually checking for the existence of the given paths). Other necessary parts can be taken from Daniels patch. What is missing right now is a function to add the locale_domain and locale_path information from a plugin using a PDB call. This will follow later. Salut, Sven
Error compiling gimp1.1.7 on PC/Linux
Please can anybody tell me the reason for this error message and where i get the files 'make' is looking for? Running Mkbootstrap for Gimp::Lib () chmod 644 Lib.bs LD_RUN_PATH="/usr/local/lib" cc -o ../blib/arch/auto/Gimp/Lib/Lib.so -shared -L/usr/local/lib -L./../../../libgimp/.libs -Lirprefix/../../libgimp -lgimp -L/usr/local/lib -lglib /intl/libintl.a Lib.o cc: /intl/libintl.a: No such file or directory make[4]: *** [../blib/arch/auto/Gimp/Lib/Lib.so] Error 1 make[4]: Leaving directory `/usr/src/gimp-1.1.17/plug-ins/perl/Gimp' thanks, martin
Re: PROPOSAL: New i18n solution
Hi, > It was meant such, but from your description it seemed to me that > you'd like to add those entries to ALL plugins. From your answer > I can see that this was just a misunderstanding. Sorry, Sven. > > But this make it even harder to modify the parser like you'd like > since it's only usable for a fixed number of arguments. It would work > to insert those parameters before the pdb-args but that would > a) be incompatible and b) mean that every plugin must have such an entry. Huh? Daniel, stop spreading FUD and read the code. The parser in gimprc is actually pretty flexible. > Of course I try to wipe them away if they seem not reasonable or > correct to me, that's how argumentation works. HOWEVER this > doesn't mean that I don't care about your thoughts, they are > really helpful and result in new ideas in my head. Well, I have no problem to discuss the arguments, I just had the impression that you simply ignored them... > Just to clarify what I do think of: > I'd like to have this done as simple as possible that means: > - No PDB calls A PDB call is actually no harm. IMO libgimp should not fiddle with configuration files at all. Since the localisation of the menuentries is a problem in the core and not one of each and every plugin, putting the functionality into libgimp is actually bad style. > - No wire protocol changes There is no need for one, I was wrong here. > There should be a simple libgimp call which allows plugins to > register themselves in a new domain. If the domain is already > available, check whether the path matches (not done in my patch > yet!), if not simply add it. > The GIMP on the other side should simply be able to get all the > registered domains and to do the right things when gimpgettext() > is called. I am proposing exactly the same solution, with a little difference: Instead of doing the work in libgimp which is not suited to work with configuration files, make the libgimp call be a PDB wrapper and let the application handle the dirty work. The advantage I see is that we will not need another configuration file and we have the information about a plugins gettext-domain in the plugin structure where it belongs and where it is automatically kept in sync with the list of installed plug-ins. Salut, Sven
