RyanSeo

I haven't in the software setup I am using right now, but I did disable/unbind all shortcuts when testing things out, simply to minimize possible points of failure when testing stuff before reporting this bug/unwanted behavior. Whatever causes it, all the keybinds that can usually be triggered with CTRL+ALT as a substitute for AltGr are blocked by it. Thank you for getting back to me and trying, I didn't read it until today due to easter, but I do appreciate it. If you do manage to replicate it logging it with the devs (maybe as low to mid priority) might be worth it. I personally think using AltGr instead of CTRL+ALT is suboptimal, but it's good enough to get work done. The main concern is that I don't think this is limited to the (admittedly relatively rare) EURkey keyboard layout. As an example I thought if the substitution of CTRL+ALT would not work for other preinstalled keyboard layouts, and the issue is the same here. With the german qwertz keyboard layout that is most commonly used there, the "@" is typed as AltGr+Q and the € sign as AltGr+E. Almost every german I have ever seen uses CTRL+ALT instead of AltGr though. Neither of these keybinds work in Affinity publisher 2 with the normal german qwertz keyboard layout (when I try it at least), so I fear this issue might affect a larger portion of the userbase than just those using somewhat rarer layouts. Other than that, let me just say thank you very much again for the response.

Minor update: As it turns out, using AltGr (the right sided alt key) the keybinds work, making me suspect the mode toggled by CTRL is actually the cause. I have opened a bugreport ticket [here]. In the meantime, using the right hand alt key is a less than ideal, but acceptable solution. Just wanted to share in the unlikely case someone stumbles upon this thread with the same issue at some point.

I use a ANSI (qwerty) keyboard, but type in multiple languages, most of which are european, so I use the EURkey keyboard layout by Steffen Brüntjen to type the language specific letters occasionally needed. As an example to type the german Umlauts (ä,ü,ö) you would use the keybind "CTRL+ALT+A/U/O" or "AltGr + A/U/O". In Affinity Publisher 2, when typing in a Text Frame or Artistic Text Frame, the same keybinds with "CTRL+ALT" do not produce the desired characters, instead no input is read by the program. Using "AltGr" does produce the desired characters in the Text Frames. Interestingly if I go to Edit -> Preferences -> Auto-Correct and type in the "Replace" or "With" input fields, the program behaves as expected with both input methods, meaning that it can read the inputs normally. The problem can repeatedly be reproduced on new files. Technical details: Windows 10 Home 64 bit, Version 21H1 OS build 19043.1526 Ryzen 5 5600X processor 16 GB RAM Radeon RX 6800 XT Graphics card Issue persists with and without hardware acceleration enabled No relevant background software that may intercept the keystrokes other than the OS Recipe: Have ANSI (qwerty) Keyboard (Issue supposedly appears on other keyboards too) Have EURkey keyboard layout installed and selected Open Affinity Publisher 2 Create new Project Create a text or artistitc text frame Type in it Try to insert special characters with the CTRL+ALT+Character binding Unverified personal assumtions regarding the issue: The only other program where I have seen similar behavior in the past was in Joplin, a notetaking software. In there the issue existed because the keybindings were already preoccupied by the program, and had to be unbound in the settings. After unbinding it worked as intended. Since in Affinity Publisher 2 only one of the relevant keybindings seems to be preoccupied with another keybind ( CTRL+ALT+SHIFT+S for export), this solution does not work here. However my assumption is that the program somehow blocks the keybind because it reads some of the input. Since using AltGr keybinds works, my assumption is that the issue is the using of the CTRL key on the keyboard to switch into the mode in which you can see the distances of text fields to their surroundings (for lack of a more specific term). A "fix" could consist of either making it so that the keybinds work on EURKey again (evaluating how realistic that is is beyond my technical skills), or giving us the option to bind this control mode in the settings to some other key, which might also work. I'm of course willing to elaborate should further information help on my part. I know this is a bit of a nieche issue, but it seems like unwanted behavior and as such it should qualify as a bug. I asked about possible ways to fix it in the Support & Questions part of the forums and was advised to specify it as a bugreport. Thank you for your time.

Well, thank you very much again for all the help so far, I'll do that.

Interesting, again, thanks for the help so far. The friend who recommended me Affinity products actually has a Publisher 1 licence/version, so I asked him today to test it while screencasting so I could see if the behavior was consistent across versions and it appears to be: Typing with EURkey still doesn't work for letters that require keyboard shortcuts such as ctrl+alt+a/o/u/s. Holding CTRL down and moving the mouse around makes the same "distance" indicators appear around the text areas, so I assume the same "mode switching"(for lack of a better term) issue is identical across versions, so sadly I couldn't see if this mode switch is what causes the issue. He's also on windows, like me. The only thing that was different across our versions is that he uses a german qwertz keyboard, while I use a ISO (qwerty) one, but since I couldn't physically be there and bring my iso keyboard to test things with his version, using eurkey on the qwertz layout was the best we could do. Maybe MacOS and Windows have larger differences than I thought, since the ctrl+a/e shortcuts are different on windows (with Ctrl+a natively being "select all"). I'm starting to doubt that I will find a solution to this problem, which is a bit of a shame, but I truly do appreciate all the effort you have put into helping me find a solution. Would you happen to know if this kind of issue would justify making a bugreport? On the one hand I assume it's unintended behavior on behalf of the program, which would be an argument to make a bug report, on the other hand it seems like a nieche issue and putting resources towards fixing compatibility with a keyboard layout like EURkey is probably not worth it from a business standpoint, assuming it's not a trivial fix (and even then it'd be a low priority bug at best).

