Aleksandar Kovač

To be able to put multiple additional masters on a publication page is pure genius. (Look in Help for: 'To apply an additional master page to a publication page' in 'Applying master pages' article). This superbly useful feature has saved days of my time by now. Example: Put 10 instances of individual packaging master pages on a huge publication page next to each other, see it all at the same time, and then place graphic variables into master frames is gobsmacking. Moreover, using Data merge layout on that huge publication page and seeing the content move synchroniously and being populated automatically with nutritional data and other packaging related content using Data merge it is pure magic. Now, that 'but' part... Problem 1: User layout is not preserved context: Add several individual master pages to a huge publication page. Position them next to each other. Edit individual master spread dimensions. Click 'no' to 'Target pages differ in size to the master. Would you like to resize them to match?' And... problem: Ugh. Back on huge publication page your nice distribution of individual master pages is gone. Individual masters are moved to center. Stacked over each other. Must be moved back by hand. Locking individual master pages on the huge page does not work either. expected behaviour: Individual master pages placed on a huge publication page observe Transform X,Y position and Anchor Points as defined in huge publication page's Transform panel. That is why user defined them. Ignoring user's work is never cool. Zero/origin for dimensioning master page's spread is center. But, once placed on a publication page, individual master X and Y position and Transform Anchor Point can be defined. Why are they not observed and layout preserved? Problem 2: User column guides' settings are not preserved context: Define column guides on your huge publication page. They will help you layout additional multiple individual master pages. Alt-drag individual master page onto your huge publication page. And... problem: Where are my huge publication page's column guides? Deleted. Shucks. You have to make them again and they will work fine until one attempts applying additional master page. Why were column guides deleted in the first place? expected behaviour: Noli tangere ... column guides... meos! Leave my column guides alone. Deleting user data is never cool. Now, if huge publication page was applied e.g. huge master page with column guides, those master column guides would have been preserved. Are these issues a result of a bug or a feature? An example with instructions is attached... Additional masters issues.afpub

Thank you @Old Bruce for this workaround. I have done so and will see how it goes. I cannot find a reference for this behaviour except a case on Windows a few years ago. There, the problem was caused by certain PDF elements and the behaviour was accompanied by high CPU usage. Here this is not the case. This could still be a bug.

On all 1.10.5 Affinity betas, almost each time when I am closing the file with imported-placed images I get a warning: "At least one file is currently being opened. Please wait for files to load before quitting the application." Nothing is loading as far as I can see. And it never stops. Nothing untoward visible in the Activity monitor. Is it something others see, too? Or, am I embarassing myself again with a lapse of patience/punctiliousness/common sense/ and so forth... On mac OS Monterey 12.2.1 and Mac Mini M1.

@garrettm30 You are right. I was not patient enough. Preflight dictionary error disappears after a moment or two if I switch text language to "None". I will correct my post and go rest.

Yes, @garrettm30, the starting point is a bit of a conundrum. We do have to start from somewhere, and it is likely going to be an incorrect starting point. I vote for 'Prefer None' as well as application default (and no guessing shenenigans!) and of course ability to change that to a preferred language. To add to your proposals, improved documentation would help a lot already. Or, that Assistant notification thingy (the name escapes me) could be used to direct user attention to this. Or, my preference would be, just not engage spell checker until User defines language for some text. Logic here being 'I'd rather see no errors than irrelevant/wrong errors', and 'how dare you detect errors against None language based on misconstrued language variant, you cheeky software!' <- edit: see the following posts.

