I am having trouble exporting my SVG as a PostScript file. Basically, it changes some parts of the image and fills them with black.
Actually this file exhibits several problems, some of which I fixed, some are unfixable, and some may be fixable but not fixed yet.
- The black parts ARE black yet use transparency, but PS does not
support transparency, so they become opaque. Never use transparency if you are going to export to PS. It"s very easy to fix this however: select one of the transparent objects on the camel; switch to the Dropper tool (F7); make sure it"s in the "pick visible color without alpha" mode; click on that same object. That will pick the visible color and assign it back to the object, but this time without transparency. Repeat for all transparent objects.
And why not convert automatically the transparent areas to a bitmap when exporting a PS? We can't always does the "Dropper tool trick" with complex transparencies. This is the way Freehand and Illustrator does it.
On 4/22/05, MoNKi <lsmonki-basura@...637...> wrote:
And why not convert automatically the transparent areas to a bitmap when exporting a PS? We can't always does the "Dropper tool trick" with complex transparencies. This is the way Freehand and Illustrator does it.
1 Because when I export PS, I want to get PS, not an embedded bitmap. I am supposed to know the capabilities of PS and create my design accordingly. If I really want a bitmap in PS, I want to create and embed it myself with full control over resolution, colors, etc. An _unexpected_ embedded bitmap often means the PS file has become simply unusable.
2 Because PS is a dead end format, not worth putting lots of resources into. Better spend the same resources on supporting PDF with real transparency.
bulia byak wrote:
On 4/22/05, MoNKi <lsmonki-basura@...637...> wrote:
And why not convert automatically the transparent areas to a bitmap when exporting a PS? We can't always does the "Dropper tool trick" with complex transparencies. This is the way Freehand and Illustrator does it.
1 Because when I export PS, I want to get PS, not an embedded bitmap. I am supposed to know the capabilities of PS and create my design accordingly. If I really want a bitmap in PS, I want to create and embed it myself with full control over resolution, colors, etc. An _unexpected_ embedded bitmap often means the PS file has become simply unusable.
2 Because PS is a dead end format, not worth putting lots of resources into. Better spend the same resources on supporting PDF with real transparency.
1. When I export a PS, I want a PS too, but if this PS dosn't support all svg features, at least I want an aproximation of it. I don't suggest a full "bitmapped" PS, only bitmaps instead of transparent areas and this bitmaps inside clipping paths, this clipping path should be the original transparent object path, and a warning telling you something like this on save time: "Warning: PS files don't support transparency, this transparency will be interpreted as bitmaps", and then a dialog asking you the bitmap resolution. There is no need to ask for colors, etc... the colors should be the same as if it supported transparency. This way semi transparent shadows could be added and exported to PS, EPS, ... Or add special effects to vector shapes, like bevels, blurs, ... saving this parts as bitmaps and the rest as vectors.**
2. EPS files aren't as dead and also has this problem.
Is only an opinion. The users shouldn't have to know the capabilities of PS because usually they are artist, not programmers. They do a design, and then export it as EPS, svg, png... without knowing all the formats in the world.
On 4/22/05, MoNKi <lsmonki-basura@...637...> wrote:
- When I export a PS, I want a PS too, but if this PS dosn't support
all svg features, at least I want an aproximation of it. I don't suggest a full "bitmapped" PS, only bitmaps instead of transparent areas and this bitmaps inside clipping paths
This makes little sense - if some part of EPS is not vector, it's as bad as if the whole file was bitmap. Moreover the seams between the vector and bitmap parts will look ugly (I'm speaking from experience, as I've seen such PS files produced by other programs).
- EPS files aren't as dead and also has this problem.
EPS are still used for simple graphics such as TeX figures, but these normally don't require transparency, so EPS works fine in these cases. If you're trying to use a format which is simply not appropriate for your graphic, you have only yourself to blame.
Is only an opinion. The users shouldn't have to know the capabilities of PS because usually they are artist, not programmers. They do a design, and then export it as EPS, svg, png... without knowing all the formats in the world.
An artist need not know the capabilities of EPS, you're right. However neither the artist need to know about the existence of EPS at all. The artist has got a tool whose native format (SVG) is perfectly adequate for everything that the tool is capable of. If the artist wants to move his/her art to another tool and that tool does not support SVG, blame that tool, not us. SVG is an open standard supported by most decent software these days.
Anyway, this is not to say that I'm in principle against this. If someone wants to implement embedding bitmaps into PS/EPS, please proceed. I'll gladly accept this feature into Inkscape so long as it's optional. I just don't want to spend my own time working on it.
Other possibility is create the "non transparent" colors automatically:
Get the transparent object and make intersections with all objects below it. Get this intersections and fill them with the "sum" color.
Possible problems: - When more than one object is transparent (Shouldn't be a big problem) - When a bitmap is below the transparent object: A new bitmap is created with the colors changed using the transparent object as clipping path. - When there are gradients: You should create an object with every gradient step, and then use this objects to do the intersections.
MoNKi wrote:
Is only an opinion. The users shouldn't have to know the capabilities of PS because usually they are artist, not programmers. They do a design, and then export it as EPS, svg, png... without knowing all the formats in the world.
*sigh* I know. Several times I had to collect a bunch of logos from various sponsors which were to be embedded into a PS file for high-resolution output. Half the people sent me jpegs of what originally was obviously done in some vector program. When I asked them that I wanted an EPS they would send me something created by opening the jpeg in Photoshop and saving it "as EPS". I ended up rebuilding several logos.
I think an artists dosn't have to be programmers, but they should know their tools. That includes basic knowledge about file formats and their capabilities. Someone who doesn't know the difference between a bitmap and a vector graphic shouldn't do computer-based design.
--Daniel
On Tue, Apr 26, 2005 at 05:42:30PM +0200, Daniel Haude wrote:
I think an artists dosn't have to be programmers, but they should know their tools. That includes basic knowledge about file formats and their capabilities. Someone who doesn't know the difference between a bitmap and a vector graphic shouldn't do computer-based design.
Yup, that's like a woodworker that doesn't know the difference between hardwoods and softwoods, or a painter that doesn't know the difference between oil paints and water paints. ;-)
Like different kinds of woods and paints, each graphics file format has its own unique strengths, weaknesses, and quirks. Some file formats are very flexible and can be used for a variety of purposes, others will have more specific limitations.
Bryce
participants (4)
-
Bryce Harrington -
bulia byak -
Daniel Haude -
MoNKi