Re: Tiff changes?
>It shouldn't be hard to stick an SVG path in a PNG extension chunk. >If enough apps use it, it will become a standard. And if you change the DTP guys minds, IMHO. From my experiences, it is hard. I have shown PNG, talked about compression, and more things, but some guys still do not get it, they still use old formats, even for internal work, even after showing that the other format gives the same results and loads faster. :[ GSR
Re: Tiff changes?
> Eek. TIFF is very much alive in the print media world..! Just declaring it > sucky is not going to help a lot :| You don't have to declare it sucky. It is sucky by itself :-) > I also heard TIFF is the only format you can supply with a "clipping path" > from photoshop that a DTP package supports. So you can define the image > outline from the paint program with a path, then say "This is the clipping > path for this image" and save it as TIFF. This would be neat for sodipodi, > sketch and whatnot.. any clue if we could do something similar or does > anyone know if something like this exists for other formats too? It would be > useful since the path will always be more accurate than some clipping object > you define in the vector program.. It shouldn't be hard to stick an SVG path in a PNG extension chunk. If enough apps use it, it will become a standard. Federico
Re: Tiff changes?
Thus spoke Tuomas Kuosmanen > On Sat, May 06, 2000 at 03:06:26AM +0100, Nick Lamb wanted to say the following: > > NB None of this affects loading images, and you should NOT be > > creating more TIFFs, so hopefully right thinking people are quite > > unaffected apart from this build problem. > > Eek. TIFF is very much alive in the print media world..! Just declaring it > sucky is not going to help a lot :| Yes, this was the response I was going to give. Although Nick provides some very good technical reasons why we might not to want to work with TIFF, it happens to be the only format (provided it's not compressed) that seems to work for all the publishers I deal with. So, I'm pretty much stuck with using TIFF for now. -- Michael J. Hammel |We need somebody who can work The Graphics Muse |independently and innovatively in the [EMAIL PROTECTED] |face of unreasonable demands." http://www.graphics-muse.comJob posting at Stanford CS Department
Re: Tiff changes?
On Sat, May 06, 2000 at 11:26:25PM +0300, Tuomas Kuosmanen wrote: > On Sat, May 06, 2000 at 03:06:26AM +0100, Nick Lamb wanted to say the following: >> NB None of this affects loading images, and you should NOT be >> creating more TIFFs, so hopefully right thinking people are quite >> unaffected apart from this build problem. > Eek. TIFF is very much alive in the print media world..! Just declaring it > sucky is not going to help a lot :| > I also heard TIFF is the only format you can supply with a "clipping path" > from photoshop that a DTP package supports. So you can define the image > outline from the paint program with a path, then say "This is the clipping > path for this image" and save it as TIFF. This would be neat for sodipodi, > sketch and whatnot.. any clue if we could do something similar or does > anyone know if something like this exists for other formats too? It would be > useful since the path will always be more accurate than some clipping object > you define in the vector program.. Photoshop, for instance, lets you save and image with clipping path to both TIFF and EPS, in addition to PSD, of course. The disadvantage with using EPS for this format is that the files tend to get prohibitively large (I suspect there is little or no compresison going on, and that it also encodes as ASCII). During my days working in prepress, we were actually told not to send TIFFs with clipping paths to the printers, but use EPS instead. The reason given was "greater precision". I'm not sure if this is correct or not, though. Anyway, being able to define a clipping path and save it from within GIMP would be extremely useful, even without CMYK support (the other big deal for print work), since you can at least use it on greyscale images. -- Joakim Ziegler - Helix Code webmaster - [EMAIL PROTECTED] FIX sysop - free software coder - FIDEL & Conglomerate developer http://www.avmaria.com/ - http://www.helixcode.com/
Re: Tiff changes?
On Sat, May 06, 2000 at 03:06:26AM +0100, Nick Lamb wanted to say the following: > NB None of this affects loading images, and you should NOT be > creating more TIFFs, so hopefully right thinking people are quite > unaffected apart from this build problem. Eek. TIFF is very much alive in the print media world..! Just declaring it sucky is not going to help a lot :| I also heard TIFF is the only format you can supply with a "clipping path" from photoshop that a DTP package supports. So you can define the image outline from the paint program with a path, then say "This is the clipping path for this image" and save it as TIFF. This would be neat for sodipodi, sketch and whatnot.. any clue if we could do something similar or does anyone know if something like this exists for other formats too? It would be useful since the path will always be more accurate than some clipping object you define in the vector program.. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Tiff changes?
Thus spoke Nick Lamb > > Have the libtiff requirements changed recently? 1.1.19 built fine. > > Yes, there has been a change to my use of libtiff, on the discovery > that recent versions have removed support for LZW. Can you tell me > which version of libtiff you have, so I can guage what to do next? Sure thing: libtiff.so.3.4 My RH 6.1+ boxes seem to be unaffected by this, and they have libtiff.so.3.5. > The problem is that we can't trivially detect at run-time which > CODECs are really present, TIFFFindCODEC was better than nothing, > but if it causes problems I'll remove it, because it wasn't really > The Right Thing (TM) in my opinion anyway. It appears this was an addition to the TIFF 3.5 library. I haven't upgraded my RH5.2 boxes for various reasons, most of which have nothing to do with Gimp. Eventually, I'll move to 6.2. > NB None of this affects loading images, and you should NOT be > creating more TIFFs, so hopefully right thinking people are quite > unaffected apart from this build problem. You lost me a little here. Why should I not be creating more TIFFs? -- Michael J. Hammel | Never argue with an idiot. They drag you down The Graphics Muse | to their level then beat you with experience. [EMAIL PROTECTED] | -- Dilbert http://www.graphics-muse.com
Re: Tiff changes?
On Fri, May 05, 2000 at 06:54:51PM -0600, Michael J. Hammel wrote: > /usr2/graphics/gimp/gimp-1.1/gimp-1.1.21/plug-ins/common/tiff.c:1237: > undefined reference to `TIFFFindCODEC' > > Have the libtiff requirements changed recently? 1.1.19 built fine. Yes, there has been a change to my use of libtiff, on the discovery that recent versions have removed support for LZW. Can you tell me which version of libtiff you have, so I can guage what to do next? The problem is that we can't trivially detect at run-time which CODECs are really present, TIFFFindCODEC was better than nothing, but if it causes problems I'll remove it, because it wasn't really The Right Thing (TM) in my opinion anyway. At worst, users will receive a strange, but intelligible message from the library telling them to choose a different CODEC, I think. NB None of this affects loading images, and you should NOT be creating more TIFFs, so hopefully right thinking people are quite unaffected apart from this build problem. Nick.
Tiff changes?
1.1.21 build on RH 5.2, with fairly updated graphics libs: gcc -g -O2 -Wall -o .libs/tiff tiff.o ../../libgimp/.libs/libgimpui.so -L/usr/local/gtk1.2/lib -L/usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm ../../libgimp/.libs/libgimp.so -lglib -lm -ltiff -L/usr/local/gtk1.2/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -Wl,--rpath -Wl,/usr/local/gimp-1.1/lib tiff.o: In function `save_image': /usr2/graphics/gimp/gimp-1.1/gimp-1.1.21/plug-ins/common/tiff.c:1237: undefined reference to `TIFFFindCODEC' Have the libtiff requirements changed recently? 1.1.19 built fine. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Everything should be made as simple as possible. But not simpler. -- Albert Einstein.
