Re: [Gimp-developer] Re: Gimp 1.3.23 available
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: I did build the latest libwmf (2.8.1). It required some minor patches to its source. But it's not installation-location-independent (like for instance GTK and GIMP are). It looks for its fonts in a I location fixed at build time. This is not acceptable on Windows. I need to fix that, and submit patches to the libwmf maintainer. Perhaps you could also have a quick look at GAP (CVS module gimp-gap). It seems to be experiencing a similar problem: http://bugzilla.gnome.org/show_bug.cgi?id=126000 We will try to start doing GAP prereleases soon. It would be nice if GAP would then be available for Win32 also. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: gimp-plugin-template 1.3.2
Hi, While GIMP is approaching the 2.0 release, the libgimp* APIs are stabilizing and it's about time to update plug-ins so they will work with GIMP-2.0. In order to help you with this effort and to encourage you to write some fancy new plug-ins, here's a new release of the GIMP Plug-In Template: ftp://ftp.gimp.org/pub/gimp/plugin-template/gimp-plugin-template-1.3.2.tar.gz The gimp-plugin-template is a build environment and some stubs to get you started writing your own plug-in. It features a working autoconf/automake setup, is prepared for internationalization and supports the new GIMP help system. Basically all you need to do is to tweak the user interface to your needs and add some nice image manipulation routines. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP UI discussion on Inkscape list
Hi, here are some links to discussion about the GIMP user interface and how Inkscape could benefit from it: http://sourceforge.net/mailarchive/forum.php?thread_id=3546965forum_id=36054 http://sourceforge.net/mailarchive/forum.php?thread_id=3546964forum_id=36054 http://sourceforge.net/mailarchive/forum.php?thread_id=3548256forum_id=36054 The latter link shows some fundamental misunderstandings. Almost all issues the author brings up here only exist because he didn't understand the user interface and how to configure it to his needs. Still interesting to read though... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [gimpwin-users] Re: Gimp 1.3.23 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tor Lillqvist wrote: | Tor Lillqvist writes: | Possibly the lcms.dll in the lcms11.zip file isn't suitable as such | to be used from GIMP, but will have to be rebuilt from source. | | Yes, that seems to be the case. I don't know the technical reasons, | but when I built the lcms DLL from sources (a rather simple | ./configure --disable-static make job), no crash any longer. | | Still, as I really don't understand colour management very well, I'll | leave it to others to say whether it is useful or not. (In fact I am a | bit colourblind, so I have wondered whether it even would make any | sense for me to try to use a colour managed workflow for my digital | photo workflow at all ;-).) There has been some work done to try and use color matching software to do color matching and proofing for color-blind people. This has been mostly done as accessibility research. I think prepress applications can be found as well. This is not the original link I found, but it is pretty good: http://www.internettg.org/newsletter/mar99/accessibility_color_challenged.html This is actually a fairly well researched topic, and I believe the Meyer article was the original source I red on this topic. As for learning about how to apply color management, Real World Color Management by Fraser, Murphy, and Bunting is pretty good, with only a few probably-insignificant for pre-press mistakes. - -- Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/yMBKad4P1+ZAZk0RAoqCAJ0ScDIL3EWQPSYfs1GP0xRwfUXXkwCgpo7b mC8XYN8nkWUxPndQhRjGOSw= =fiso -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
Other effects aside, I am all for preserving the RGB values of each pixel, regardless of it's alpha value. If there is garbage in there, once the mask has the alpha channel, it can be selected by color and one can cut away the previously transparent areas quite easily. Also, the nominations copy from alpha channel and move to alpha channel sound clear enough, while layer's alpha channel by it is own was very obscure to me when I met it first time. Regards, JS -- On Friday 28 November 2003 16:30, [EMAIL PROTECTED] wrote: There's been some controversial discussion in bug #127930 http://bugzilla.gnome.org/show_bug.cgi?id=127930. Raphaël proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Sven Neumann [EMAIL PROTECTED] writes: While GIMP is approaching the 2.0 release, the libgimp* APIs are stabilizing and it's about time to update plug-ins so they will work with GIMP-2.0 as gimp packager in mandrake linux distribution, there's one thing that has always annoy me with the way gimp is released upstream. a library soname should be libname.so.major the major number should be increased when abi or api is broken/altered (eg: libpng-1.0.x was libpng.so.2 whereas libpng-1.2.4 is libpng.so.3). ie the library major is not related to the library version number. major is not increased on version bump but on api and/or abi change (eg: libgal keep increasing its major because of this and gal-0.24 provide libgal.so.23) this enable to have different versions of the same libray installed at the same moment because different programs need different libraries version (eg: libgk+-1.2 and libgtk+2.0) as gimp is concerned: - in the 1.0.x days, its library major was 1. - then in the 1.1.x days, the soname switched from libgimp.so.1 to libgimp-1.1.so.25 aka gimp stoped to follow std major library numbering - in the 1.2.x, it's now libgimp-1.2.so.0 - in the 1.3.x, gimp-1.3.23 library soname is libgimp-1.3.so.23 that is gimp does not anymore follow std major library numbering: - its library major is set to its minor version. - the soname contains the first part of the version number i would like next releases of gimp to follow std library major numbering: - switch back to libgimp.so.23 - increase library major only on API or ABI change (thus libgimpui major may differ from libgimp ...) - do not ever reset major to 0 when gimp-2.0.x is released this would enable: - saner packaging of gimp - distro packagers would know when they've to rebuild packages that depends of gimp because major has been bumper thus meaning that: o either packages should be linked against latest lib because of new abi o or package should be patched for new api thanks :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] What makes the GIMP toolbox special?
hiya, thanks for responding, On Sat, Nov 29, 2003 at 12:54:12PM +0100, Sven Neumann wrote: Carol Spears [EMAIL PROTECTED] writes: are there other instances of tools that do not appear in either the menus or in the toolbox? No. All tools register a menu entry at least. A few of them set a flag that indicates that they don't want to show up in the toolbox. We should probably make this configurable somehow; perhaps for 2.2. Does that answer your question? having seen alts egg in gimp-1.2, i have no idea what might not show up in the gimp menus. i really thought that someone might 'fess (confess) to having a tool or plug-in included in gimp that does not use the usual registration protocol to get there. i was sorry to see only one negative and late response here. i wish i had time to try all the different key combinations on all the buttons of all the widgets to see if what you say is true. one thing i have learned, is that just because i try to do things the right way, it doesn't mean that others have done the same thing. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
On Monday 01 December 2003 19:00, David Neary wrote: (...) And Alpha channel to Layer Mask is unclear? If there is an action of copy alpha to mask and one other of move alpha to mask, then alpha to mask, IMO, is not clear. Actually I dislike the way they are spelled right now (/me run yesterday's compile from the GIMP) hmm..there they are, under initialize layer mask to: Layer's alpha channel and Transfer Layer Alpha Channel Yes...definetly seems like copy layer's alpha channel will be easier to understand at first sight. Transfer or move are both good. Cheers, Dave. -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
Joao S. O. Bueno wrote: Other effects aside, I am all for preserving the RGB values of each pixel, regardless of it's alpha value. If there is garbage in there, once the mask has the alpha channel Agreed. I am of the opinion that modifying the alpha channel should never modify RGB data. If we consider pixels with alpha 0 as undefined, then that isn't a hard fast rule. Also, the nominations copy from alpha channel and move to alpha channel sound clear enough, while layer's alpha channel by it is own was very obscure to me when I met it first time. And Alpha channel to Layer Mask is unclear? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [gimpwin-users] Re: Gimp 1.3.23 available
Tor Lillqvist writes: I did build the latest libwmf (2.8.1). It required some minor patches to its source. But it's not installation-location-independent (like for instance GTK and GIMP are). It looks for its fonts in a I location fixed at build time. This is not acceptable on Windows. I need to fix that, and submit patches to the libwmf maintainer. There is now a port of libwmf (and patched sources) at www.gimp.org/win32/downloads.html (at the bottom of the page). --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
