Table column bugs

[anweid]

Affinity Publisher 1.7.0.174 on a German Windows 7 (64bit) behaves as shown in the attached video:

1. When changing a table's width so that its height also changes, artefacts may stay on screen (video 0:00-0:35).
2. When trying to auto-fit a column of a table that already contains cells with more than one line, the auto-fit fails completely, breaking words after each character (video 0:37-0:50).
3. Trying to adjust the width of the ruined column doesn't work anymore: The width refuses to get larger than a certain amount, which is too small for the contained text, even though the neighbouring column is large enough (video 0:50-1:01).
4. The too small column can be made even smaller with the mouse, but not wide enough, and a second auto-fit produces the same bad result as previously (video 1:01-end).

Andreas Weidner

[Chris_K]

Hi Andreas

I'm getting a slight redraw error but it is quickly disappearing for me instead of staying on screen but this could be machine dependant, so i will get this reported.

The autofit could be better here too i think

point 4 is basically just  point 2 and point 3 is expected behaviour as you cannot enlarge the column any further than this without enlarging the entire table. If you press shift when moving the column it will resize the table for you as well

Cheers

[anweid]

I am completely flabbergasted: Do you really define point 3 as 'expected behaviour'?

• At first, the columns have widths as shown above: The text 123 fits properly.
• I do an auto-fit of the first column, which completely ruins this first column by making its width much too small.
• Now I try to get the previous (and perfectly working) width back again with the mouse, but cannot, because the software forbids that. Why should it forbid that? The width I want to achieve with the mouse is the width prior to the auto-fit problem. Why should that behaviour be 'expected'? I tried the same mouse resizing with every other software I know (including PagePlus), and it always worked perfectly...

To probably make the problem clearer, I attach a second video plus the corresponding Publisher file: The first column is wide enough to show the text 123. Even without any auto-fit, as soon as one tries to make the column wider with the mouse, it snaps to a width that is much smaller than any single character and stays there, refusing to even be made as large as it was when starting the mouse movement.

If this is by design, this would be the first software in my whole life that completely ignores the user's wishes, but defines its own column width, irrespective of its contents...

But the tip with the Shift key is valuable - thanks. Now that you told me I also see the corresponding hint in the status line, but I would probably never have found that on my own.

Andreas Weidner

TableColumnBugs.afpub

[gbjack]

+1 to the bug above while I was working on a 1 page document. Also when using the arrow key to shift objects, sometimes the distance indicator got blocked by the centre text frame handle, being underneath it. While at times it got displayed correctly by being in front.

[Chris_K]

Hi Andreas

Your second video demonstrates the issue slightly more clearly. This is indeed a bug and I shall get it reported

Thanks