Jump to content

Search the Community

Showing results for tags 'svg export'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • Report a Bug in Affinity Publisher
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 16 results

  1. With Designer 1.8.6 on macOS 10.14.6, when I open an SVG file and then try to export it as PDF, the application completely crashes. Steps to reproduce: - open attached SVG file - go to File / Export - select the "PDF" tab in the export dialog - the application crashes I have verified the SVG and found it to be a valid SVG file. I have some other SVG images (generated from the same source) where the same behavior can be observed. eILCD example - LDPE injection moulding parts model.svg
  2. I use Affinity Designer to create files that I export – using "SVG (for export)" – for other apps, such as Cricut Design Space. The problem is that the Affinity Designer SVG export contains scientific e notation values like: <g id="topback" transform="matrix(-1,-1.22465e-16,1.22465e-16,-1,854.039,695.404)"> that other apps, specifically Design Space, chokes on. Trying to import that object into DS results in unusable, malformed objects. Sometimes I can "fix" it by editing the SVG file from the above, to: <g id="topback" transform="matrix(0,1,1,0,854.039,695.404)"> resetting the transform matrix, but it doesn't work for all objects, I haven't dug into how to map the space transforms properly, and I'm trying to avoid learning/doing that because this step is a huge pain. Based on a bunch of SVG parsers, the files are technically valid, and Affinity can re-import the SVGs, but I need them to work with the other apps. But this issue doesn't happen all the time and I can't figure out exactly what causes it to occur in the first place. Nor can I figure out how to fix it. I've tried deleting the offending object and re-creating them, but the new objects are affected exactly as the one it's replacing Any ideas would be very helpful. THANK YOU!
  3. Hi, So i tried exporting a illustration into figma, but the layers just don't align, i will share my original view and the export view, can anybody help me out i am running on a time frame here PS. the PNG comes out A-OK Regards -Noobie37-letter.svg the PNG view SVG view
  4. When creating a normal rectangle in Designer and exporting to svg the result is as expected: <rect x="240" y="380" width="740" height="60" style="fill:rgb(96,240,103);"/> But when we set the rectangle to have rounded corners, or use the rounded rectangle tool instead, the svg-exporter now suddenly converts the rectangle to a (much longer) path-element: <path d="M980,290C980,273.443 966.557,260 950,260L270,260C253.443,260 240,273.443 240,290C240,306.557 253.443,320 270,320L950,320C966.557,320 980,306.557 980,290Z" style="fill:rgb(96,240,103);"/> BTW It doesn't matter if 'flatten transforms' is enabled or disabled in the exporter, I didn't converted the rectangle to curves and I found the same behaviour using the latest Designer beta-version ( That's not what I would expect and is causing problems in projects here, because since the rectangle now is converted into a path this prevents Javascript to get (or dynamically set!!) the properties that came with these basic shapes on purpose, like x, y, width and height, but also the rounded corner-radius itself. This is what I would expect instead: SVG knows about rounded rectangles; they are just rectangles but with two additional attributes added: rx and ry for the rounded corner-radius x and y. So in this case this is what I would expect: <rect x="240" y="260" rx="30" ry="30" width="740" height="60" style="fill:rgb(96,240,103);"/> I might be missing something here, but I searched everywhere and couldn't find a way to output to just rounded rectangles instead of paths in the svg-exporter. For a project I'm working on right now I had to remove all roundings from all rectangles in the Designer file (so had to change the layout to something we don't want) just to output svg <rect> elements instead of paths. And than after the exporting we need to add the cx and cy attributes to all rect-elements manually in a code editor after (each!!) Designer svg-export we do... So every time the design changes even a little bit, we need to redo this all over again or manually copy and paste only selections from the new svg-file to our working svg-file. As you might understand that's not really efficient, causes mistakes/errors pretty easily, takes a lot of time (and money!!) we rather use on designing, animating and programming and is pretty frustrating. For interactive/animation use we really need to have rectangles as outputs if we use rectangles in Designer, also on rounded rectangles. If we use rectangles by design, we'd like to have them in the output too. Otherwise we would have converted them to curves instead. With rectangles as output we can set/animate width, height, x, y etc dynamically, and even the rounding-radius of the <rect> by Javascript. But with paths that's much more complicated and makes everything overly complex, which is totally unnecesary and results in too much code or less performant results. Basically the above counts for all basic shapes in Designer that are supported in SVG: if there are svg elements that match the basic Designer shape, please export them to those elements instead of converting them to paths. There is a reason for existence for all basic shapes in svg: they have special properties we need. And their names like <rect> are much more symantic too. Next to this, as you can see in the example, exporting to paths instead result most, if not all, of the time in much larger svg-files and we try to keep our files as small as possible for fast loading and performance, especially for use on mobile devices / internet. Keep in mind the above example only shows just one rectangle. This counts up pretty fast with having more shapes in the design. Bottomline: Please export basic shapes in svg to basic svg shapes! If we'd like to have paths, we can always convert them to curves instead before exporting to svg. Thanks!!
  5. Hello, I am a previous photoshopper and switched to AP and AD. I am fairly new to vector images and wanted to know why, when I export an af design file,(in AP or AD) I created like my logo, why does it export as an HTML document?
  6. When I export a design in the SVG format and open it in another vector program the size is different. I need the design to be the same size as the size I created in Affinity Designer. I opened the SVG file in AI, Corel, Inkscape, Cricut Design Space and Silhouette Studio. In all the software the design is not the same size as I created in Affinity Designer. Am I using the wrong settings?
  7. Suggestions moved here It's a little much to split into different items and I also need my time to do my job, so I write them in one post. The list is definitely not all, but a lot of other things I posted on the forums already. It would be great if somebody would pick them up and fix em! Guess I'm hoping for a miracle. PROBLEMS IN SVG EXPORTS Bug: Fillcolor doesn't get exported to svg when opacity is set to 0: When an object has opacity set to 0 the svg exporter doesn't export the fill color, but fill: none. That's wrong. We didn't want to clear the fill, we set the opacity to 0. But we still need to be able to readout the fill-color by Javascript, as meant by the designer. Issue: GUI doesn't give any indication of values with decimals. That's especially a problem when using values like 0.0001. The editor just shows 0% and that's not right, it's above 0% This is not only misleading and giving the wrong information in the GUI (causing mistakes and confusion), everytime we need to check if a value is really 0% we have to click it and enter the value again, because there is no way to view the REAL value in the software, not even on a tooltip or something. We need to be able to enter values with decimals, because of another bug in Designer where the fillcolor doesn't get exported to svg when the opacity is set to 0%, so we have to fill in strange values here like 0.0001% just to have the fillcolor exported. Bug: Don't know when or why, but sometimes the transformpanel of a group is disabled. Bug: When exporting closed objects like a circle or a rectangle to svg the element got stroke-properties that are only relevant for rendering when a path is open Obviously a stroke-linejoin doesn't make any sense on a circle or a rectangle (and other svg shapes which are always closed). This is causing too much data in the output file, making the file loading longer in browsers which is important to us!! We do everything to keep our files as small as possible, and use software like svgo to compress svg, but these kind of things are impossible to filter out with tools like svgo. Bug: After rasterizing an image layer suddenly Affinity adds a clip-path to the svg-export which is completely unncecary, changes hyrarchie, makes the file overly complex and large and matters for performance When placing a raster image inside an Affinity file and don't rasterize the image layer, so export the image-layer as is, Affinity exports the image to svg using the <use> element with <defs> which is great and works as expected. But when we first rasterize the image-layer into being a pixel-layer, suddenly Affinity creates a completely different output structure in the svg file. Now, for no reason, Affinity adds a clip-path to the image which doesn't do anything, because it's set to the bounds of the image, so is completely useless and we don't want that clip-path. It makes the export file a mess, it influences performance, filesize, hierarchy and structure of the export causing all kind of problems and confusion when using the svg export programatically by Javascript and css. Which is totally unnececary; it should have the exact same export as when not rasterizing the layer. EXPORT PERSONA Bug: The 'Continues' watcher in the export persona (which is a great feature btw) doesn't refresh the files when the name of a layer is changed.Changing the name of a layer causes a new ID in the svg output, therefore it should update the outputfiles (at least when using files like svg), because when using the svg files together with Javascript and css those ID-values are needed and needs to be up to date. Now we have to manually save all svg's after changing a layer name. Bug: Sometimes the 'Continues' watchter of the export persona goes crazy and suddenly triggers tens to hundreds of updates directly after each other, eventhough there's no need to. Everytime this happens a webpack workflow here, with watchers watching if svgs are changed to compress them and copy them to a working folder are being triggerd tens to hundreds of times in a second too, which is obviously not what we want, 'cause it slows everything down and refreshes way to much so everytime this happens we have to wait for all those redundant refreshes to finish. It's almost like Affinity collected a bunch of changes and goes through them one by one in delay or something. Bug: Don't know why or when, but the 'Continues' watcher in the export persona sometimes goes out of sync. So it doesn't update the outputs anymore. But maybe this is the same bug as it not refreshing when a layername changes? Bug(?): When moving an artboard whith a slice connected to it, I would expect the slice to move with the artboard, but it's not Bug: A lot of times it's impossible to fit a slice to an artboard. Even if the artboard got integer values for width and height. BOOLEAN OPERATORS Bugs: Sometimes boolean operations don't work anymore since the last update (1.6.123) I don't know why and when this exactly happens, but before this update there weren't this much problems with the boolean tools. Since this update I already had a lot of times where the boolean operators just didn't work how they are supposed to. Things like not wrong results when merging paths, like suddenly paths aren't really merged, but contains holes like as if it's suddenly became a compound path, which doesn't make sense and worked before.
  8. Hi, when I export a text alined to a circle as SVG, every time I import it to Video Scribe the line is not correctly positioned. Could you please look at the files? Thanks a lot. Wofür du bezahlt wirst 2.afdesign Wofür du bezahlt wirst 2.svg
  9. Rightnow exporting to SVG has all styles inline on all seperate svg-elements. And elements don't have classes or IDs. Using SVGs on web and making interactive animations on a daily basis this way it's impossible to animate elements and use external stylesheets without having to manually add classes and IDs to each element and remlve all inline styling in a text-editor after each export. I don't like to say it, but that makes this workflow impossible to use. Having to stick to inline styling inside the SVGs is another problem: - These days inline-styling is a big nono and validators throw penalties if inline styline is being used. The preferred way is internal style department, or use with external stylesheets. - A lot of layouts use the same styling on multiple elements. With inline styling all these styles got copied for all elements, resulting in a way larger SVG file then needed because of a lot of repetitive redundant data. This can easely be avoided by adding classes to the SVG elements and having one style-rule inside the general section for each different style. That makes the export a lot more efficient and makes it easier for developers like me to just copy the generated styles and move them to an external stylesheet if needed. - When styling is in the general <style> tag inside the SVG, a developer only have to change 1 stylerule if something needs to be changed instead of having to change all objects having all the same inline-styles - Because there are no classes nor IDs added to elements, we are unable to animate the elements with javascript, or again, we have to add IDs to all elements we want to animate each time after an export... A little bit like the Adobe Illustrator advanced settings offer, but that could even be improved to keep the SVG output as small as possible: My suggestion would be to add this to the SVG exporter settings: - A checkbox to add IDs to SVG elements where the layer-name starts with an asterix ('#'), followed by the name of the layer/curve. That way we can decide wich elements get IDs so we can address these elements later with Javascript to animate and so on. And with this we also prevent adding IDs to all elements in the SVG (resulting in a large SVG file with a lot of unused, redundant IDs). And when no # is add to any layer, no IDs are being written to the SVG. So full control here I'd say. - An option to choose one of the following for the SVG Export: - Use inline styles - Put styling inside <style> tag (recommended - mostly resulting in smaller files and less redundancy) (Perhaps to be complete even a: - Put styling inside svg attributes (but not my taste ) ) When a user picks 'Put styling inside <style> tag' the elements get a class attached with the styling in the general <style> tag inside the svg. Long story short: for real / advanced usage of SVG on the web for web development, interactivity and animations (by css and javascript), these options are indespensable! It would be very much appreciated if Affinity developers could look into this! Thanks a lot!
  10. Hi guys, There are some problems when exporting as SVG, when using "Selection without background" Basically, the stage height and width most of the times don't match the height/width of the graphics, instead, one extra pixel is being added. For example if a graphic has 30x40, the stage of the exported svg will be 31x41. Also, another issue with SVG, is that most of the times I can't change the stage dimensions. I even tried changing the stage dimensions for svg icons downloaded from flaticon, and it's the same problem, nothing happens most of the times. Thanks, Chris
  11. Hi there, Since a recent version when I export a file as SVG, the group name will be different in the svg than it was in the .afdesign file. For example, I have a group that is called "showroom-062". When exported the group name (that shows up as id in the SVG) is "showroom.-062". Since I need this for adding interactivity to the SVG on my website this is rather annoying. For now I can just search and replace it in the SVG but I would rather have it be it correct on export. Can you please fix this? Thank you!
  12. Something has changed on SVG export from version 1.4.0 to 1.4.2 now I can't import SVG from "Anime Studio 11" Reference to Rasterize..
  13. I am working in AD and I need my file to be able to be opened in AI. I saw somewhere that svg is best if you have clipping masks. So I tried all and it the file gets rasterized weird and is not usable at all, and I get the Clipping will be lost on roundtrip to Tiny message. What blows my mind is that Inkscape gives me the file intact along with all the clipping masks and everything! Any clue anyone?
  14. I'm trying to export a simple shape I made in Affinity Designer to an SVG file. The shape is composed from two very simple Bezier curves. However, the curve representation in the output SVG does not preserve the simplicity I made in Affinity Designer, and instead add way too many unnecessary points along the path. While this does not affect the visualization of the curve, it makes it inefficient for drawing in real-time (specifically, I convert the SVG code to Objective C and render it in real-time). Is there a setting that forces the SVG export to keep the same Bezier representation I made with Affinity Designer, or is this a bug in Affinity Designer? Thanks! P.S. I can send the file and the SVG file by email, if you need it for investigation of the problem.
  15. When exporting svg graphics, it appears that objects with a blending mode (tested with multiply and color burn) are just dropped from the file without warning or explanation. Or am I missing something? Untitled.svg Untitled.afdesign
  16. When I export with SVG, sometimes simple pen lines with only 2 nodes don't export. Does anyone know why? If I edit the pen line's pressure, then the pen line will show up on export under SVG.
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.