Jump to content
You must now use your email address to sign in [click for more info] ×

dkx888

Members
  • Posts

    16
  • Joined

  • Last visited

Everything posted by dkx888

  1. It's not about beeing a SVG editor, but exporting SVG's based on simple groundrules should be standard. Like in AI, Sketch, etc.., those are also not svg editors but they are doing their job well. I hope Affinity does take this issue seriously, because the exported svg results are just not usable for a couple of use cases / areas.
  2. There is a wide range of needed optimizations of the svg export in Affinity Designer. I am just listening the most important (buggy) ones for now: The svg tag has the width and height property as percental values, this can cause multiple (positioning / scaling) issues for the web usage (I am a Web Developer, 12+ years) while rendering the svg appropriate and the values are often differently in different browsers for the usage of early access in the DOM, the CSSOM and even for JS. That's why most SVG Exports usually use precise attribute values, e.g. instead of the current export <svg width="100%" height="100%" viewBox="0 0 596 842" ... it needs to be exported as <svg width="596" height="842" viewBox="0 0 596 842" ... AD exports the path's, etc. with inline styles (style="...") instead of the acutal svg properties (e.g. fill="...", stroke="...", font-style="...", etc.). Therefore it's currently hard to override those values outside the svg and even for dynamic JS manipulations / effects The id's of exported elements have the layer's names, therefore there are sometimes problems (e.g. <g id="ArtBö--ard11" serif:id="ArtBö &lt;ard1">) with special characters (including spaces, etc.), especially when trying to access them, sometimes they even brake things. They should be removed from the final svg export entirely (some of the special characters aren't w3c valid for id's anyway). By the way, the exported serif:id="..." makes the svg way bigger in size then it should be (bad loading times on the web), it makes a huge differences when it comes to complex svg's Other export tools / competitor tools do it as explained above and there are no problems. If there is some more detailed technical information needed then let me know.
  3. *thumbs-up* I would really appreciate that as well, because I am also interested in developing plugins for affinity (currently I was thinking about creating a dynamic clothing plugin for characters). JS would be my favorite language as well, but I would be also happy with any other language (except Java).
  4. Hello, as a Designer & Dev (Game & Web) I usually need SVG's quiet often, I usually need to run those SVG's through a Converter (SVG => to Meshes). But now the Problem beginns, for example, if I use curves with brushes on them, then AD converts those brushes to simple images only (I looked through the exported code of the svgs). This is really bad news for me, Illustrator doesn't do that, Illustrator actually converts those brushes (even complex ones) entirely to SVG valid data. Is there a plan to improve the AD SVG Export Options anytime soon to make this work? If this isn't on the AD Roadmap anytime soon, is there a alternative way to do it then (e.g. Vectorizing those Brush Curves)? I am also missing vectorization of curves and other objects in AD in general, that would help out by quiet a lot. [EDIT:] Seems like most AD Brushes are more or less Images (not the simple standard brushes), what makes it impossible to export it as valid SVG Data / Vectors, except if AD has some smart vectorization features in the future. Why are even Image Brushes allowed in AD? It's the opposite concept of a Vector Application, just wondering. Kind regards, DK
  5. Thanks a lot! I don't know why I overlooked the "Show Lines in Points" Option, I was there a couple of times :D But about the font-size on Web in AD, it's strictly confusing, now a days you actually do design Web Layouts in 192dpi+, because of Retina / High DPI Devices, so the font-size behaviour is kinda confusing to me now as it is. On Illustrator it doesn't matter which DPI you have on a Webdesign Layout, the units stay constantly correct there. So I am not entirely sure why AD went this way, probably because you do have the Export Persona to switch between 1x, 2x, 3x, ... Image Exports anyway, a bit confusing to me :) And if you actually look at the official W3C Specs (about CSS), e.g. 12px are 12px as Output, no matter if you have a 72dpi or a 450dpi device, AD went the wrong way about this part. There should be at least a option to change this behavior, even if the Export Persona has those High DPI Image Exports available. I also have to Export the Document as an PDF for review and presentation purposes (multiple times after those reviews), in this case the presentation would look less sharp as well if I have the Document settings on 72dpi (even if I change the PDF Export DPI Settings to a higher value, or am I mistaken?).
  6. Thanks for your Input Alfred. I wanted the border width in px globally for all new AD documents as you mentioned. But i haven't even found a temporary option to change the border width unit to px, is it somewhere hidden? About the font-size problem, you are right, the Problem only appears when you start with a print document and change the document settings to "web" afterwards, seems to me like a AD Bug?
  7. Hello, is it possible to change the border line width format to px instead of pt in the AD Settings (globally)? It can be really annoying to move the slider only in pt format, for now i have to type in the px units manually every time. I wont ever need pt in Webdesign, at least not in my case. The other problem is the font size, I've changed the AD Font-Size Setting to px (globally), but the incremental font size shown in px (font window) is really bad for webdesign, e.g. at the moment the AD Standards are: 20.8px, 25px, 29.2px, 33.3px, etc. That's just wrong, espacially because you don't have any px decimals in Webdesign (they kind of work, but still aren't correctly / fully supported on all devices down to the present day). The only acceptable formats on the web are px, percentages, em (and optionally rem) units. P.S. Love AD with every day more and more, just missing a few functions here and there as the one mentioned above.
  8. There is actually a simple solution to this problem (it was driving me crazy for quiet some time as well until i've found this option). Simply select the group or text frame or whatever, further below the right bottom anchor point (e.g. for resizing, etc.) there is another anchor point, select this one instead and resize it to your liking, that's it :) I've also uploaded a screenshot (see attachment), because it's not that obvious. I also couldn't find any tutorial about this issue on any AD Tutorials, etc., I also couldn't find it in the AD Docs, I wished AD could mention it somewhere, that would be very helpful to everyone who is new to AD.
  9. Thanks a lot Meb, I'll keep an eye on it until it's released :)
  10. Hello, I am working professionally on many projects with AI every day, but I am really missing the relative alignment feature of aligning a object or more objects relatively to another object. On AI when I select multiple objects (like squares), then keep the "Alt" Key pressed and click on one of the objects then i can start aligning relatively to it (the clicked object will be the "main object", every other object gets aligned to this one). I haven't found this feature anywhere in AD. Is this feature on your roadmap or is it already implemented in a different way? It's one of the features that i am really missing, at the moment I have to stick to AI (sadly).
×
×
  • Create New...

Important Information

Terms of Use | 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.