faulty textile import

[Arthur Meili]

For test purposes I imported a larger text (about 10000 words) from Microsoft Word. So I could try out all kinds of things.
Now the strange behavior of Affinity Publisher: On 22 pages the layout is perfect according to the settings. But then only one line per page is displayed. I was not able to locate the error.

Has anyone had similar experiences?

Thanks, Arthur

[walt.farrell]

Just so we have more details, how did you perform the import? Copy/paste from Word into Publisher, or save as an RTF file and then insert into a text frame using Text > Insert, or something else?

[Arthur Meili]

I tried copy/paste into a text field as Word document and as RTF. Also Insert Text from File (RTF) - always with the same result.
The error always occurs at the same position in the text document. Even if I delete some paragraphs around the critical point, the appearance does not change.

As an illustration I enclose two screenshots.

Arthur

[dominik]

39 minutes ago, Arthur Meili said:

The error always occurs at the same position in the text document. Even if I delete some paragraphs around the critical point, the appearance does not change.

Hello @Arthur Meili,

import from preformated text can always bring unwanted (and invisible) things into the document.

You can try the following:

1. In the menu 'Text' enable 'Show Special Characters'. Now look at those pages where only one line per page is displayed. Do you see any blue special characters at the end of these lines. If so, which ones? They may be unwanted page breaks.
2. Copy the entire text and paste it into a plain text editor (like Notepad on Windows). This will get rid of all formating. Copy the whole text again and paste it back into APub. The only disadvantage of this method is that it does not remove line breaks or page breaks. To eliminate these you'd have to use a special text editor that allows to 'join lines' (e.g. NoteTab light does this).

With these two tests you perhaps can narrow down if the problem is part of the imported text or a problem within APub.

Cheers,
d.

[walt.farrell]

As @dominik said, importing formatted text has its risks.

If you can include the .afpub file here, we can try to diagnose it further. But if I were looking at it, beyond examining the special characters as dominik suggested, I would carefully examine the settings in the Character Panel and the Paragraph Panel, noting the all the values for the text just before the error position, and after. You will probably find some setting that did not transfer properly.

Whether that is the fault of Word or of Publisher we can't tell. It might require both files to determine that, but it might be something the Serif QA team would be interested in doing if they don't have the issue logged already.

You could, though, try your same experiment but pasting into another application such as LibreOffice Writer, to see if it handles it all properly. If LibreOffice handles it and Publisher does not, it's likely a Publisher problem. If both LibreOffice and Publisher fail, I would be tempted to blame Word.

[Arthur Meili]

Dear Dominik, dear Walt
Thank you very much for your efforts! In my screenshots the special characters are shown, but hard to recognize. I add two more, where it is more obvious - no special characters, respectively only the usual paragraph marks.
 Interestingly, this behavior disappears again on page 43 (screenshot 3).
The settings in the paragraph and character panel do not differ before and after the "break".
Good idea to set the text in another layout software! So I looked at the result in InDesign CS6 and Microsoft Publisher 2013: The problem doesn't occur in either of them!
So it really seems to be an Affinity Publisher problem.
I include the Publisher document, also my RTF document, where the critical point is marked yellow.

Thanks
Arthur

Affinity_Publisher Test3_FEG.afpub

Geschichte_FEG_1950_RTF.rtf

[dominik]

3 hours ago, Arthur Meili said:

Affinity_Publisher Test3_FEG.afpub

Geschichte_FEG_1950_RTF.rtf

Hi @Arthur Meili,

thank you for posting those two documents. In the APub document I can see the change to one line per page on page 26.

For a test I copied the entire text (without the one in the side coloums) and pasted into NoteTab light. There I compressed all lines which means it makes everything one big block of text. Since it is a plain text editor it also removes all formating from the text.

This text I pasted back into APub. The single lines per page are gone.
This lets me assume that the problem is somehow part of the imported text (perhaps in combination with some bug in APub).

By looking at text flow options in the APub's paragraph panel I didn't find any source of this behaviour (so far).

I'll keep investigating 
d.

[dominik]

2 hours ago, dominik said:

I'll keep investigating 

One more discovery:

• Select all text of the main text (including headings).
• Assign this selection to the entire text.
• Select 'Detach Paragraphs from Body'.

Basically this assigns 'No Style' to all paragraphs and removes the single lines on some of the pages. Everything flows across all pages as intended.

I take this as an indication that the imported paragraph style 'Body' has some setting (or bug) that causes the fault.

d.

[walt.farrell]

If I create a new .afpub document, draw a text frame covering the first page, then right-click and "Insert text from file" everything looks just fine to me.

