Jump to content

Is it expected Designer behaviour to get a raster output when exporting to an SVG with an opacity of less than 100%?

Recommended Posts

I only found this strange effect after quite a bit of chin stroking and hair pulling with something that was confusing the heck out of me.

Workflow to re-create the issue (in Designer for Windows):
1. Create a new document containing an artboard (A5 landscape will be fine).
2. Draw a triangle that almost covers the whole artboard (don't go near the edges so you can see the effect better).
3. Give the triangle a Black stroke colour and a thick stroke width (16pt will be fine).
4. Go the the Export persona and export the artboard as "SVG (for web)".
5. View the exported SVG in a browser.

All should look just fine at this point.

6. Go back to the Draw persona.
7. Select the artboard layer - NOT the triangle layer (but it does the same thing either way).
8. Change the Opacity of that layer to 90% (this is the thing I did by accident that was producing the strange problem).
9. Go back the the Export persona and export the artboard as "SVG (for web)" again.
5. View the exported SVG in a browser.

The image now looks blurred. It's actually an SVG containing a raster of the triangle. You can prove this by editing the SVG in a text editor.

Is this expected behaviour?
(It took me ages to figure out what I'd done "wrong".)

I did a quick search and only found the following related issue:
* https://forum.affinity.serif.com/index.php?/topic/63257-texts-rasterized-when-exporting-to-pdf

Share this post

Link to post
Share on other sites

I have followed your your workflow and I am also getting this behaviour but if I change the export to SVG for Export it does not rasterise, I will speak to our QA team on Monday regarding this. 

Share this post

Link to post
Share on other sites

I have spoken to our QA team and this behaviour is correct for the SVG for web output as it is rasterised to ensure compatibility with the web browsers for the  opacity  settings and to keep the file size small

Share this post

Link to post
Share on other sites

Thanks to @DWright and @owenr for your help with this.

It sounds like AD is just doing what it's supposed to - and that's fine - but that still leaves me with a question.

While I still have some reading/experimentation to do regarding the Export Persona, how do I know which properties/features are "unsupported"? Not just for SVG but for PDF/EPS too.

I suppose could read the SVG/PDF/EPS specifications out there on the web but that's a heck of a lot of reading which, in the end, will only tell me what these file formats allow and doesn't tell me what AD can produce using them. (Also, there's no way to tell how the words/phrases in the specification material transpose to the AD nomenclature/functionality.)

It would be very useful if the help files could contain a simple list - for each format - saying which properties/features are unsupported. Even if full disclosure of all of the facts would be too complicated, a basic list would - at least - be a starting point for further research.

Share this post

Link to post
Share on other sites

I think a few different issues are getting mixed up a little here.

I've just done a little experiment with AD on Windows 10.
I recreated the workflow I gave above and made three exports from the Export Persona as "SVG (for export)":
* filled triangle with stroke;
* filled triangle;
* triangle with stroke only.
Each export produced an SVG with a rasterised image of the triangle.
It seems like AD is being consistent whether the shape has a fill or a stroke or both but I don't think that's what the issue is.

If I've understood you correctly, you are saying that AD should export the shape as a vector, rather than a raster. I would think that that is what most people would expect. The shape is a vector, SVG is a vector format, the shape should be exported as a vector.

However, I think what @DWright is saying is that, when using "SVG (for web)", AD automatically rasterises the shape because of the opacity setting and it does this so that web browsers will all show the image in the same way (I assume that it does this as not all web browsers show partial transparency of SVGs the same way). In a way, AD is taking the hassle out of displaying the exported SVG in a web page but, at the same time, the user is losing the ability to get exactly what they want because it will always be rasterised even if they don't want it to be. "SVG (for web)" is more of a: "Use this setting and all will look fine on the web even if you don't get what you were expecting". (Basically I was using the wrong export type in the first place and that brought about the problem I was having.)

As for "SVG (for export)", I think you are correct that AD should export the vector with an opacity. That's how most people would expect it to work, as it does in other software, and the SVG specification allows for opacity on most elements of the drawing. So in this case I agree. Exporting with "SVG (for export)" should export the shape as a vector with an opacity rather than rasterising it.

However, I disagree when you say that AD is not doing what it is supposed to do. Assuming that Serif have designed AD to rasterise all elements with an opacity of less than 100% then it's working as it is supposed to. It's maybe not working as most people might expect it to, but it's working how it's supposed to (if the assumption is correct). It's a small difference but worth pointing out. (On the other hand, if AD was not designed to rasterise then it, indeed, is not working how it's supposed to do. Only Serif can say.)

Anyway, in summary, I accept that "SVG (for web)" will rasterise all partially transparent elements but I don't think it should rasterise them under "SVG (for export)". Unless someone can convince me otherwise.

Share this post

Link to post
Share on other sites

For the experiments in my last post I did indeed give the entire artboard an opacity of less than 100%.

While AD does give consistent output across those cases - the content is always rasterised - I believe that this is either the wrong output or the output is not what the user would expect. There is no warning - or other method of the user knowing - that the entire artboard will be rasterised. The user is exporting as SVG and, while they could be aware that the SVG format can contain rasters, they would probably not expect that the entire drawing will be exported as a single raster. (This might be different for "SVG (for web)", as noted earlier, but for "SVG (for export)" the user will be expecting vector output so they can load it into other software that accepts vector input.)

It is my belief that a user with a drawing that consists entirely of vector elements will expect that, when exporting to a format that caters for vector elements, those vector elements will be exported as vectors and not be rasterised. The fact that this does not happen should, in my opinion, be documented either in the Help or, more preferably, in the UI. Draw with vectors -> Export as vectors -> Get vectors.

As for the results you are getting, I created a drawing with (a) a rectangle with both fill and stroke, (b) a circle with fill only, and (c) a line using the Pen tool with no fill. I got the same results as you: The circle and line were exported as vectors but the rectangle was exported as a raster. I totally agree that: this is not what I would expect; it is inconsistent; and I would suggest that this result shows that there is either a bug or AD is not performing as the user would expect it to.

The SVG specification accepts both fill and stroke opacity - https://www.w3.org/TR/SVG11/masking.html#ObjectAndGroupOpacityProperties - and, as far as I can tell, there is no mutual exclusivity between them. Basically, I agree with you on this point, it's a problem.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.