Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox <[EMAIL PROTECTED]> wrote: [cmyk comversion] > Where I work it is a very critical process. Any tips here? If gimp would support CMYK on-screen, how would the users work be different? Do users actually adjust CMYK themselves or do they just draw using predefined CMYK values? I mean, is the principal problem the missing CMYK colours in RGB, or is the principal problem the "looks the same on-screen as on print". The latter could be solved largely outside the gimp (tiff plug-in), the former obviously not. > with less compulsive designers it is much less critical. This feature > would not get gimp into prepress houses, but might help out the casual > designer who is preparing artwork for a short print run. Would it be worth it? ;) > The most common/best way to do trapping that I have seen is to trap > after the rip using a program like creo/scitex full auto frame (which > isn't quite as auto as the name implies:). Obviously, as only then you have the full image. Hey, the new postscript can do in-rip trapping ;-> (adobe claims yet another revolution ;) > even if it doesn't have a setting I dont think we should modify the > default behaviour of gimp to work around a bug in quark :) well, it depends on wetehr you call this a bug or not. if quark lacks the functionality (if!) to bind profiles to images it's not a bug ;) > > 3. (optional, but important) finally enhance the paths to be multipart, > >contain holes etc. simon? smoon? ;) > > How is #3 optional? :) Well... it's the most difficult part. 1 and 2 could probably be done even in gimp-1.2, #3 is a problem. Also, if you don't have clipping paths you still can print many photos ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug selection (swatters ready!)
On Fri, Nov 30, 2001 at 05:27:26PM +, Dave Neary wrote: >12582 http://bugzilla.gnome.org/show_bug.cgi?id=12582 NEW >jpeg preview makes gimp's open layers dialog segfault > This is a fairly long-running jpeg-based bug. Is this a > libjpeg issue, or is there something we can do about it? libjpeg -- when we first discovered the bug, I was able to reproduce exactly the same bug with cjpeg. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in development
> I am not sure if I understand your code correctly (I am even more of > a newby), but your code seems to only work on grayscale images. Did > you make sure your image was grayscale before you tested your plug-in > on it? Yes that's it: I had tested with a grayscaled image but it didn't work (a PNG image). I retried with a color image transformed into a grayscaled one and it works (enabled). Now I have to make it run without segfault =). Thanks to all. -- [EMAIL PROTECTED] "Le temps ne fait rien à l'affaire, quand on est con, on-est-con !" -- Georges Brassens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.2 Bug selection (swatters ready!)
Hi all, As promised, here's the first of an occasional series I like to call "GIMP 1.2 bugs we know and love". Bug # URL STATUS Description 12582 http://bugzilla.gnome.org/show_bug.cgi?id=12582 NEW jpeg preview makes gimp's open layers dialog segfault This is a fairly long-running jpeg-based bug. Is this a libjpeg issue, or is there something we can do about it? 51780 http://bugzilla.gnome.org/show_bug.cgi?id=51780 NEEDINFO A Tru64 memory issue - can anyone verify this/provide extra info? 17904 http://bugzilla.gnome.org/show_bug.cgi?id=17904 NEW rounding error in calculation of selection boundary The "1 pixel to big or small" bug - Sven sent a patch in for this one a couple of weeks ago. Anyone want to test it, and finally close this one? 22567 http://bugzilla.gnome.org/show_bug.cgi?id=22567 NEW window size confused after un-doing resize (attempt to allocate height 65097) There was a (very) shallow fix (by yours truly) submitted for this almost a year ago, but it's very much alive. There are some recent comments by Sven on this. Anyone feel like attacking it? 63411 http://bugzilla.gnome.org/show_bug.cgi?id=63411 NEW Eraser Tool behaves wrongly when toggling. Seems pretty accessible... 12754 http://bugzilla.gnome.org/show_bug.cgi?id=12754 NEEDINFO Crop From Selection, doesn't quite. Another variation on the +/-1 bugs - but I haven't been able to replicate it. 53811 http://bugzilla.gnome.org/show_bug.cgi?id=53811 NEEDINFO guides not working with Xinput A WACOM bug - I hate these (not least because I don't have one, and hate anyone who does :)) Marked as NEEDINFO, but there's 2 verifications and some xev output there. Enough to get started. 35489 http://bugzilla.gnome.org/show_bug.cgi?id=35489 NEW crop tool doesn't always change canvas size An odd one, this - another intermittent bug. Actually, it's every second time. And only on big images. Go figure. (I mean it, go figure :) Obviously this is a small selection of the 50 or so bugs still open against 1.2, but this is a finite email :) Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] first CVS gimp try
Hi, Hans Meine <[EMAIL PROTECTED]> writes: > I installed gtk+-1.3.10, pango-0.21, atk-0.6 and stuff in the right > order - no problems so far (using pkgconfig-0.8.0 from Mdk8.1 BTW). > > The Gimp compiles with some small setup-hazzles, but has at first some > strange stuff at starting up: > > --->8 snip 8<--- > using MMX: yes > > gimp (pid:11899): ** WARNING **: No fonts found by pangoft2. Things will probably >not work > > gimp (pid:11899): ** WARNING **: Didn't read any pango ft2 fontalias file. Things >will probably not work. your PangoFT2 setup is not complete. Since this setup has changed with Pango-0.22, I will not comment on how to make it work (as a hint: look into the examples dir in the Pango source). > gimp: query called > gimp: query done > gimp: run called extension_plugin_helper > gimp: Could not open module /usr/local/lib/gimp/1.3/plugin-modules/libiwarp.so! > gimp: time for the evil loop > gimp_dialog_factory_add_dialog: registering toplevel "gimp:toolbox" > --->8 snip 8<--- > > Where to a newbie it seems that > - Pango has problems. (?) > - An "evil loop" can't be very nice to have ;-) the "evil loop" is perfectly fine. It originates from some experimental code which is not really used yet. > However, the real problem is that the loading of images fails: > - GIFs have 0 layers works for me. > - JPGs are not really loaded (only the progress dialog appears, until > I press cancel) works for me. > - The same with PNGs ditto. > - TIFs report an error "incorrect count for field MaxSampleValue (1, > expecting 3); tag ignored" and some module segfaults (I get this: haven't tested that. > > /usr/local/lib/gimp/1.3/plug-ins/tiff: fatal error: Speicherzugriffsfehler > /usr/local/lib/gimp/1.3/plug-ins/tiff (pid:12118): [E]xit, [H]alt, show [S]tack >trace or [P]roceed: > > While I could imagine some of them are temporary problems in a > development version, I don't believe you all get all those.. ? well, we are very early in the development process, so you will most likely encounter more of those problems. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it withoutimplementing it.
On Thu, 2001-11-29 at 20:23, [EMAIL PROTECTED] wrote: > > Sometimes you will need to match a logo captured in a photograph to a > > specific "logo colour" , but the first step would be to convert your > > photograph to CMYK. > > But how critical is that process? Do you think that my main point - cheap > conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and > would enable gimp to enter prepress world (even if not at all perfect)? Where I work it is a very critical process. At smaller shops that work with less compulsive designers it is much less critical. This feature would not get gimp into prepress houses, but might help out the casual designer who is preparing artwork for a short print run. > > "Logo Colours" (aka spot colors or PMS colors) can already be used in > > gimp if you are only using one ink at a time. Just save your image as a > > grayscale tiff and place the image in quark using whatever ink you want. > > What about the clipping path, though? I'd guess you want to overlay these > layers often. Yes, clipping paths would be important. > I was told that trapping can be done with expensive plug-ins for photoshop > only, which would make sense, since trapping is (AFAICS, no idea actually) > not really well-defined for photos, what users would buy such a trapping > plug-in for photoshop? Photoshop has had a built in trapping function since atleat version 5.5, but I've never actually used it. I've never seen a photoshop plugin used for trapping, but I suppose it is possible. The most common/best way to do trapping that I have seen is to trap after the rip using a program like creo/scitex full auto frame (which isn't quite as auto as the name implies:). In general trapping shold be done by a prepress professional, not by your average in house designer. > > setting the colour profile to sRGB in gimp is the wrong fix. There > > should be a setting on either quark or the rip that tells it what color > > profile to use for images that have no assigned profile. > > Unfortunately, users usually don't have control over the rip. I guess > whatever rip is used just uses it's defaults for RGB. quark is a difefrent > story - what if quark doesn't have such a setting? even if it doesn't have a setting I dont think we should modify the default behaviour of gimp to work around a bug in quark :) > But I think that acse would be rather irelevant once we have CMYK in tiff. Yep. > >REVISED CONCLUSIONS (ordered my importance). > > 1. implement CMYK saving in tiff and eps. > > 2. enhance tiff(?) & eps to save all channels & paths in whatever format >is actually understood (DCS for eps). one path must be marked as >clipping path (e.g. by name "Clipping Path" or by some parasite >(gimp-clippath on the image containing the ascii form of the path >tattoo or somesuch). > > 3. (optional, but important) finally enhance the paths to be multipart, >contain holes etc. simon? smoon? ;) How is #3 optional? :) Jay Cox [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
