fde101

Serif does not normally respond to feature requests. This should be expected. Also, this is hardly the only thread on this topic, including at least one going back to August 2018: Examples:

By default, the Affinity apps scale most shapes non-proportionally, but images and artistic text (that I can think of off-hand) scale proportionally by default, since stretching them is not likely to be the normal desired action. Using the shift modifier reverses whatever the default would be for the object(s) being scaled. You can change this behavior using the "Move Tool Aspect Constrain" option on the Tools preferences page.

The issue I had previously reported concerning the column rules section missing from the text frame panel is still present in the current beta. The section appears if I set the language explicitly to "English" (UK English) and restart the app. It disappears again if I set it back to "Default".

I agree there doesn't seem to be a way to do this with macros, but do note that you can do this directly in the various resize dialogs using expressions like "+=20%" - just in case you had missed that...

This has been discussed on other threads. The Windows version of the Affinity products are built using a toolkit from Microsoft which is not supported (by Microsoft) on ARM64, such that Serif would basically need to rewrite the application to get this working. They have indicated that they are evaluating options, but due to this limitation, I would not expect that version to be released any time soon, as it is not a simple matter of a recompile; this will take a lot of work.

Hi @TyNik, welcome to the forums! You can already do this using the Move tool. Holding down the command key (Mac - if you are on Windows check the status bar to see which key it is there) will normally scale around the center of the object. To change the point it scales around, turn on the Enable Transform Origin button on the context toolbar; this will show the transform origin in the center of the object, then you can drag it to the point you want to scale/shear/rotate around (for scale and shear need to hold down command).

You can set individual tab stops using the text ruler on a text box (View -> Text Ruler) or in the Tab Stops section of the Paragraph panel. Individual tab stops are listed in the list that covers most of the panel; the single width box at the top is used for the remaining tabs stops after the ones listed. On the text ruler, if a tab stop is shown stuck to the bottom of the ruler, it will stick to the left side of the text box when the box is scaled. If it is shown at the top of the text ruler, it will stick to the right side.

Yes, you can import plain-text, RTF and Word DOCX (not DOC) files. You can also copy/paste from other programs.

You can put text on a path by creating the path using the normal shape/pen tools, then with the path selected, clicking on it with the artistic text tool. The path itself will become invisible, but the text will follow it. You can tell when the mouse is over a valid path because the pointer will change to reflect creating the text on the path. The Affinity products do not yet have a mesh warp tool that keeps objects in an editable vector format, though Affinity Photo does have one that operates on raster layers, and this can be accessed from the Photo persona within Publisher if you have both programs installed and have started them both at least once. IDML import is partially implemented in the 1.8 beta which is currently underway. INDD and QXP import are not expected to happen. Normally you should be able to edit text imported from a PDF file, but if the text had operations applied to it which cannot be cleanly imported into the Affinity products (things they do not currently support natively) my guess would be that they were rasterized or converted to curves during import. If they are coming from PDF files, it may also be that the other program converted to curves when producing the PDF). If your text is converted to curves and is a single object (one entry on the layers panel), then it will have a single, shared appearance (fill/stroke/etc); if you want to color the letters individually, you will need to break it into multiple objects. To do that, right-click on the object and from the Geometry submenu select Separate Curves (you can also find the Geometry submenu in the Layers menu).

Not true. In Affinity Photo, this activates the color picker when using the brush tool. @walt.farrell, correct: it is control+option+LMB drag on the Mac. The Mac has four modifier keys instead of just three so none of the mouse chording is needed (that is how Serif seems to be compensating for Windows having one fewer modifier key to work with).

Some time back one of the betas did have a destructive mode for the cropping tool but they backed it out because it was causing problems of some kind. I don't think they are specifically opposed to this, probably just isn't a high priority at the moment to fix whatever was broken in the previous attempt.

While there is overlap between the formats, they target different market segments. PostScript is a page description language with a primary purpose of describing entire documents for a printer, though it has been adapted for use in transporting individual images (EPS) and for display use (DPS) prior to PDF coming along. SVG is designed for individual images and animations (something the Affinity products are not expected to support anytime soon if ever) and is targeted primarily at display use rather than print. I generally view Affinity Designer as catering to both market segments, so both are important: SVG for those creating graphics for the web and some types of UI work, and PDF for those designing for print. This means having features of both standards, some of which will require adaptation to be made to work in the other (or in some cases will simply need to be omitted).

What are the numbers below the characters in your screenshot?

@A_B_C, those ".sc" (small caps) glyphs may be characters that result from a combination of multiple code points, rather than not being mapped at all...? There are actually small caps code points in the unicode standard but they do not include the diacritical marks, so those characters would need to use the combining character code points to be represented. Not sure what tool you are using to view the font, but do you know if that property field would populate in that scenario? Details: https://en.wikipedia.org/wiki/Small_caps#Unicode https://en.wikipedia.org/wiki/Combining_character EDIT: I don't think that is what is happening here. The code points are actually in your screenshot, just below each letter in the big area on the left, and they are not the "small caps" code points even for the glyphs with the ".sc" in the name. Code point 0041 is the code point for a capital letter A, for example. Note also that the combined "AE" form is 00C6 for both of them - the "normal" and the "small caps" variant... these are mapped to code points, but for some reason your tool is not showing those mappings in the field you pointed to.

