Tables, several problems (Publisher)

[Thomahawk]

Column Handling problem:
In Publisher 1.7.1 tables are very hard to handle. Resizing single columns always affects the columns next to it. This makes it insanely difficult to get to the desired end result. Very frustrating, that all following columns have always to be resized. The handling is furthermore very tense, clicking and moving the column line does not respond fluidly but with lags in response time. Please take an example from Indesign, where the other columns are not affected by a change of one of the columns.

Copy/Paste Problem 1:
Copy text of all rows in one column. Park it in a text-only editor or in a publisher textframe already shows all text without line separation. When copying it back into new rows, all text lands in one cell. 
By general standards, copying text from tables always must include line breaks for each row.

Copy/paste Problem 2:
Delete content of one row (C) and replace it with rows texts copied over from Word, I paste it without formatting into C. All content of row (D) disappears.

[Joachim_L]

3 minutes ago, Thomahawk said:

Column Handling problem:
In Publisher 1.7.1 tables are very hard to handle. Resizing single columns always affects the columns next to it. This makes it insanely difficult to get to the desired end result. Please take an example from Indesign, where the other columns are not affected by a change of one of the columns.

Hold Shift while resizing the column. But you are right, filling in values or resizing columns without changing the rest of the columns would be better. The Shift method is not a precise method.

[Thomahawk]

Thanks Joachim. I did try all kind of usual key combinations, somehow it did not work before, until I knew from your post that it must. Now suddenly it does. Much better. Should be the standard setting.

[Thomahawk]

Still, the copy/paste problems make working with tables in publisher very difficult. Whatever I paste in, the text in cells in the next column get deleted. And until now, the only source to get a text list from that end up in individual rows in publisher is from tables in Word. Text lists with line breaks from any other source including publisher itself end up being put all in one single cell. Big problem.

[Thomahawk]

It is not even possible to copy texts from a Af Publisher table back into Excel. All columns and rows from Publisher land in one Cell in Excel.

THIS IS A MAJOR FLAW AND MAKES PUBLISHER TABLES COMPLETELY USELESS!

[garrettm30]

3 hours ago, Thomahawk said:

THIS IS A MAJOR FLAW AND MAKES PUBLISHER TABLES COMPLETELY USELESS!

A little perspective might be helpful. Your statement is so broad that in its current form it is shown to be false by the many people who have put Publisher tables to good use. Perhaps you rather mean that it is effectively useless in the limited context of needing to copy a Publisher table out to Excel. I would suppose that it would be rather rare that someone needs to move from Publisher to Excel, but surely it must happen every now in then, as everyone's needs and workflows can potentially be very different.

The problem you have raised here has to do with how Excel handles the data it receives, and of course that is out of Serif's hands. Serif, on the other hand, does have everything to do with how data is copied when a table is copied, but I am sure that the priority is that they copy the table in such a way that it can be used within Publisher itself (such as to paste it in another place or another document). Maybe they can possibly achieve their own priorities while also being able to take Excel into account, but I suppose it must be low priority at the moment.

However, that does not make "PUBLISHER TABLES COMPLETELY USELESS." If Serif were to suddenly remove tables, the forums would light up with complaints from all the people who had been using tables.

[Wasp11b]

Does this work - copy Publisher table contents, paste into Word (Keep Source Formatting) and then select all and copy into Excel?

[RM f/g]

Did a quick test with copied cells from a publisher table.

– Pasted into NeoOffice spreadsheet: rows pasted into separate rows, colums were combined into first column.

– Pasted into Numbers: pasted rows and colums in separate rows and colums as desired (and expected).

It seems the receiving programs deal with copied/pasted information in a different way.

[Thomahawk]

hmm strange.

Yesterday I tried every possible way how to get 3 columns with 20 rows copied out of publisher. Nothing did work, and the application I tried the most was Word. Everything ended up on one line.

Today, with the same table from yesterday, suddenly it copies just fine into Word. So there is some inconsistency involved. As long as at least this works, then my statement of USELESSNESS I would have to gladly take back. But then what worries me is: precisely then when I depend on it to work – will it?

I would say it could have been Words fault, if not the same resulted in every other app like TextEdit, Excel and even in Publisher itself when copying back. So I am really unsure now how much I can trust Publisher.

 

 

 

[garrettm30]

When it works, take note of what you have selected when you copied, whether a range of cells (even all of them) or the table as a single object. Here is how Word interpreted what was copied using both methods:

 

But it does appear that neither option will work the way you are hoping when pasting into Excel. Selecting a range of cells works great in Numbers.

[Thomahawk]

Yes, as Publisher does not work standard conform even when pasting without any format, often several steps are needed. I can not copy a column from excel and paste it nonformat into publisher table columns. That gets the next column deleted. I must paste it into TextEdit nonformat first. But from there directly to publisher places all text into one single cell. Paste it from Excel to TextEdit and into Word and then into publisher is the only way this works.

Why is publisher not standard conform? Compare Indesign, where it does not matter if the text comes directly from Excel, Textedit, or whatever app, it always splits it correctly, lines into rows and tabs into columns, without affecting cells that are not selected.

[Thomahawk]

On 8/9/2019 at 8:47 PM, garrettm30 said:

When it works, take note of what you have selected when you copied, whether a range of cells (even all of them) or the table as a single object.

Thats the thing, Garrett. In publisher, because of the nonconformity, one needs a lot of experience with it, exactly knowing when to do what and how in order for it to work. Today for example, I could again not copy a whole table out of publisher, everywhere it ended up all in one line. I had to copy column by column. No clue why it did not work.

Again compare to work with tables in excel or indesign. Just copy paste anything anywhere. It always works without having to think about anything except if doing it with or without formatting.

Publisher tables are just not there yet. Not user friendly.

