GNOME Bugzilla – Bug 131982
Add "Clipping path" functionality to paths
Last modified: 2009-08-03 15:28:01 UTC
For page layout work, at work we use (don't laugh) PageMaker. Me and the other guy recently learned that we could import raster images (saved as an eps file) w/transparency and have it display properly in PageMaker. We also learned that the eps file must have a clipping path. Basically, it's a path with a special designation as a 'clipping path' and everything inside the path will show, and everything outside the clipping path is transparent. There's a little rivalry at work because my colleage uses Photoshop while I use The Gimp. As it would be, PS could do a clipping path, but I couldn't see that Gimp could. In PS, you bring up the context menu with the paths menu up and designate which path will be the 'clipping path'. That's it. I don't know about the internals of the eps file, or if it's even a recognized spec in eps (but I'm gonna guess it is). Here's an eps image w/a clipped path made by Photoshop. http://epierce.freeshell.org/bugzilla/gohome.eps Feel free to ask me any other questions (I don't know much else though). Eric Pierce
If I understand this feature correctly, we could define these clipping paths (not to be confused with clipping groups mentioned in bug #51112) by doing the following: - converting the transparency to a selection (->Alpha to Selection) - converting the selection to a path - marking this path as a clipping path (this is the new feature) I don't know exactly how clipping paths should be defined. The EPS file that you linked to is unfortunately not very helpful, because this is a compressed EPS and it is not easy to read. It would be nice if you could create a smaller file (e.g. a very simple shape such as a single square), save it without compression and then attach it to this bug report using the link "Create a new attachment".
Well, now I see that clipping paths are a PostScript feature. So the best way to implement this feature would be to do it in the ps plug-in. It could be as simple as reserving a special name for the path and making sure that the plug-in saves it in the .eps file in the appropriate format. So I am re-assigning this bug to the ps plug-in. Although we could still do something in the user interface: there should be a way for the user to know that the feature exists. If we rely on a special name for the path, then the user should be aware of this. Does anyone have suggestions about how this information could be presented? Maybe some entry in the right-click menu for the paths, saying "Define as clipping path" that would rename this path? Is there a more elegant solution?
I don't see how the first two steps Raphael mentioned are related here. The bug reporter asked about a way to store paths (or vectors) in an EPS file. This sounds as if it should be implemented in the EPS plug-in. It might need some help from the core though. I guess we will have to add a path selection menu to libgimp.
The first two steps described in my first comment were just there to explain how the user could define a path that matches the border of the transparent area, because the clipping path is suppposed to describe that border. Once this path is defined (using that method or any other one), the user would have to designate that path as the clipping path. As I wrote above, this is the new feature that we need. The ability to save paths (any path, not just a clipping path) in PostScript files should probably go into a separate bug report.
If we had a paths menu useable from libgimp, we wouldn't need a change in the paths dialog. The user could choose the clipping path from the list of paths presented to her in the PS save dialog. Optionally there could be an entry labelled "Selection" that would cause the plug-in to create a path from the image's selection and store it as a clipping path.
Yes, that makes sense. Good suggestions.
Hi there, I once wrote a python-fu to save Gimp paths to Postscript files. It worked with the old style paths, tough, and I had not updated it to GIMP 2.0 paths. I am now with little spare time, and translating the GIMP to pt_BR in that time. My script is at <a href="http://hopey.nervo.org/~gwidion/gimp">http://hopey.nervo.org/~gwidion/gimp</a>, if someone wants to check how to build the postscript path. Otherwise, as soon as I finish translation, I will try to implement this one, and some other features in the ps plugin. Just building up to Sven's sugestion: maybe a radio selection with "create clipping path from: ( ) selection ( ) Active Path" could do the job.
Created attachment 23580 [details] Here's a simple square with a transparent border.
Damn... I messed up that file attachment (above). I think the file made it alright (same filesize). Just change the file extension to .eps. I'll try again. Can someone set bugzilla to accept eps files? I think a right click on path with a 'set (current path) as clipping path' or something like that would be appropriate. FYI, I don't think you can set more than one clipping path in PS.
Ok, let's try this again. On all comments in this bug report: s/eps/tif/ I don't know if this originally worked on an eps or not. But I know it works on a tif. I'll check the eps again at work. And here is a tif (no LZW) w/clipping a path. http://epierce.freeshell.org/bugzilla/clipping_path.tif It's a circle with transparency. The path designated as the clipped path is 'path 1'. Eric Pierce
Hmm? So... EPS or TIF? Because I will work on the EPS stuff soon - as I wil adrees the PS plug-in. Tiff's do not belong in my realm however. If you are saying EPS, here it is as it will be addressed, as I proposed in BUG 138583 : A clipping path will be generated to keep tottally trasparent areas of the image from showing up in a PS (or EPS) rendering: This way: in the merged image perform: gimp-selection-layer-alpha gimp-selection-to-path render said path in PS using it as clipping path. As you can see the funcitonality for rendering a GIMP path as clipping path would be included anyway, we just need to get a good way of putting it on the interface.
I've made up my mind (or maybe I was just smoking crack)... ;) A clipped path is savable by *both* tif & eps. I just verified it. Here are several sample tif/eps images with a clipped path. The image is a red circle w/a clipped path around the circle dropping out a white background to transparency. Note: not all images properly showed/printed transparency when printed with PageMaker 7 (see notes for each image). All the eps images are labeled 'clipping_path_<preview>_<encoding>.eps'. <preview> and <encoding> are the 2 main options when saving an eps in PS. 1. Printed correctly w/clipped path, but printed image is converted to black & white. Also looks black & white in PageMaker document. http://epierce.freeshell.org/bugzilla/clipping_path_1bit_ASCII.eps 2. Printed correctly w/clipped path. Worked correctly (i.e., circle is red and perimeter is transparent). http://epierce.freeshell.org/bugzilla/clipping_path_8bit_ASCII.eps 3. Printed correctly w/clipped path. Worked correctly (i.e., circle is red and perimeter is transparent). http://epierce.freeshell.org/bugzilla/clipping_path_8bit_BINARY.eps 4. DID NOT printed w/clipped path. http://epierce.freeshell.org/bugzilla/clipping_path_none_BINARY.eps 5. DID NOT printed w/clipped path. http://epierce.freeshell.org/bugzilla/clipping_path_none_ASCII.eps 6. The only tif example. I used default save settings in PS. Byte Order: IBM PC. No LZW. Works correctly. http://epierce.freeshell.org/bugzilla/clipping_path.tif Summary: If a preview isn't set when saving an eps, it doesn't work. Tif wasn't encumbered by this. Eric Pierce
For the record, clipping path are defined in this supplement to the TIFF specification: http://partners.adobe.com/public/developer/en/tiff/TIFFPM6.pdf
Fixed in rev. 22519 I have implemented this for TIF now. This should basically solve the problem at hand. Feel free to reopen the bug if support for this in EPS is essential. 2007-05-17 Simon Budig <simon@gimp.org> * plug-ins/common/tiff-load.c: Fix the order of the imported paths. 2007-05-17 Simon Budig <simon@gimp.org> * plug-ins/common/tiff-save.c: save the paths in the TIFF. Please test interoperability with other programs. Fixes bug #131982. * plug-ins/common/tiff-load.c: fix coordinate reading for negative coordinates.
Comment on attachment 23580 [details] Here's a simple square with a transparent border. Original description was too long for the soon-to-be-upgraded Bugzilla.