Ben

That is exactly why we use the circle approach. You can also mix up shapes (such as the star, cog and polygon) - and they will follow the same rotation centre if the base boxes match. This would not be possible if we expanded the shape fully into the base box. Bear in mind these are dynamic shapes. A lot of other apps just give you clip art. Once placed, there is no control over the shape. We have opted to keep dynamic shapes live - and part of that involves being able to preserve the centre of rotation and logical radius while adjusting the parameters.

Hi, @Friksel I appreciate that you don't agree with how we've done things, but they were done this way for very thought out reasons. As has been shown - we've tried to define things in terms of circles so that when the number of points changes the shape is still centred. For your usage that might not be what you expect, but you can cycle through to get the Bounding Box, and then scale that as you see fit. The importance of using a circle is that of keeping true proportions, and centre of rotation. If I drag out the box while holding Shift - I get a 1:1 base box. If the shape was not based on the internal circle of this base box, then I cannot achieve a 1:1 proportioned star. It would always be stretched within the base box. It's not just the star - we have a number of shapes based on a circle: Polygon, Cog, Pie, Crescent, Double Star, etc. The logic is the same for all of them. In short - you can do what you want, but it requires you to cycle to the kind of box you want. You can get true bounding boxes, and you can scale and position based on that. Converting to curves also gives you a true bounding box, but you lose the dynamic shape. We won't be changing the current logic. If it wasn't done this way - what would be the intuitive way of creating 1:1 proportioned dynamic shapes??

Thanks for raising this issue - we have closed it as "by design".

Yeah - loading 1.7 files back into 1.6 is not guaranteed to work, and we won't support it. We can't retrospectively change 1.6 to accommodate newer files from 1.7. Of course, a 1.7 file should load/import back into another 1.7 Affinity app.

Of course the position of a handle affects the shape of a bezier curve - and that is precisely the point. But, as I've tried to explain, the properties of a bezier mean that the length of the handle required to form common arcs does not fall into neat grid positions. So, if you always work to grid, you are never going to get true arcs. Some of the reasons..... I think you mean all but one of the reasons. You might also want to read again - the snap to grid feature is currently available in Publisher, and will be in Designer and Photo as soon as they Beta. Think that might have already been said. And thanks for calling my efforts tedious. I had hoped that these features might be useful, and offer something not found in other apps. Anyone that understands beziers and wants to use them for more precise construction should be able to appreciate these features.

@AndyQ Read back through this thread - I'm not going to repeat all the explanations as to why every example given to me for matching handle lengths and angles, aside from specifically putting a handle on a grid position for that one use case, has been shown to be achievable with the new features and do not require snapping to specific grid points, and that the new features mean you are not tied to just using the grid size or axis directions.

I wasn't being pedantic, and I wasn't overruled. You'll also see that I repeatedly asked for the specific use case to justify the feature - but that took an age to come. I added the feature (in the end) because the people shouting for it could not see that what they were asking for was provided in a more elegant way, and as I tried to explain at length, it doesn't play well with all our other features. Of course, we have explained at some length that if people then chose to turn all the features it will hamper usability, but we give people what they think they want.... then they can figure it out for themselves. The reason that some things are "commonplace" features is that they are just copied, lazily, from other sources - there is no thinking outside the box to see if there might just be a better way. We are trying to innovate, not replicate. ...and calling people names isn't going to encourage them to do anything.

I'm sorry - there's nothing we can rescue from this file. Can I ask what set up you have? Are you saving to an internal hard drive, Cloud storage folder, USB storage or network share? Did you also get any warnings or errors the previous time you saved the file? Thanks.

Ok, IDML... but INDD and AI files?

One other note - the link to the afdesign loader library earlier in this thread - don't bother. They are not even 1% of the way there to understanding the file format, and will never be able to keep up with changes if they are trying to reverse engineer the data.

I might just step in again.... It would be a MASSIVE undertaking to document our file format. A small number of companies have been legally compelled to do such a thing due to their market share. The majority of other companies do not do this. Firstly, our file format is always changing as we add new features and refine existing ones. Secondly, our file format is already huge. It is also more complex than common formats, for reason of speed and data size. I really don't want to say too much more, because it won't benefit anyone to give partial information. Users that keep stating that other companies open source their file format are generally only thinking about PSD (which is very poorly documented), and even that does not properly document all editable features (some features are still black-boxed). Other editable file formats, such as Illustrator, InDesign, Quark, etc, etc, are not publicly documented. All other documented file formats that tend to be open source or public formats are intermediate or end formats - PNG, JPEG, PDF. These are not editable formats and do not preserve editable features. Access to thumbnails is a different issue to full access to the internal workings of the format. This is something that may get considered in future. So, to put this to bed. Do not expect us to document the Affinity file format any time soon. And, if that is a problem, go ask Adobe for a copy of the Illustrator file format, then come back to us. I'd also say that anyone who is so paranoid that they don't use afdesign files for storing their editable documents, are really missing the point of using Affinity altogether. Not sure how we can convince you...

This looks like a bug to do with fills on text frames. I'm guessing you don't see these problems with fills on other objects?

As for the "floaty nodes" bug - if anyone can provide an example document, I'll look into it.

It's not a mesh fill. It's still a linear fill, but has correction points for when the fill has become skewed/sheared by its parent object - so the two additional points only pick up the gradient end colours. If you drag out a new linear fill, you get the conventional single line. If you then shear the object, you will see that the linear fill is still conforming to its object, and you will now get the shearing handles on the fill. This is a (new) unique Affinity feature, and allows you to put a linear fill on an object and non-uniformly scale or shear it while preserving the fill qualities. If the fill was still based on a 2D line, it would walk or distort relative to its parent object. Not good for scaling objects or symbols.

Right now, you could try reducing your layer count by combining vector objects into single curve layers. Do it using the boolean ops, don't create a live compound.