[Thomahawk]

Same as tabs by the way. They are also way too difficult to handle.

[Wasp11b]

 "Paste it from Excel to TextEdit and into Word and then into publisher is the only way this works."

Or you could create a text frame in Publisher, paste into that, copy that text, highlight the table or the required cells (you need to do this), and then paste. Still a hassle but perhaps less so.

Pasting directly into Publiser table does not seem to pick up tab as a delimiter - must be a bug.

[comancheTodd]

I've used Word and Excel for years, so I thought I'd already been through "Table Hell." But, Publisher brings it to a new level.

I'm sorry for dropping several issues here—if any of these are covered elsewhere, please point me in the right direction.

I will not be offended if you kindly explain to me that I'm doing it wrong.

1. You CANNOT select an Existing Table thru the Text tool, or even with the Table tool—directly.

Since I'm working on a laying out a novel, my default tool (for now) is the Text tool. One would think that the software would be aware enough to know that when I click or double-click over an existing table, the cursor should shift to the Table tool (like the Move tool changes to the Text tool when double-clicked over text.)

For example, if you click on the Table with the Text tool, it just places the cursor before or after an existing table. If you double-click over the table, it highlights the box the table is in (I guess that's what it's doing—pretty useless/meaningless, IMO).

Let's try something else. First, I'll choose select the Table tool. Initially it gives me the cross-hairs to create a New Table; but when I click on my existing table, it places the cursor before or after the table (just like the Text tool). Huh? And when I double click over the table, it highlights—exactly like the Text tool!

So, to get the Table tool to actually select and apply to the table I have to

1. Choose the Move tool first
2. Use the Move tool to click on the table to select it
   (This shows the table as blue lines with handles; other than the handles, this mode does nothing else that I can tell).
3. THEN choose the Table tool

Table formatting appears only if you first choose the Move tool, use it to select the table, and then choosing the Table tool. If you leave out step 2, you're back to the beginning: start over at step 1.

Huh? This is nuts and very, very, VERY, frustrating.

2. Selecting other text with the Table Tool

Once in the Table tool, I can go from one table to another and it properly selects the next table.

OK. Let's say I'm done with the table for now, and I want to work on text. Since I'm still in the Table tool (it is currently active), if I click on some text, I immediately get the vertical line in the text that shows I can edit, but the Table tool is still highlighted in the tool panel. Furthermore, if I'm trying to go from that text back to a table, I have to back to step one above. So, which tool am I in? I'm going to guess it is not the Table tool...

Perhaps these are all UI problems, but they sure make using tables a huge pain.

3. Floating or Inline or ????

I have one table near the beginning of the book that is clearly floating above the text—I can hit returns in the text around it, and it doesn't move, but text appears to flow underneath it.

I have several other tables in the appendix that are clearly inline, that is, they behave like they are part of the text stream. If I hit return before them, they move down with the flow of the text. (They seem to act like they are in the style of the return character that immediately follows them—kinda like Word.)

I can't figure out how or why they are different, or how to change one kind to the other kind, or if there are still other options. Since this is intended as a layout program, it would sure be nice to understand how to control them!! At one point, I tried Text-Wrapping with the floating one, but it didn't seem to do anything...

4. Formatting Hell

I have a page in the appendix that is pretty tight—I'm trying to squeeze just one more line of text into it so that the rest of the book flows correctly. The place on the page where I could conserve some space is around three tables that contain example text. But, no matter what I try, I can't seem to control the space around the table. I have tried adjusting the "Frame Insets" at the top of the Table panel, the "Cell insets" nearer the bottom, the "paragraph format" the table appears to be in, and several other things. What seems to work on one table, won't work on the next, etc.

Very frustrating!!

I would love to be told I'm doing it wrong, and instructed on how to manipulate tables.

(BTW, for me, Affinity's "Help" is pretty much useless—it explains things that most users would be able to figure out on their own. That's why this post.)

comancheTodd

[Volant]

to add to the discussion of Publisher's jank, if you accidentally set the inset value for a cell (or group of cells) to be more than is on the page, (i.e 22 inches) it will still scale all of the cells by that amount. EVEN if that means making it so large you have to zoom out to like .00002% (hyperbole) to grab the edges and resize it. unfortunately pressing ctrl+ z doesn't do anything when you have made a mistake such as this. it resets the inset value but does not resize the table back to where it was. i consider this to be a massive problem when working with the insets of cells frequently, i don't feel like one typo should cause me upwards of 20 minutes of work as it has tonight. 

i also agree whole-heartedly that the way scaling cells works as of now is ridiculous. 

also, please give an option when inserting a column or row, to split the currently selected one in half rather than moving EVERY cell up/down or left/right.

[walt.farrell]

8 hours ago, Volant said:

to add to the discussion of Publisher's jank, if you accidentally set the inset value for a cell (or group of cells) to be more than is on the page, (i.e 22 inches) it will still scale all of the cells by that amount. EVEN if that means making it so large you have to zoom out to like .00002% (hyperbole) to grab the edges and resize it. unfortunately pressing ctrl+ z doesn't do anything when you have made a mistake such as this. it resets the inset value but does not resize the table back to where it was. i consider this to be a massive problem when working with the insets of cells frequently, i don't feel like one typo should cause me upwards of 20 minutes of work as it has tonight. 

Have you reported that as a bug (or found a bug report for it)? If not, I would suggest doing so.

[Old Bruce]

15 hours ago, Volant said:

unfortunately pressing ctrl+ z doesn't do anything when you have made a mistake such as this. it resets the inset value but does not resize the table back to where it was.

There does seem to be a bug here on Mac in that the Undo will work on the Insets and the Height values but the Width of the cells is not undone. Are you on Windows and if so does the Height not change when doing Undo?