Friksel

Hello @Ben , In my opinion the way it's build now is very counterintuitive and not consistant. Like @evtonic3 I would expect the snapping and stretching of the starshape to work exactly like drawing a rectangle and a circle: stretch and snap to the bounds. I understand we can accomplish this by using the period-key, but it's pretty inefficient and way to much keystrokes and work we have to do each time we want a star to draw and hit the area bounds. In my opinion it should be the other way; shapes should always show the boundingbox and stretch on that. That's what I, and I believe a lot other designers, would expect to happen. Right now it's not only confusing, it's inefficient and therefore frustrating having to do this, which doesn't have to be that way in my opninion. Anyway, just as a reference I hereby reference to a discussion we were just having on another topic about this. I would say please change the behaviour to use the boundingbox, or add an optional keyboard stroke to make it use the boundingbox to stretch immediately while drawing the shape. Rightnow it's too much steps in my opinion and counterintuitive. Thanks!

But to not only complain and think in solutions instead; It would be great if it would be either work exactly with the bounding box, or we could have a button like ALT or whatever to do the bounding-box-switching immediatly. That would fit everybody's needs I'd say (if somebody really wants the behaviour like it is build now). Well, thanks again everybody for your buys help! I'll use the period-method for now!

So we pick a star, define exactly where we want the star to be on the document and use document-bounds-snapping, but the star doesn't stretch to the bounds... than we leave the mousebutton, have to switch to a bounding box with a period and have to resize the star again, but now it can snap to the bounds.... I don't think that makes sense at all and isn't really efficient or intuitive to me. But hey, at least it prevents a conversion to curves so it's a step closer

Yes, and I responded to it. You can see clearly on that image that the star is not hitting the bottom bounds, nor the left and right bounds. But guess we are talking in circles now. I know you are an intelligent guy so don't get me wrong and of coarse no offense at all. I guess I didn't explain myself well or we just dissagree on how an intuitive graphical interface should work for designers on this point. I was hoping there was something I was missing, but guess it's a choice Serif made. It seems like the choice made is made on logic in the background instead of intuiteve logic in a designer-perspective. I would have made a different choice, cause I think is a serious design flaw... and according to the other thread I'm obviously not the only one. Great to know drawing stars from the center is possible, thanks for the tip. But unfortunately drawing stars from the center doesn't solve this, because it's still impossible to snap the stars to the document bounds without converting it to curves first. Again, this is not me trying to troll, I think it's really a serious design flaw. That said, thanks for trying to help. At least now I know. Now I have to go to my meat... which is probably burning by now...

Exactly the same as drawing the star from top-left to bottom-right. Could be, but it's not stretching the shape with the boundingbox to the bounds of the document, but it should. I don't really care what the explanation is of base box and bounding box. It should work intuitively as how we would expect the interface to work in my opinion. I am a developer too, so I understand some things in the background could work differently, but that's not my business if I am a user and use the software as a designer, than it should work the best it can and consistant to other tools. The problem here is that other vector-tools draw shapes from the center, so you place a cursor on the 'canvas' and than make the star bigger by moving your mouse while holding the mousebutton. And that's the way the logic behind stars is. But Affinity tried to make that interface easier, which I really like, by drawing the shape topleft first and than let us stretch the shape to set the size. But they did it the wrong way and not worked it all the way through as what I think should be done. Again, in my opionion it should work exactly the same as drawing circles (fits the bounds), drawing rectangles (fits the bounds). No matter how technically difficult it is in the background. We should just not have to worry about those things. That's why we use graphical interfaces. Rightnow the star is not even in the center of the document...

Yes, I understand what you are explaining and I understand now that it's build like this. Thanks for your responses. I understand the technical background on how to draw the shape with its center point in the middle and all, but I don't agree with this to be the right and an intuitive interface for a vector drawing tool, because it's not only unintuitive, it's working differently than the rest of the interface. And I highly doubt other graphical software works like this. A boundingbox should ALWAYS fit a shape and drawing a shape that is able to stretch should ALWAYS hit the bounds of the container. Designers should never have to worry about technical stuff, how it's build and all. @Mithferion I understand, and after converting to curves we can stretch the hell out of the shape and fitting it to the bounds with no problem at all. So why such a strange interface at first?