Again, thanks for the quick response. If I disable "Replace text while typing" it doesn't replace them at all (as I would expect). If I enable it I can use the workaround of replacing ä with ae (which is how it's traditionally written in german if you do not have access to a ä key), but it still only works if ae is its own word, rather than replacing it as I type. As a result instead of typing "Säge", I'd have to type "S ae ", which then becomes "S ä ", delete the two whitespaces, then add "ge" to the end of the word. That's just not a reasonable solution for typing, replacing one keystroke with 10, at least not with how frequent these characters appear in the texts. Either way all of these seem like workarounds for the actual way I'd want stuff to work, which is the program being able to read the keystroke (as it does in the settings menu). I have tried deleting ALL keyboard shortcuts to see what would happen, and it still doesn't work. That being said, if I hold the CTRL key I clearly seem to enter some kind of "mode" in which I can see the measurements of items (distances etc.), so my guess is whatever process in the program intercepts that keystroke blocks me from being able to use any keystrokes involving CTRL from my keyboard that aren't explicitly shortcuts in the software itself. If there was a way to disable CTRL toggling that mode that may be worth a try, but I don't know how to do that, nor do I think I saw any relevant option in the preferences menu.

First of all, thanks for the quick answer! I checked the shortcuts, but the only occupied keybind in there is ctrl+shift+alt+s, which is used to export. Since all the others (including ctrl+alt+s) do not work either, I don't think that's where the issue lies. The first linked shortcut customization option is the menu I looked for when I tried to disable possible double binds, but it seems to be limited to "tools, menu items, panel switch on/off, and tool operations", which isn't the same as entering a specific ascii character as I'd need for my uses. The closest workaround I found so far has been using the Auto-correct function and adding combinations to get auto corrected to these ascii symbols, but since these corrections only work with words, not with parts of words, it doesn't fix the issue sadly. Interestingly enough, when I am in the "Auto-correct" menu point and type the correction in there, it manages to read the EURkey inputs just fine and I can type the letters as I would expect, which means the issue is somehow only happening when typing in the actual document. Using MSPowertoys feels like a bit of a hack that shouldn't be neccessary, but thankfully that partially works, mapping the keyboard shortcuts to the umlauts seems to be recognized by APub2. Sadly it doesn't seem to be able to offer ß as an output, so even this solution isn't perfect. I still wonder where the issue lies and why I can't fix it, but at least with the workaround of MSPowertoys I seem to have a somewhat functional solution, though possibly not being able to type ß might still be a dealbreaker sadly. Either way, thank you very much for your time and advice so far! If this ever gets fixed I'd love the software, for now I'll try it with the powertoys workaround and decide then, but I get the feeling sadly that this issue will be a dealbreaker for me, not being able to type some letters in a language is too much of a disruption for any viable workflow. Edit: As it turns out MSPowertoys does not fix the issue. It seems to be only able to switch the keybinds of a given keyboard, so while I can assign the umlauts äüö while on a german keyboard layout, once I switch to ISO or EURkey, it just binds to those keys " ; ' [ ". This means the keybind MSPowertoys functionality doesn't work as a workaround either.

I am pretty new to Affinity Publisher 2, but after getting a recommendation from a friend I decided to give it a try and am currently testing out the 30 day trial to see if it works for me. For the most part, I really like how intuitive the software seems to be, but there is one dealbreaker issue that I have not found a workaround for so far: (I assume) some of the keyboard shortcuts of the program block essential keyboard shortcuts used in my keyboard layout, making these impossible to use. To explain in a bit more detail, I write on a iso keyboard, but regularly have to write multilingual texts (usually german or english, occasionally other european languages). The best way to do so for me has been using the EURkey keyboard layout, which maps a bunch of european characters onto the ISO keyboard. While using Affinity Publisher 2, these characters do not get printed and as a result, I have to essentially write and more importantly edit text in external programs and copy it over. As an example for german, the letters Ä,Ü,Ö as well as ß are all typed by using CTRL + ALT + (A/U/O/S). If you add shift to it, they are printed uppercase. In almost every software I use, this works without issue. The only software I have so far encountered where it doesn't work is Joplin (a notetaking software), which blocks the CTRL+ALT+S keybind. In that software, I could find the keybind in the programs settings, unbind it, and use the software as intended. Naturally I tried to do something similar in Affinity Publisher 2 by going to Edit -> Preferences -> Shortcuts and looking for any of these keybinds being occupied. I don't find any of these keybinds in there and if I add an already occupied keybinding (for example CTRL+A for select all), I get a warning that this keybind is now double bound, but the same does not happen to the EURkey keybinds, leading me to believe the sofware occupies/blocks these keybinds in some other way that I have yet to find a way to disable. My question therefore is if there is a way I can regain the ability to use EURkey keyboard layout keybinds in Affinity Publisher 2? Either by unbinding them if they are occupied by some other keybind or by fixing them in some other way? As it stands, this is unfortunately a dealbreaker for me that would make me decide against buying the software once my trial period is over, which is a shame, because I really like what I have seen so far, but the use of EURkey (or an equivalent other solution that adds the same functionality to Publisher 2) is non negotiable for the type of content I intend to edit. I am using the Desktop Publisher 2 software on Windows 10. I thank anyone trying to help for their time.