@Larryh, Affinity Designer is hardly minimalistic; not sure where you are getting that from or what you are comparing with. In some cases the tools are designed differently than in other software (as should be expected) and the functionality that other programs use multiple tools for are merged into a single tool which may have multiple modes of operation. It sounds like you need to spend a bit more time exploring the interface before trying to judge the program. SVG is only one standard for vector graphics, and is not the native or primary format that Designer targets. It is one option among many when exporting, and it would make no sense for Designer to limit its feature set to only those things which happen to be supported by this one format. The export persona allows configuration of repeatable exports from the same document and for exporting multiple sections of a document simultaneously, which can be very useful to some designers depending on their workflow and what they are trying to produce. For one-off exports, the options in the File menu are likely more convenient. I'm not sure what you are designing, but realize that design/illustration is a very large field with numerous people in different situations having different requirements; this program may not be tailored to exactly the type of work you are doing as it attempts to cover a lot of ground; search around the forum a bit and you will find people using it for everything from designing corporate ads and logos to software user interface design to creating card games. It is a powerful, professional application, but whether or not it is the best for your needs is something you will need to determine - no one program will be perfect for every user and project.

If/when scripting support is implemented, it might be nice to either be able to assign arbitrary toolbar icons to kick off user-provided scripts, or at least to offer a small number of "User-Defined" toolbar icons such that scripts could be configured for them if it is not practical to support addition of arbitrary ones to the set of available toolbar icons. For example, toolbar icons would be "User Script 1", "User Script 2", etc., then a user who wants these oddball commands could have a script to print the document and assign it to one of those icons. The rest of us could come up with more meaningful ways to leverage them. Something for everyone.

True, but I'm curious because I'm not 100% certain this means the font is invalid. Is it considered valid (in spite of being strange) for a program to use glyphs of a font which are not mapped to a valid code point? I could understand that in the case of an embedded subset of a font in a PDF for example (I would think a specific glyph would need to be referenced anyway to indicate which should be rendered?) but with a "normal" font source not sure how a program would be expected to find the glyph with no code point being mapped... InDesign does appear to have features for doing exactly that - identifying characters by glyph directly without going through the code point - so this might actually be technically valid: https://helpx.adobe.com/indesign/using/glyphs-special-characters.html

Just so I understand this clearly... the concern is that Publisher is treating invalid fonts as being invalid?

No problem!

@Ushur, You can do at least the first three already using the move tool after making your selection. To set the rotation point, turn on the "Enable Transform Origin" button on the context toolbar, then drag it to where you want the rotation to anchor. To use that same point to scale around, hold down the command key (on Mac - if you are using the other platform check the status bar for what key to use) while dragging one of the handles. Depending on what you mean by distortion, if your selection is not an entire layer try Layer -> Duplicate Layer to make it into one, then try either the Mesh Warp Tool or the Perspective Tool; one of those might do what you want?

Hi, @dmopell, welcome to the forum! By AFP do you mean Affinity Publisher? You posted this in a section of the forum for discussing Affinity Designer, which is a separate program. There are already a number of threads discussing footnote and endnote support for Publisher, and the short version is... eventually.

And spread the discussion out even more than it already is, making things even less likely to be noticed when they do get around to it since they will be all over the forum rather than consolidated in once place? Why not keep it together in one of the numerous threads that already exist on that topic? Personally, I am much more interested in support for SVG fonts than for variable fonts, but I do think both should be seriously considered and supported at some point. As has been repeated a few times, however, it seems this won't be happening particularly quickly, and I don't expect that piling additional discussion on top of what has already taken place is likely to change that.

I wonder how many times I might need to repeat this before it sinks in... Scripting languages which are built-in to the application cannot readily interact directly with other applications. Particularly in a sandboxed security environment such as MacOS apps from the app store. As a result, a 100% cross-platform implementation cannot support workflows that interconnect multiple applications - you must use a mechanism provided by the OS to support that, and those mechanisms by nature tend to be OS-specific. Refer to the post by @TonyB above for one possible option for dealing with this. It would provide an in-app scripting language which would be cross-platform for those scripts which do not require interaction with other apps, but allow the OS-provided scripting architecture to hook into it just enough to make it possible to interconnect multiple applications for those who have the need to do so. Sounds great in theory, but doesn't always pan out in practice. HTML, ECMAScript, CSS are supposed to be open standards to allow for consistent interpretation between browsers, but look at how many sites work well on one browser and not on another... and different operating systems and environments are by nature different. In many cases, something that is intended to work well on all of them is doomed to work poorly on all of them unless it is separately optimized for each one. Same thing with SQL code transported between database engines, etc.

Yes, technically the scripting architecture in MacOS is not limited to AppleScript and can support the use of other scripting languages at the OS level as long as a proper bridge is created for them. AppleScript is the most cleanly integrated one, but there are a few others around. I believe the same is true for WSH, where VBScript and JScript are the "bundled" options from what I am seeing.

I was being hypothetical: if the restriction were not in place concerning objects which are half-on the artboard, then this could be a problem, thus possibly the decision to make them behave as they do...