MmmMaarten
-
Posts
536 -
Joined
-
Last visited
Posts posted by MmmMaarten
-
-
-
16 hours ago, Bryan Rieger said:
I love how you fly everywhere in this world—past the cafe, the telephones and the toilets straight to exhibition stands! And you don't even have to taxi or gate your plane.
Yeah, it's magic! 😀
-
5 hours ago, MattP said:
What awesome work! Well done!
Thanks! 😀
-
Hi everybody,
Finally finished a new interactive exhibition map after working hard! All graphics are created with Affinity Designer and Wacom Tablet. With around 750 stands and lots of roads making it possible to create milions of unique routes (each stand to each stand), this was pretty intensive Designer work, next to the programming and animating!
BTW not really Designer-specific, but if you're interested; when requesting a route it even takes into account the actual traffic to calculate the fastest route on the fly!
Hope you guys like it! 😀
-
On 5/5/2021 at 9:15 AM, Gabe said:
This is because the origin is not fixed in an artboard based document, but determined my the leftmost (for X) and uppermost (for Y) artboards. How does this interfere with your workflow? Artboards are just containers, and 99% of the work is done inside an artboard, where objects you put inside them will always use the top left corner of that very same artboard as X,Y - 0,0
Hello Gabe,
Please read my previous posts, what you write was already there, so I refer you to those posts.
Asking me why I would like to use and trust absolutely positioning of artboards is kind of the other way around.
It's like a car dealer is asking you why you'd like to use the back door of your car when your back door is broken, and is saying; could you tell me why you're not entering via the front door that is working?!It should just work. But it doesn't. I'd appreciate it if you could mention it to the developers. Thanks!
-
9 hours ago, Gabe said:
Hi @wigglepixel,
This is expected. With Enable Transform Origin, the X and Y fields will operate on the control point. So, in your case, it's moving the centre of that artboard to 0. The canvas origin is determined by your artboard location, so when you move the artboards around you also move the (0,0) origin.
Hi @Gabe
Thanks for your response. I would expect that, when setting the control point that is in the center of an artboard to (0,0), the artboard moves to (-half artboard width, -half artboard height). But it's not doing that.
Designer is not moving the control point to (0,0) when entering these values, but is changing the coordinate system instead and than adjusts locations of all artboards accordingly, making the artboard to move and this and all other artboards to get different locations instead.
This also makes precise working with coordinates impossible, as the coordinate system and all artboards on it changes every time we move an artboard before the first one.
In the video you can see that I repeatedly set the control point of an artboard to the exact same value: (0, something). But instead of the artboard to remain on the same spot after once setting this location (of the control point), it is moving not only its location in numbers, but also the coordinate system and the view around each time I set it to the exact same location. So that's not what we might expect and I wouldn't categorize this as expected behaviour. To me this is like when wanting to move a couch we don't move the couch, but the whole house around it instead and than correct the position of all other furniture to keep it on the same spot.
Hope this makes sense and could get some love by the developers! 💓
-
Weird things were happening with positioning artboards before in earlier versions, but that was mostly about floating vs integer positioning numbers. But now it really seems completly off to me. Please see video below.
@Serif: IMO positioning an artboard is basic functionality we should be able to rely on. Any chance this could get fixed in the near future?
[edit] Please note this behaviour has to do with the 'Enable Transform Origin' mode being enabled, when turned off it works as expected. -
Graphics created in Affinity Designer and animated using Javascript and math to explore new interactive animation techniques.
Also having fun creating music meant to be tunes and exploring a fitting musical style for some projects! 😀 🎵🎹
-
18 minutes ago, Sean P said:
There is no specific reason I'm aware of, but we do risk breaking workflow for other users if we do this, as the SVG format is quite versatile.
Just to be clear that we don't have a misunderstanding; I'm not talking about middle spaces (inbetween spaces), but leading and trailing spaces of the layer names.
I can't think of a workflow of people using leading and trailing spaces we cannot see in the editor anyhow (definitely not the trailing spaces), but let's say there is a useful workflow to use them; could you guys please consider to add a setting to automatically strip them during entering (or when exporting) as these are error prone when programming with svg's and lots of layers and I don't see any way to spot issues with spaces now in the editor without clicking all hundred layers one by one, which does't only take a loooong time and is boring, but also is errror prone by itself, as it's active for changes again? Please consider this, it doesn't seem like a major change, but it makes a difference of hours of work here.Just a quick demo to illustrate this
This is a layername without a trailing space:
And this is a layername with a trailing space:
I don't know about other people, but for me it's pretty much impossible to spot, especially when having hundreds of layers in a file and inside groups all with different names. I can't spot the difference even when directly looking at it. But one of these names is wrong as the space got there by accident and is now messing up the workflow in svg.
-
12 minutes ago, Sean P said:
Hi wigglepixel,
As far as I can see the actual space is stripped away and replaced with a hyphen in the actual 'ID' entry that matters. If you've got a document that this is failing with on export then by all means please do attach it.
It was reported a while back that IDs were including spaces if the layer name contained a space, so it decided to change the space to a hyphen to stop the illegal ids. However we also retained the original layer name using 'serif:id' which is used on import back into Affinity so your layer names still contain spaces.
Thanks for your quick response. Ah, I believe you're right. I remember I've seen a hyphen along in the process. So probably I 'automatically' replaced the hyphen and forgot about it. Sorry for the inconvinience. So just changed the opening post.
There's still the thing about spaces in the layer names though. We cannot see them in the editor, so accidentely entered spaces in the layer names are difficult/not to spot in the editor, but are a pain in the resulting SVG when programming as the IDs suddenly are different (just found out the hard way with a few hundred layers here, where chances were higher that by accident a space was entered in some of these layers. These issues are very difficult/impossible to spot in the editor)
Is there a reason why leading and trailing spaces aren't trimmed from layernames inside Designer?
-
When having a space (at the end) of a layer name and exporting to svg, Designer doesn't trim the layername when setting it in the svg's id attribute. Resulting in an illegal (non-working) id.I don't believe pre- and postfix spaces will be ever usefull and especially while naming hundreds of layers a mistake by entering a non-wanting space there is made very quickly, but pretty much impossible to spot in the editor.
This results in different IDs in the svg output though, making the elements not be found by code, as these 'invisible' spaces are replaced by hyphens (which is great with inbetween spaces, but not with post- and prefix spaces).
Could Designer please always trim pre- and postfix spaces in layer names directly after entering them?
-
4 hours ago, Sean P said:
It was logged as an issue with development to be fixed.
thanks
-
On 10/14/2020 at 3:30 PM, Sean P said:
I will speak to development.
It's 5 months later now. What was the outcome?
-
Nice, I missed this one too, great addition!
-
@abra100pro To answer the other part of you question, about proportions;
This is also right. SVG stands for Scalable Vector Graphics. Meaning it is made to scale automatically to the size of a window in, for example, the Safari browser you mentioned.
So your export is completely fine, but the resulting svg is displayed in a brower window (or parent HTML element) that is bigger than your design, so it scales to 100% of your browser window / parent element automatically. You can see that when sizing your browserwindow; the svg scales along with it.
When you want a different size in the browser, you just need to know a little about styling with css or set the width and height attributes of the <svg> element in the svg file. Or look for the preserveAspectRatio attribute. But that's a whole different topic.
If you only use Safari or another browser just to test if your created svg is okay, you are fine. Everything, except for the font part, is okay in your output and is exactly as expected.
[edit] It's a little difficult for us to answer about 'parts are missing' part in your question as in the example you posted there are no parts missing.
But the only thing I can think of right now is that your design uses raster-graphics (so pixel-based graphics, instead of vector-graphics) next to / inside the vector graphics. If that's the case check your output settings under the 'More' button to be sure your raster graphics get exported too. But better in most cases: don't use raster graphics inside vector graphics if not needed. -
That's no quirk nor bug, but you're missing a font so it cannot display the text the same way.
You are exporting the text as editable text, instead of outlines (= curves of the created text). When exporting the text as text you also need to have the same font when displaying the svg, so to use in production environments you normally export the text 'flattened', so your texts as outlines (curves) . To do that: ctr-enter on the text object, or Layer --> Convert to curves. OR better, let Affinity do it automatically during export with 'Export text as curves' to keep the text editable in the design itself and only flatten the output.
File --> Export --> Choose SVG --> Click the 'More' button --> check 'Export text as curves'
If you really would like to keep the text editable in svg export than it all depends on where you use the Svg to know how to load the font. But 99% of the cases you don't need to edit the text when exported.
[edit] see below for answers to other parts of your question
-
On 3/5/2021 at 12:16 AM, walt.farrell said:
Just turn off View > View Mode > Clip to Canvas.
That's nice for viewing stuff in the editor (and thanks for the tip), but when objects are outside the canvas they don't get exported to files like svg.
Which is a problem when doing things like creating animations where things need to be outside the (svg) view(box) before they move unto the 'stage', which happens a lot in animations/interactives.
So for me the request to make it possible to have objects outside the canvas AND export them (perhaps with a checkbox to either clip or don't clip) still stands and would be highly appreciated!
So this:
is exported without the rect:
But also the following example, which is represented by some simple shapes here, but could be a complete character, like an animal or object sticking half 'in view' to be animated fully into view, would loose important parts of the figure during export, making it useless after export. Ofcourse we can work around that by putting stuff completely on the canvas and move it outside by code before animating, but it's far from an ideal workflow. Also it's not always possible to fit elements onto the canvas, as they might be bigger than the canvas to, for example, let them scroll by during animation.
-
When designing for interactives with text inside the exported svg, I was surprised to see that the alignment, as set to a text in Affinity, wasn't exported. The alignment was 'flattened' during export so it is always left-aligning.
Because of this, when setting the text with code in the created svg <text> element, it will not be aligned as set in the design, but always left-aligned. So we need to add extra, redundant, steps in code to add this 'text-anchor' rule to every text object that isn't left aligned and correct each position. Which is a pitty, as svg <text> elements have an alignment property, called 'text-anchor', which would do this automatically. But right now Affinity doesn't export the alignment to the 'text-anchor' css property (or inline svg attribute).
Please Serif, export text alignments with the alignment in tact, using the 'text-anchor' property, when exporting to svg so we don't need to align stuff with code afterwards!
(about text-anchor on mdn: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/text-anchor )
Thanks for considering this!
-
+1
Using svg interactively in browsers and/or using stylesheets on them we need to be able to add css class names to elemenets. Right now we have to do this manually every time after exporting (breaks the workflow and makes it difficult to re-export a changed design) or write extra code to change IDs into classes (which needs extra work and unneeded extra code for each project).
It would be nice and a lot easier if we could add these class names right within the layer names of these layers in Affinity (only the css class names, the rest we can do externally in other editors). So let's say our layer name is '#floorId.floor.floor1' in Affinity, that layer would then export in svg to an element with id="floorId" class="floor floor1"That way every user could use he's/hers own workflow by deciding which objects get a class/multiple classes and/or id. And we can also decide NOT to use IDs at all.
-
Yes! Copy as svg works now!! 😀
-
[edit] hmm... I just reacted with a +1 to give the option to export Affinity Symbols as SVG Symbols because of performance reasons. But my view on the peformance part has changed;
Not sure if things are improved in 2021 (guess not as svg isn't changed for many years, but perhaps the web rendering engines for svg have), but according to this old post, using SVG <symbol>s makes the SVG not faster, but even 50% slower in some cases as seen in a test: https://stackoverflow.com/questions/8604999/does-reusing-symbols-improve-svg-performance
Still think having the option to export Affinity Symbols to SVG Symbols would be a nice addition and very useful in some situations. Especially when a symbol has a lot of graphics inside that will be reused multiple times and not being animated. Than, for use in browsers, it would load a lot faster and doesn't need the peformance part that much.
But please, if this will be implemented in the future, make it an option instead of fixed export rule, so Affinity symbols will not always be exported as SVG symbols, but only when we ask for it, because of the above reason!
-
-
On 10/14/2020 at 3:30 PM, Sean P said:
I will speak to development.
Thanks
-
@Sean P thanks for the quick response. When I try it now, when opening an ai-file and cancelling the import, I see the issue again. On the files I test it now I don't see the same issue when not canceling during import, but I'm pretty shure I didn't cancel import before while having the same issue.
I'll keep an eye on it as I can't replicate the same issue without cancelling the import at this moment.
Interactive Exhibition Floor Plan with 2-Click Dynamic Route Animation
in Share your work
Posted
With collapsable legend, auto clustering markers when they would otherwise overlap and switchable marker groups with memory! 😀