Publisher text flow into next text frame reduces to 1-point type

[karlbu]

Hello forum.  I am having an issue in Affinity publisher 2.0.4 where I have pasted unicode text from a Microsoft Word document into a Publisher document that has three columns.  The text is unicode-pasted into columns are formatted as a style with 13-point Helvetica Neue Light 45 font.  All good after the paste.

When I attempt to flow the text into the next column, the text automatically flows into the next column—illegibly, at 1.4 points.  (See screen shot, top of column #3.  If you can't see the text there, neither can I.)

I can (carefully) select that microfiche text at the top of column 3, click 'no style' and then reapply the correct style, the text does format correctly.  However, a) that's a lot of manual formatting for a long document, and b) the text flow to the new column should flow with the correct style formatting. 

This happens throughout the document, and, unfortunately, across multiple documents. 

I have reinstalled and recently updated Publisher to 2.0.4.

Has anyone experienced this issue?  And, if so, any suggestions for a more permanent fix?

Thank you.

[walt.farrell]

One possible cause for that: When you drew the Text Frame for that column, you adjusted its size by using the lower-right handle (the one detached from the frame). That is the rescaling handle, and would adjust both the size of the frame and the size of the text it contains. For example, if you initially drew the frame longer, then decided to shorten it, but used that outer detached handle rather than just dragging the bottom of the frame upward.

[RM f/g]

I ran into this a number of times. But:

1. It hasn't happened anymore for quite a while;

2. All imported MS-Word styles are deleted immediatly after placing/pasting text and replaced by styles compiled in Publisher.

Are they related? Who knows?

[walt.farrell]

1 hour ago, LondonSquirrel said:

That isn't what happens with the rescaler handle - it affects both axes at once.

But the end effect would depend on the original size of the frame, and we don't know that.

[karlbu]

Thank you everyone for your quick responses.

Walt—My process:

1. Clicked on the white triangle with red outline as precursor to text flow.

2. Positioned resulting +[T] icon to top of column 3 (which was blank, e.g. no frames).

3. Sized text frame to column, and text immediately flowed in at 1.5 point microfiche.

Therefore, no, I did not use the 'resizer' handle.

Note, that after I have re-applied the style (per my original post), deleted the text frame in column 3, then re-flowed the text (per steps 1,2,3 in this post), the text flows in with the appropriate style.  Point being, I was not able to repeat the issue after correcting the 1.5 point text.

Because this has occurred on multiple documents, methinks it is also a bug lurking in the code.

I will monitor and report back any additional findings.

Thanks again. 

[karlbu]

This formatting issue just won't go away and doesn't want to resolve.  After trying to again correctly format the micro-type (as described above), the bottom of one column now forces 87.5 point type.  After reformatting the elephant type, more elephant type appears from the subsequent text.  Can't select all text in multiple paragraphs to re-apply the selected text style, because the elephant type refuses to re-format.

See attached screen shot.

[karlbu]

Hypotheses based on further testing as of today:

1. Severe bug related to text flow between text blocks when Text Style applied.
2. Possible text corruption when Unicode-pasting text from a Microsoft Word document, as RM f/g suggested.
3. Combination of 1 and 2 above.

When I removed the Text Style from the text that flowed from column 2 to column 3, the micro type still appeared.  However, I was able to carefully select the un-styled micro text and successfully change the font size. 

There is a nasty bug lurking somewhere deep in the code.

[karlbu]

Thank you.  I have added your steps to my workflow.

[Jim_A]

This is a shot in the dark but might help isolate the problem:

I remember from my days wrestling with Word docs this tip from Clive Huggan in his article Bend Word to Your Will.

"Paragraph marks contain up to 250 types of formatting information. The last paragraph mark in the document sits just before the invisible “master section break”, which contains a huge amount of document-related formatting — including the file header (not to be confused with a “page header”), which contains the corruption. Often, if a [Word] document is corrupted, the corruption can be removed by transferring all but this last paragraph mark into a new blank document..."

So if this bug is repeatable it might be worth trying to cut and paste all but the last paragraph mark from the Word doc.

[RM f/g]

Here's my method for transfering text from MS Word files to Publisher.

 

A MS Word file is openend in NeoOffice (a LibreOffice variant) enhanced with the wonderful add-on ‘Alternative Searching’ by Tomas Bilek: https://extensions.libreoffice.org/en/extensions/show/alternative-dialog-find-replace-for-writer. It can save complex search and replace actions.

I activate this add-on and a few mouseclicks later I have replaced remains of sloppy typing – like double spaces – and have applied markups to the text like <i>text</i> for italic text. Then select all, copy.

In Publisher, with paragraph style set to Body and character style set to [No Style]: ‘Paste Without Format’, so only plain text is pasted. Including footnotes, luckily.

With a few find and replace commands, text between markups is replaced with character styles and markups removed.

These find and replace commands to be used in Publiser are kept in a separate text file for as long as Publisher doesn't support saving of find/replace commands or scripting.