(did experiments with fresh eyes) Oh. I see. Oh... All of the language dictionaries are available all the time and utilized depending on Character's language definition and pertinent options used. That is exactly what I desired. How... unexpected (?) 😲. Then, the source of (my) confusion was: Language dropdown under 'Replace text while typing' in 'Preferences/Auto correct' is not following the convention established by the rest of the 'Preferences' panel. Every other dropdown element is used to set a preference. Dropdown here does not set any preference. It is only a shortcut to a specific list of custom auto-correction/text-expanding entries that are added to the language selected in the same dropdown. I.e. selection here does not matter while working. All of the entries are available if language needs it. If that is right,this is a bit 'on the edge' case for a dropdown. Some extra explanation could make it easier to understand, like this?: Actually, if on, AP auto-replaces only the entries listed here. Misspelt words will be underlined red. At least, this is what I am getting on Mac. 'Main menu/Text/Spelling/Check spelling while typing' is on, as is 'System preferences/Correct spelling automatically' +Croatian spelling dictionary is present and active system-wide. But, it does not show up here (it does show up for 'Typography language' and 'Typography script'). Maybe that dictionary is not up to the mark needed here... That leaves only awkwardly named 'None' list for my puny little language. Custom named list would be nice... ... To everyone, sorry for attempting to expound on this, entire official documentation on this topic is: "Use these options to control how auto-correction intelligently and automatically replaces or formats your art and frame text". The issue with Preflight 'Missing dictionary for language en-XX' still exists.

An old thread, but still very, very relevant. @thomaso condenses it very well: and... App should not assume OS or Affinity GUI languages have any relation or relevance to document's content and full separation here is justified. In language-specific markets, that assumption would mostly be wrong since UIs are seldomly translated in smaller languages; pro users prefer English UI (my observation); the content created is rarely in any of the languages Affinity offers, and frequently multi-language. Additional argument against assuming language on document level is that you have already given us the finest language control imaginable: on character level; which is also a part of Paragraph style's definiton. And finally, an assumption that is incorrect and malformed (e.g. en-PT, en-HR, en-DE, etc.) is worse than no assumption at all. I believe that ideally a new document should not be language-specific - 'None'. ... Now, that Auto-correction in Preferences is another thing completely. I cannot grasp where is it positioned in the context of language control and language tools. I believe that Auto-correction should be more like: WHEN 'French' THEN 'Auto-correct: French', and not a specific, application-level preference. Especially not one that does not (or does it?) have effect on other language settings in Publisher. ... For fun (and perhaps for an indication that something is broken) look what I see for spelling language: a separator 😆. So symbolic, considering my location, Croatia.

Yes, still like this.

'Edit in Publisher' and 'Edit in Photo' commands are not present in Designer's 'Export persona'. Quite often I am in a workflow where I am using Publisher layouting goodies and 'Edit in Designer' to setup slices for that work. Many times I need to pop back to Publisher to make a correction. Muscle memory hits 'Edit in Publisher' shortcut, but my ears are met with an error ping. Argh, click back to Designer persona, hit the shortcut again... Needy git aren't I? Still, this little stumble could be polished by adding these commands, no? Perhaps there is a deeper reason why these commands are not included in Export persona that I am not aware of. Well, they do exist in Pixel persona.

In short: Slices ought to be retained in Data-merge generated files and propagated in generated pages. Scenario: User sets up a work file using Publisher and Designer tools. Using Publisher, 'Data Merge' is essential to position and populate the file with variables. Using Designer, slices are set up in the same file so that, once data merge file is executed, files can be exported quickly. Data is imported, looks fine, user executes 'Data Merge manager' -> 'Generate'. Generated file looks fine at first but in Designer slices setup is gone! Replaced with UID-looking whole-page slice. Slices cannot be copy/pasted (not clear why, when it could save time in setups and dimensioning), User has to come up with workarounds. Workarounds will increase possibility of error and timewaste. Why is this a problem? This behaviour is detrimental for user since it: results in unnecessary loss of user data and time, requires generation of slices for each future data-merge generated file, requires potentially problematic workarounds. Expected behaviour: Slices are retained in data-merge generated file. This behaviour would be then coherent with retention of text-styles, master pages, swatches, preferences, and other user-set file characteristics and assets in data-merge generated files.