It doesn't matter if the star is square or not, it stretches while drawing, so it should stretch to the document bounds. Look at the padding on the left, even if the star-shape wouldn't stretch it shouldn't be there. And the whole point of a boundingbox is that it always tightly fits the shape. That's why it's called a 'bounding'-box. It shouldn't matter how much points there are. If we switch to 5 points it shouldn't make the star smaller, but the boundingbox fit the star to let its boundingbox fit the document bounds on stretch and with that fit the star to the document bounds.

When drawing a star and snap to a squared document for some reason the star is having some padding and therefor not snapping to the document bounds. I don't see any reason why the star would not stretch up to the document bounds. I don't get it. Am I missing something here? star-size-and-position.mp4

No problem @Dan C. Thanks for your quick response and great to read it will be exported to <pattern> when available.

Hi, For a project I need to add a <pattern> fill to svg elements. It's no problem generating them by code withJavascript, but it would be a lot faster if there is a way to create these patterns from the Designer-editor. Is there a way to create vector-patterns in Designer that export to a <pattern> element on svg export? Thanks!

Yes, that would be my choice as well. As an option. Like this: I don't know where I put it (can't find it on the forum at the moment), but it would be very welcome to be able to add css-classnames inside the layernames, just like illustrator can. Right now everytime in Javascript I have to write code to look for elements by ID and than add classes to them. It would be a much better workflow to add the classnames for every element directly inside Designer. So if your layername is '#header' it translate to a svg-element with id="header' If your layername is '.toggle' it generates a svg-element with no ID, but a class: class="toggle" Or a mixture of multiple classes or id and class(es), so if you name your layer '#header.main-header.visible' you get a svg-layer with: id="header" class="main-header visible" I'd say layers without an ID starting with # or a class starting with . (dot) in the name doesn't get a classname nor an ID. That way we are also able to have layernames in our Affinity files without them being exported to svg. Only if we need a layername to be exported, we add a '#' in front of the layername and if we need to add classes we add classes to it in a chaining way.

You're right. I seem to have missed that one.

It could be some software is 'abusing' meta-data of the jpeg to store things like this, but it's definitely nothing the jpeg format itself is capable of or designed for. Nor is the metadata. Jpeg can only store one layer of pixels so it would be a very odd choice to use for things like this if even possible. That's why formats like PSD exist in the first place.

As far as I know this should just work, I never seen this go wrong so far and I don't believe there is a setting for it. But I might be wrong

@Alinoyan It would help if you inform us if you're working on Windows or Mac

@Poziomka It's impossible to include a clipping path inside a jpg or a tiff. They cannot contain any vector data.

I don't know about color fonts, but I expect variable fonts will be great for webdevelopment, because they make font files a lot smaller if you need more variations, making websites loading a lot faster and being able to animate the fonts. My 2 cts

Wow, they made some great decisions back then: - The vote was 5-4 in favor of Y-down. --> ffiew... if this was decided the other way it would be browser hell; everything else in browsers is y down - the hope was that browsers would implement SVG Basic instead of SVG Full. However, Mozilla implemented the whole specification. And then other browser vendors followed. --> thanks to this we can now make the web great!

No, this is still not fixed. The algorithm for converting to curves just isn't right in Designer and when exporting to svg with stroke set to inner or outer it automatically converts the strokes to curves. The latter is nececary, because software like browsers are not able to replicate inner and outer strokes, so Affinity needs to convert it to outlines. So the cleanest way to output your graphic is to create the outlines yourself and fix the mistakes the Designer algorithm made, or set stroke to center.

That last one is so alive and yet so still! I like it!

