dbacoreworks

100% agree with above; I spent some time setting up a table and then after about an hour's work, realized the table's text was ever-so-slightly lighter than the rest of the document text. Could not figure out what I had done so I started doing command-Z, undoing things step by step until the text turned normal again. The last command said "undo set global opacity" (or similar) and that led me to this thread.
I've searched for that phrase and/or term in the built-in Help and the online manual and I get "no results found" so I was pretty lost for a while.
So I have to work from the command-undo spot before I accidentally hit whatever key I hit.
And to build on the above, something global like this at least needs an "are you sure?" dialog pop-up before enacting.
 

This needs to be disabled. It is dangerous for pre-press work. I don't see any situation where these keys could be useful as they are.

This is in part because unlike regular key bindings, they offer shortcuts for the full range of opacities in 1% steps. That is done by waiting briefly after one of the number keys is pressed to see if another one is pressed. If it is, then the second one becomes the second digit in the percent. So for example, pressing 1 immediately followed by pressing 2 sets opacity to 12%.
It's a clever idea in theory but in practice I think many of us, myself included, would prefer some way to disable it because it is too easy to hit a number key by accident.

Hi there,
By default in Affinity Publisher on windows the keybindings for 'set global opacity' are set to the number keys 0-9.
I've never used the global opacity - but sometimes unintentionally I've caught a number key by mistake unknowingly.
This is massively dangerous. If I have ever while working in a document hit a number key without realising it while something is selected, not only will that thing have its opacity changed which I don't want, if text is selected this will cause Publisher to raster that text on export for my projects.
But, the keybindings don't seem possible to change. Apart from this critical issue, I'd love to be able to bind 0-9 to something useful to me!
The above flaw very nearly caused a horrible printing issue in the main print run of my self-published book - I know to look out for it now and I go manually from page to page after every export checking for rasterised text, in a 160+ page book. 
Am I missing something?
Thanks!

I totally understand everyone's frustration with tables. At my work I need tables on a regular basis and they are a pita. Dear Serif, rethink your priorities on what basics are to a layout application, don't waste your time on fancy features anymore you drop after a while. I even made my peace with the clumsy colour organisation, but TABLES? Tables are basic. Please.

Please re-evaluate table improvements

Grumpy grandad in:
First; I love Affinity's apps. I'm a total evangelist and convinced a lot of customers and colleagues to purchase it. I have been a "Affinitier" since 2015 and I won't go back. So please, don't take this as a free light ranting.
I'm tired. I'm frustrated. Because of tables. And I have been this way since Publisher came out. I can't understand by Affinity decided to make tables as a separate monolithic object only.
Why, in the name of the design gods, they decided to make it like something outside of the text (Something that even the cheapest, crappiest text editor app understand).
Why, in the name of the design hell's lord they decided that tables can't spread through text containers, columns and pages.
Why, in the name of sanity, can't we set a fixed width to a table, or set fixed width to a column, or block the width to prevent Publisher resizing them whenever I move any other single column, making a nightmare to set the table layout.
I'm tired. This is the single cause of friction and discussion inside out studio team. This is the cause of delays and multiple errors on our work. It is the cause that we have started to make tables in a larger document apart so we can work with big tables before segmenting them to be placed into the final layout. This is why we fear to add or move any design element, because the hideous tables will no spread or move correctly in the documents breaking all the text workflow. This is why we fear to modify a table layout, because we will have to do it on all the segments of the table.
Our last work toke 4 extra hours just because of the tables. Because of the need to segment it and re-layout it after any document modification. And that's 4 hours I can't pass onto the customer because is not their fault.
In 2019, Affinity recognized that this was a very requested feature. Now we are in 2023, and that forum post is deep under into the vault of the lost threads. But we still have to design tables with virtual scissors and glue.
Publisher v2 has been a great improvement on a lot of things, but this table thing is outrageous, and just now, in the middle of a urgent complex corporate document full of tables, it is wat is making us to be working on Sunday instead of walking the dog in the countryside.
I don't know what more to say. I wish Affinity to tell us something more that "we know it is requested we will look into it, someday"
For all the love that I have to the team, I hate tables in Affinity. And I hate to be inside the studio trying to make tables to work on Sunday.
Grumpy grandad out.

My only comment about Publisher is that I've mentioned it to more than a handful of people since I learned of it and every one of them said "oh, that Microsoft app?" or "I've been using it for years". 
 
I would think a name like Affinity Layout or Affinity Pagesmith would set it apart a bit more.