As I don't have Word, I can't try copy/paste, but I did try that from LibreOffice Writer, and it worked properly.

@Arthur Meili: Can you reproduce the problem if you create a new document and use "Insert text from file" using the .rtf file you attached here?

[Arthur Meili]

Hi Dominik and Walt

Thanks again. Yes, detach paragraphs from Body removes the single lines. 
And yes, I can reproduce the problem …
In a newly created document I inserted my RTF-file via insert text from file and added pages to the end of the text. There were no problems with the imported RTF format.
Then I created a completeley new text style and applied it to the whole text - and indeed, the error is back! That doesn't depend on the font, I tried three different ones.
This was not the case with my test with InDesign and Microsoft Publisher.

Arthur

[dominik]

53 minutes ago, Arthur Meili said:

Then I created a completeley new text style and applied it to the whole text - and indeed, the error is back!

This sounds like there are 'certain characters' part of the imported RTF that make APub's text styles stumble. A bug can be the source but I am not sure about this. It would be worth to further investigate the characters around the unwanted page breaks.

d.

[Arthur Meili]

After another test I can basically give the all-clear ... :-)
But first I want to tell you something about my background. I've been working with layout applications for more then 25 years now. I started with Page Maker ... Mainly I produce flyers, brochures, magazines and photo books. Longer texts I capture in Word or get it as Word files from other authors. Since the change on rental basis of adobe software I look for an alternative. Affinity is a top candidate for me!
I started my new test right from the beginning. I took the text from an old project - Nepal Expedition 2009 -, a photo book I designed for the travel group. The text contains 19,060 words. It is also a Word file, but only with the basic format for the text.
The import as RTF file into a new Publisher document was done without any problems. Then I created a new text style and applied it to the whole text - no problems here either. So my first text seems to be really damaged, even if the error didn't occur in InDesign and Microsoft Publisher.
One observation still seems important to me: The text from Word can be saved as a TXT file (with or without linebreak; CR/LF). When importing into Publisher, however, the umlauts from the German language are lost (ä, ö, ü). Special characters such as quotation marks are also affected. The TXT file contains everything.

many thanks

Arthur

[walt.farrell]

3 hours ago, Arthur Meili said:

One observation still seems important to me: The text from Word can be saved as a TXT file (with or without linebreak; CR/LF). When importing into Publisher, however, the umlauts from the German language are lost (ä, ö, ü). Special characters such as quotation marks are also affected. The TXT file contains everything.

Without seeing how they're affected, I can only guess. But it sounds like a problem detecting the encoding of the data. Those characters have different representations in ASCII ghillies than in Unicode files, and if the text file is saved without a BOM character at the start the program reading the file has to guess the encoding and may get it wrong.

I think I've commented on a similar problem in Publisher in the past, and I believe their method of guessing needs to be improved.

Meanwhile, you could try saving with a BOM and then importing into Publisher to see if that helps improve the result.

[Arthur Meili]

Okay, I'll do you the favor … 
In the screenshot (import of TXT document from Word) the German umlauts, quotation marks and dashes are missing.

Arthur

[Ray S.]

Hello,

if I'm importing text created with notepad and saving as .txt in ANSI-format the Umlaute are not recognised. But if I save the text with unicode, or unicode big endian, or utf 8 encoding everything ist fine. Maybe that help, Arthur.

[Arthur Meili]

Hi Ray
That's a very good tip! I saved my text in Word as a TXT file with Unicode encoding and imported it into Publisher. All characters are there! The structure of the document (paragraphs) is also preserved.
Unfortunately, the topic error remains in the document. An attempt with another text saved in this way was successful.
Thank you
Arthur

[dominik]

2 hours ago, Arthur Meili said:

That's a very good tip! I saved my text in Word as a TXT file with Unicode encoding and imported it into Publisher. All characters are there! The structure of the document (paragraphs) is also preserved.

I want to emphasise this. Whenever possible I try to save a TXT file (or CSV in other cases) with UTF8 encoding. This works well with special characters.

 

2 hours ago, Arthur Meili said:

Unfortunately, the topic error remains in the document. An attempt with another text saved in this way was successful.

This seems to be another hint that the error has it's source in original document ... maybe in combination of some bug in APub. There must be something with the text style definition.

d.

[Chris_K]

Hi Arthur Meili

This seems to have something to do with the Keep with next lines option on the paragraph panel. If this is set to 0 then all the text will be together, as soon as you set it to 1 or above you get the frames with single lines. I shall get this reported to the development team

[Arthur Meili]

Hi Chris

You actually identified the source of the error! Also the error with the page break (and also Frame Break) is to be led back to it.
I was able to reproduce both.

Thanks!
Arthur