Thanks a lot for responding guys. Yesterday I was pretty busy and just couldn't have this on top of that, so that was the reason I opened this thread because I figured I am probably not the only one facing this issue and I'd rather ask about it instead of being annoyed about it everytime But in no means I thought Affinity is programming this forum and put time to fix something in the forum. I agree completely all the time should go to the products instead (especially Designer I'd say). That said, I'm glad @GabrielM responded that they informed the forum-creator about it. Would be great to work with quotes and stuff without this enters-aren't-working-anymore issue. I feel pretty stuck in a small room when that happens @SrPx Thanks for the tip about shift+enter. I use it a lot on websites and in software like Word and I believe in Designer too. So I probably tried shift+enter to avoid the problem. But next time it happens I'll try again @Wosven Yes, I think it happens with me when quoting. I also move quotes around with the move-icon on the top left. Maybe that has something to do with it. I didn't use smilies on the last post where it happened, so I don't believe that was 'my' issue. @GabrielM The 'source' button is indeed only visible for you moderators, not for us. It mostly isn't such a great idea to let visitors enter code. Although I agree that I would have it open everytime to see what's going on to fix my own post

Damn... even ctrl-V for pasting is not even working on some spots in the editor. crazy

Hi, Last week and now I noticed it is taking forever to write a post with quotes in it: I don't know why, but everytime it happens I am not allowed to use line-feeds (enters) in the text, which is pretty annoying and makes it almost impossible to post something with quotes in it. This wasn't happening before and nothing changed on my system (all other websites and software are working great and there's nothing wrong with my keyboard. When this happens (linefeeds/enters not working) it's pretty impossible to post on the forum. Anybody having the same problems? Something changed on the forum? Any advise on what to avoid to stop the 'enters' to stop functioning? Thanks!

If you select the artboard tool you can draw the artboard wherever you want by clicking and dragging. If you already have an artboard and want to change the size: select the artboard tool, select the artboard in the layers panel and than you can move/scale the boundaries of the artboard (blue lines with blue dots on the corners) in the viewport.

You can use svgo yourself to optimize the outputs of Affinity; by commandline or by adding an svgo-loader to webpack. That's actually a lot better than if Affinity would include it in the software, because there are an enormous amount of settings and (everyday changing) plugins available for svgo and you would like to set all the settings the way you want it. There is no setting that fits all/everybody. So if Affinity would like to add it to the export, which I doubt, they should at least make it possible to use the svgo config file where you can make all settings yourself, otherwise they would have to change the exporter forever everytime svgo changes and a new plugin comes out. I would advise you to use (or learn) webpack, search for the svgo-package and the svgo-loader. Webpack even has a watcher which allowes you to keep track of svg-changes yourself. So everytime your svg changes (got saved) webpack automatically compresses it via svgo. And together with the 'continues' mode in Affinity Designer Export Persona everything is completely automated. Every change you make in your design will automatically 'rendered' to svg and webpack will automatically compress your svg directly. What else can you whish for! But I'm afraid that's a bit technical and you need other tools, like npm too. So if you're not that into that maybe that's not the way to go for you. Then the alternative is to use the link you provided. That's actually not SVGO, but a website that is using the svgo commandline-tool under the hood for you to give you some graphical interface. But svgo is a 'commandline'tool, running in npm and got a lot more settings. About compatibility: I don't know what you mean by 'compatibility' with svgo tool, but svg is svg. Most svg out there is version 1.1, so they are (or should be) all compatible. There's nothing more to it than that for compatibility. Affinity's svg is completely compatible with svg, so the tool youo refer to can open the Affinity svg's perfectly fine. If you don't get what you want or svgo is destorying your layout, then you have set the wrong compression settings in svgo. Not all settings are right for every job. Those compression settings are changing your svg and sometimes that brakes your layout. To use the settings you have to know a little more about the technical format of svg I'm afraid, or just try out all settings per file and see what works for you per layout.