Thank you @Old Bruce. I have edited the post above to reflect that 'F' is not the default. I believed it was Affinity default since it was always there. Control + Command + F is my preference, too. Monterey (I believe) introduced system-wide Fn+F. Now this becomes even stranger. I wonder where did 'F' shortcut come from? 🤔 Not my preference, it was there on the first start of new betas (two of them!) and it remained there after pressing 'Reset'. Does anyone know if beta is pulling shortcuts from regular releases?

I can confirm. Attempting to export JPEG slices by clicking on 'Export slices' on 'Slices' palette crashes Designer. Crash manifests as spinning ball, Designer becomes completely unresponsive... and then only Force quit works. Observed on on Designer 1.10.4 and beta 1.10.5.1 The file in this case is multi-spread file with master pages, it has been to Publisher and back to Designer. How about others?

To add more references to this issue... In freshly downloaded 1.10.5.1 Betas, all Affinity for Mac products, before and after pressing 'Reset' shortcuts (just to be sure) I see the following: 3 'Toggle Full Screen' shortcuts; 2 of them the same, colliding with each other; Default shortcut 'F' (that is there before and after pressing 'Reset') does not work.

Issue: In (almost) Sir David Attenborough's voice with tropical birds in the background: One can see all kinds of exotics venturing about Affinity apps' custom shortkeys... Here is one rife with peculiarities. 'Toggle Full Screen' shortcut collides with... another 'Toggle Full Screen' shortcut... but that other one is unset... And for some reason – yet to be understood – doubled... Assigning 'Toggle Full Screen' shortcuts sometimes produces a brood of four or even five 'Toggle Full Screen' instances. All but one unset, colliding with each other in a desperate struggle for survival under a mildly irked eye of a nitpicky user... Present in all Affinity 1.10.4 series products. Expected behaviour: User assigns a 'Toggle Full Screen' keystroke and goes happy about toggling Full Screen on Affinity applications until he, she, et. al. falls righteously asleep, like a baby, delighted with so much Full Screen toggling done today.

@abarkalo, I also prefer seeing menu all the time. Did you try: 1) turning off this (lower) option in 'System preferences/Dock & Menu bar'?, 2) doubleclicking titlebar, or 3) Alt+hold click on that green circle window control? Please excuse me if I am missing the point with these.

Inkscape has truly beautiful vector nibs... 😉 Quick, responsive, configurable...

Thank you very much once more for testing this and the variants thereof. It seems Windows implementation is more consistent, although lack of conflict you describe is unexpected in my opinion. On Mac (assuming it is operating OK) when 'Ignore Modifier' is on any combination using 'ctrl' results with empty input box as described above and the shortcut assigned does not work. With that information, I believe this amounts to a bug for the following reasons: incongruity between platforms is detrimental for user, empty shortcut input box when assigning a shortcut with 'ctrl' when 'Ignore Modifier' is on is unexpected, nonfunctional, unclear effect of turning it on after assigning shortcuts while off, and vice versa, is it a mode, a helper while assigning shortcuts, or perhaps just a petulant message to all the modifier keys everywhere in the world? Dear Affinitios, Affinitesses et al., could you look into this 'Ignore Modifier' mistery, please? This potentially powerful option is underdocumented and (I believe) incoherent. Perhaps examples or tables or any other explanatory tools would be helpful to harness it's power. Thank you.

Thank you very much for checking. May I ask if, with 'Ignore Modifier' ON you are able to assign e.g. 'ctrl+A' to a command? As shown on the image in the first post, all I get is a seemingly empty input box with an X (delete shortcut) icon. I feel this could be a bug, but since I do not understand 'Ignore Modifier' fully, I cannot say for sure yet.

