DarkClown

My current workaround: getting rid of the overlay and changing the native object colour. Seems to work out.

So you are suggesting I should manually edit the source code of every icon SVG file I produced with AD to get it working in the field? That's a "creative" workaround ...

And, as you can see from my description - the file is the same ... but for the 3rd square (the one with the fx-overlay) WP simply uses a different SVG Icon with the same ID to display it ... (so the fork has never been part of the original file

Looks like i'm dealing with extended complexity... The problem only occurs from the second SVG Icon on I use in the WP Icon Box. Someone from the Elementor forum gave a good hint for the cause of the problem: The way I generated the SVG was basically using the same original picture and only changing the overlay FX colour to generate a different coloured SVG - So if the following derivatives of SVG icons uses the same "_Image1" coding this might lead to overwritten content ... but I don't fully get the cause of the problem.

I'm sorry, Walt ... Here it comes: AD Test4.svg

I attached the actual SVG file that displays wrong in the WP Elementor Widget in the post before. The more I dig deeper in this it seems to be a combination from what AD writes as SVG and a buggy interpretation of this SVG format from the widget. The different colour is not the problem - the "new" green" is taken from an SVG file I used in another Icon-Box on the same page (so the green is just taken from another SVG file and could as well be any other random colour). I will have to deal with the Elementor guys as well on the topic. The Affinity topic from my perspective is: why is the Exported SVG different, when an object uses an layered FX than with the native colour?

Well ... I export as SVG (and that should be vector format - not bitmap) - but if SVG can contain rasterized bitmap content as well I have to admit: Nope ... that's new ... but will explain things. In that case the problem could be related to the WP Elementor Widget that is not capable of handling bitmaps in SVG vector format the right way ... (Frankly spoken I'm a bit surprised that the overlay should come as bitmap - very unexpected when you work vector based and export in a vector format). I wonder if Illustrator exports overlay FX as bitmap as well - or is it an Affinity specific behaviour? ...

Hi Walt, It might be a combination from what my Wordpress Elementor Widget interprets from the SVG file and what AD produces. It's a fact that exporting an object with native color produces a different file than an object with a layer overlay colour. (And this is caused by AD!) - Unless overlay colours are a feature of the SVG format (what I don't think) I assume there is a bug in AD at least as well. This is what I generated in AD: Here are the layer settings: And this is what I get to see in Wordpress: (The "fork" is part of an Element I used in a different Icon Box before in wordpress) The only thing that is different in the third box is the colour overlay information ... this shouldn't result in a difference in the export format (SVG). Here's the original designer file: AD Test2.afdesign As I said - displayed properly by many other programs - but the SVG Format shouldn't make a difference between a native colour and an overlay colour. I exported selected objects without background. Cheers, Timo

It seems that exporting an object in SVG Format with native colour is not the same than exporting the same object in SVG with an overlay colour as a layer effect. At least browsers (Opera/Firefox) don't recognise the additional overlay colour from the layer effects - they still think the object has the native (original) colour. Nasty bug - took me a long time to figure out it's not a wordpress thumbnail handling issue but an original Affinity Designer file bug! Some programs display the files properly - so there must be some detail in the object description in the file format that is written different by AD Cheers, Timo.

Thanks! In my case it worked out fine (but I see the difficulties). I did not expect it to be called "Expand Stroke"

Is there a way in AD to convert a curve into a shape? And I don't mean to generate a new shape surrounded by the path but I want to convert the curve itself into a shape. (e.g. a 100px thick line with straight edges into a rectangular shape with a hight of 100px - generating a curve around the former path) Cheers, Timo

@Fixx: Regardless of the dpi, in 100% mode the pdf document should be displayed in max quality (only limited by jpg compression rate) - but it isn't. Attached my JPG and PDF Settings

Maybe we have to split the problems into different parts: 1) if the document in Publisher has a width of 420mm and is set up with 300dpi it requires 72,57dpi (explanation earlier in this thread) for a 1200 pixel output at original size. 100% (or original size) means 1 pixel in the document equals 1 pixel screen resolution (it doesn't go better - all the screen can display). The reality looks different. The pdf is significantly larger and far away from optimal quality: In the background there's the pdf reader displaying the 72dpi exported pdf - in the foreground you see the same picture as jpg with a width of 1200px displayed at 100% as well Maybe I'm making some kind of mistake here ... but currently I can't explain it. 2) I think I need to understand better how publisher works. My document is set up with Adobe RGB and 16 bit. This is the same color scheme my photography is saved (16Bit Adobe RGB as TIFF). This should enable publisher to work with high quality color resolution. The pictures are linked to the document. It seems in this case publisher ALWAYS exports the pdf with16bit color depth as well (no way to limit the pdf export to 8Bit in the setting). This again results in very high file size. The only way to prevent this is to change the color depth of the document to 8Bit. Now the exported pdf seems to have 8Bit as well. The smallest file size I can get (I've been fiddling around with many setting) still ist at least twice as big as the exported jpg. Pretty much overhead for a pdf! Another question in this context: When changing the document to sRGB and 8Bit will all the pictures "converted" instantly to this color format? And what happens to the pictures when I change the document setup back to Adobe RGB and 16 Bit? Will the original quality be maintained or is the 8Bit RGB data simply converted to 16Bit Adobe RGB - meaning I actually lost the quality of the original 16Bit? The problem increases when I follow Affinities "workaround" for CMYK output to already convert the document to CMYK to get a proper PDF output. Changing this back to RGB would mean CMYK colors will be re-converted and I'll never be able to get a proper RGB output again. My preferred solution is always to work with maximum 16Bit Adobe RGB (preferred even ProPhoto RGB) resolution and only convert the document into a CMYK or a 8Bit sRGB file as desired. As long as Publisher internally still works on max. res. with original data - I don't care for the color model on top as part of the document setup. But if a conversion is done and used afterwards based on the document setup it's a nightmare. On the other hand one has to understand this to know what happens for the pdf export. Certainly since the document setup has quite some influence on the output parameters since not everything seems to be covered in the pdf parameters you can choose in the pdf export dialog. Some setting seem to force a conversion (e.g. CMYK conversion) - other need to be done in the document setup (color bit depth). But all has an effect on the generated pdf document. Quite irritating. 3) And of course there's still the topic with the graphic that get's mirrored in a pdf printer when placed 90° rotated in the document. But I guess Affinity will blame that on a buggy pdf printer (despite the fact that it happens with more than one printer) Cheers, Timo

It's getting a bit weired now ... I checked my settings again. My jpg compression was the same for jpg and pdf (85%). What surely caused a problem was the setting "Convert Image color spaces" ... checking this causes additional 4.3 MB to the file size. (I thought it would reduce size) Embedding the ICC profile is insignificant, same with embedding fonts ... Strangely enough 100% in 72dpi is still 1/3 larger than the original 1200px jpg file but still really bad quality (bottom logo is 100% pdf - top is 100%jpg). And increasing the dpi will (of course improve quality but also) increase document dimensions in 100% view. So I got pfd size down to 680kb now - vs 330kb in JPG

@Lagarto: The document is a 13page calendar for print. But to advertise and promote it I need a preview in good quality (just a significant smaller resolution that it can't be used for print and a significant smaller filesize to be able to email it or have people download it)