fde101

If I want to make presentations, I use presentation software. If I want to make videos, I use video software.

A workaround for this: instead of copying the text, create a character style from it. Then apply that character style to the other part of the text.

To my knowledge Serif has never indicated that they will ever implement this, so constantly begging for a timeframe is kind of pointless as it may never happen at all. Furthermore, this is a duplicate thread now many times over, and if I were Serif having to wade through all of these duplicates, I might be inclined to implement a policy of reducing the priority of any feature request for every duplicate thread that is created for that request, particularly as it violates the forum guidelines. In fact, according to those guidelines, this thread should technically be deleted... https://forum.affinity.serif.com/index.php?/forum/52-feature-requests-suggestions/ (emphasis mine) Also, you are clearly aware of those other threads, so you have no excuse for having duplicated them:

If you think about it, each "frame" of animation is basically a page in a multi-page document, which has the pages flipped automatically every X amount of time. As Serif seems intent on keeping support for adding multiple pages limited to Publisher at the moment, this feature might actually work better in the context of Publisher, by adding a checkbox when exporting a GIF causing each page to be treated as a separate frame of an animation (along with an option to specify the frame rate for playback). You would create a document with the required number of pages, then could switch to the Photo persona (assuming you also own Photo) to use the relevant tools to do the editing of the individual frames... Motion JPEG could then be handled in the same manner.

Both the .ico format (Windows) and .icns format (Mac) are designed to hold multiple versions of raster icons at different resolutions. In other words, I might have the same icon at 16x16, 32x32, 48x48 and 128x128 together in one file. As these icons would generally need to be maintained as a unit but still be optimized for each individual resolution, I would argue that a dedicated tool is most appropriate for working with these formats. Using a program like Designer to manage icons is more appropriate for vector icon formats, and for icons which will only be exported at a single resolution.

In that case you are looking for a product with a specific feature. This does not mean that products which do not have that feature do not qualify as professional or even semi-professional Desktop Publishing applications, and the context of my comment was in terms of a site that was generically reviewing applications of that nature, but disqualifying applications in such a way that made it sound like applications missing that feature were not professional DTP apps. This is not the case, as *most* professional DTP apps historically have NOT supported templates, at least not those that I've seen. If templates are required for you to get your work done, then you have a requirement beyond the application being a professional DTP app. I am not disqualifying that individual users may have non-standard or atypical requirements which some programs will support and others will not, but the way that particular site treats a feature like this as if it were essential to the nature of the application calls the legitimacy of the site into question. If the site had listed the review as being a review of desktop publishing applications that offer support for templates, that would be a different matter - they would be narrowing the field to a subset of desktop publishing applications which might be more suitable for some specific purpose or subset of users - but that is not what they were claiming.

There are several ways to look at this. Consider that checkboxes in general appear to the left of their labels. This means that we see whether or not a thing is turned on, before we know what the thing is, when reading from left to right. From that perspective, checkboxes in general violate your "principles of good UI design" yet how quickly would people start complaining if some company randomly decided to place them to the right side of their labels when every other app on the platform places them on the left? Why should they be on the right when they appear in a list, when they are on the left when they are not in a list? In what way is that consistent, and if it is not, then in what way does making this inconsistent manage to fit with the "principles of good UI design"? Note that I am NOT arguing that the checkboxes *should* be moved to the left - again, I personally don't care which side they are on - I'm simply pointing out that there are different opinions about what constitutes "good UI design" and that the principles you are advocating are not 100% in keeping with convention, which leaves some room for interpretation about which side they should really be on. I would not be opposed to that either, but I do feel like this is one thing that we could also simply chalk up to learning curve. If you want to live in the USA, learn to sit on the left side of a car to drive (unless you work for the post office...). If you want to hide layers in the Affinity products, look for the checkboxes on the right.

I suspect that many of those users are likely coming from the photo/illustration app world and leveraging the low cost of Publisher to get their feet wet in the DTP world, rather than coming from other DTP apps such as InDesign or QuarkXPress where the *only* layers they offer are what we are calling "global" layers here.

This would be a good argument for keeping the collapse/expand triangles and the thumbnails on the left (for a left-to-right reading order), not the visibility toggles. Of course, they already are on the left... I also agree that horizontal scrolling would be a good addition to the Layers panel, but I would point out that the checkboxes can stay locked in place on the right just as easily as on the left. We are more accustomed to seeing checkboxes on the left side of a list - if you have pull-down menu items which can be checked, the checkmarks show up on the left of the item name - personally, I don't really care if they are on the left or the right, as I rarely bother using them, but I do think there are valid arguments to be made in both "directions".

https://forum.affinity.serif.com/index.php?/forum/53-feedback-for-affinity-designer-on-desktop/

Wait, you mean... they do?!?!?!? 😇 I just pulled up the CTAN site and believe it or not they seem to be using a lot more icons than I remember them using last time I visited it. Given the nature of the site (and of TeX itself) the site seems reasonably appropriate to me. The TeX system can still be used quite effectively on a lot of older computer platforms which might not handle "modern" web browser standards particularly well, so keeping the site reasonably simple for such systems to parse may very well factor into the design...

Most people access web sites using the TCP/IP protocols, which were developed in the 70's, so a web site from the 90's is actually quite recent considering what you are going through in order to access it. Good choice. It is already a great program, just one which is not currently well-suited to your particular use case. Not in *all* other respects - no support for RTL or vertical languages, no global layers, questionable practices regarding the handling of global and spot colors, inadequate cross-reference support, virtually no interactive features (other than hyperlinks), no support for spreads of more than two pages, no support for custom slug areas (just a few pre-defined things that can be turned on or off), no support for variable or color fonts, ... ... ... Some users are much more heavily impacted by one or more of those things than by the lack of footnotes and endnotes.

Why not just leave them in a hidden layer?

Is there some reason you can't just do the scaling at print time by setting the "Fit Type" to "Fit to Printable"? Have you tried using GraphicConverter (if you are on the Mac) instead for things like this? While Affinity Photo is not likely the best choice for bulk printing of lots of photos like this... File -> New Batch Job Add Files Save into (destination folder) Save as (format) - enter "40cm" and "60cm" for size OK From there, if you are on a Mac and used a compatible file format, you can navigate to the destination folder in the Finder, select all, right click -> Open With -> Preview, and File -> Print. I would imagine there is some similar capability you could leverage on the other platform. Alternatively, if you happen to have Publisher as well... Create a new document with the correct page size and the same number of pages as you have images Add the required picture frame to the document's master page and in its properties (on the context toolbar) choose the appropriate scaling option (one on each side if using facing pages) File -> Place, navigate to and select the images, then place them in the frames on the pages File -> Print No need to scale the images - the frames will take care of it

Yes, if I use that tool in Inkscape, it works by adding a new object which is the shape of the filled area, and setting its fill color to match. If that shape were then cut out of the original, would that not in effect give you a shape builder tool? This is essentially a variation of the shape builder, which adds the area as a new shape on top instead of breaking the old one, and which sets the fill color in the same operation... so to implement this wouldn't be all that different from implementing the shape builder?