Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Recommended Posts

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

Link to comment
Share on other sites

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

Serif Europe Ltd - Check the latest news at www.affinity.serif.com

Link to comment
Share on other sites

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

Link to comment
Share on other sites

+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.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.