In Preferences/Keyboard shortcuts in all Affinity apps there is 'Ignore Modifier' checkbox. What does it actually do? Help documentation defines it: Ignore Modifier—Lets you create shortcuts using a single letter designation instead of using keyboard modifiers. A mystery. So, I tried to discern it's effect on one of the commands. In orange are marked results I find unexpected. With 'Ignore Modifier' ON 'P' is assigned as 'P'. (that is uppercase 'P'; why unexpected? Please see the reference below to @walt.farrell's experiment), 'shift+P' is assigned as '⇧P' (again, refer to Mr. Walt's experiment; furhermore, here, 'shift' is not considered a modifier?), '⌘+P' is assigned as 'P' (I guess ⌘ is ignored somehow, but to what purpose?), 'alt+P' is assigned as 'π' (I guess 'alt' is ignored, resulting in conventional π), 'ctrl+P' is assigned as empty (!) but with an option to remove it. (see image below, is this normal?). With 'Ignore Modifier' OFF 'P' is assigned as 'P'. (I understand this is something 'Ignore Modifier' should make possible but here it is, working fine with 'Ignore Modifier' OFF), 'shift+P' is assigned as '⇧P', '⌘+P' is assigned as '⌘P', 'alt+P' is assigned as '⌥P', 'ctrl+P' is assigned as '⌃P'. 'Fn' key is skipped here since I own Logitech keyboard, not Apple. Now, referring to Mr. @walt.farrell 's experiment where pressing key labelled 'P' with 'Ignore Modifier' ON assigns 'p' (lowercase P), while 'shift+P' assigns 'P' (uppercase P): In all things 'Affinity' I trust Mr. Walt first... So, is it possible that my shortcuts preferences file is borked? Or is there a finer idea underpinning 'Ignore Modifier' checkbox that my measly braincells fail to grasp? Am I alone in this?

Absolutely this!

Premise: Affinity products establish a GUI convention for users to discern color swatches using simple visual markers: Global colors: lower-right corner white triangle marker Spot colors: lower right corner dot mark marker Problem: ...and then this convention is forgotten. Except for Swatches palette, GUI does not allow User to see these markers to gain useful information whether the color applied is spot/global. Lack of this information contributes to... increased chance of user error when working with palettes where there are visually similar global/local or spot/process colors, color mixups, timewasting by clicking on the swatch in main bar to verify if correct swarch has been applied. timewasting by fixing swatches when/if they are not as expected, occasionally gnarly-fied creative flow, 'Shucks! Not again!' moments while on the phone with printing office... (All of the above contributes to worsening Weltschmertz, semi-superficial existential doubts, unhealthy cookie intake and cold, damp feet) Proposal: Use the above swatch markers consistently in Affinity products' GUI. Small and obvious example of consistent use of swatch markers is in the image below. This approach can and should, I believe, be applied throughout Affinity products.

Yes @thomaso, @walt.farrell is right, as usual . That 'fullstop' is zero-width space `<ZWSP>` displayed in tag style on Mac. Zero-width space is useful for digital type as in-the-text marker for formatting. It is one of the special characters available for selection on 'End characters:' dropdown. Thank you for your time and detailed look into this problem.

When editing a Paragraph style style via Edit style dialog a user can utilise a handy dropdown to choose a special character as End character for Initial words. Problem: once selected, this character is taken into account but it is not visible in the input box. When using Paragraph palette, special character is displayed as expected. See screenshot: side by side Edit style dialog vs Paragraph palette.

Check out these silly, silly rulers I have in Designer & Publisher (all 3 personas)... Everywhere and anywhere seems to be the exact same place! Oh! This seems to support certain philosophical ideas but it is not the condition I would want when working on a layout. I bet you can't guess how to get this! Actual area we are looking at is A4-ish, so it is not micro scale. What seems to trigger this? Rotating canvas 90 degrees and then moving mouse pointer, or zooming. Yup, rotating canvas will create a fine zone of singularity. I would expect rulers to merely switch X and Y axes, but the singularity. I'd never! Can you make your rulers silly, too? (Oh, to go back to euclidean universe just rotate the artboard back as it was.)

Hi @Lee D, in my case switching to small (or any other) size does not fix the issue. Re-opening the file does regenerate layer thumbnails.