Pyanepsion

Hello, @MikeTO, I’d like to thank you for your pertinent comments. You have indeed raised an important point, that of understanding the importance of revision mode, particularly among those who are unfamiliar with its usefulness. Word’s revision mode is not just about identifying changes for an individual user. It is first and foremost an invaluable collaboration tool, allowing multiple people to contribute to a document, make changes and clearly track who has done what. The ‘Deleted’ and ‘Moved to’ tags are particularly useful for understanding the logic and context behind each modification. Validating changes before importing them into Affinity Publisher would defeat the purpose of this tool. It would eliminate the entire revision history, depriving collaborators of the ability to track and understand the evolution of the document. That’s the whole point of revision mode: to provide a detailed record of changes. I carried out a more detailed test today, using a new text containing all the character and background colours available in normal text mode. In revision mode, as before, I used a Word script to automatically colour the backgrounds for the ‘Added’, ‘Deleted’, ‘Move origin’ and ‘Move destination’ tags. Importing the Word file into Affinity Publisher remains curiously impossible today, but the result is much more satisfactory. All text, including that which has been deleted or moved, is preserved, and above all, all background colours, even for text in revision mode, are correctly applied. word.docx

The Affinity Publisher bug seen in Word also affects texts from LibreOffice and OpenOffice. These two free software packages also offer a revision mode, albeit somewhat limited, which allows you to track changes made to a text. This feature is essential for communication. When you copy a text from LibreOffice or OpenOffice into Affinity Publisher, the revision mode doesn’t work properly either. Any ‘deletions’ or ‘origin of movement’ made to the text are lost, making the functionality completely useless. This problem did not previously exist in Affinity Publisher version 2.0.

There has been a major regression in support for Word text revision modes from 2.0. When attempting to paste Word texts that have undergone revisions, deleted elements are no longer recognised and pasted as they were in previous versions of Affinity Publisher. This behaviour obviously hinders the effective presentation of our work, particularly when it is essential to show the changes that have been made. Steps to reproduce : Open a Word document containing added text, deleted text, and moved text (revision mode on). Copy the text from the Word document. Open Affinity Publisher v2.2.1.2075 and attempt to paste the copied text. Expected result: The revision mode changes (added, deleted and moved text) should be correctly pasted and visible in Affinity Publisher. Result achieved: Word text deleted in revision mode is not pasted into Affinity Publisher, unlike previous versions of the software. Attachments : Test Word document containing added text, deleted text and moved text. word.docx

The bug was encountered with version v2.2.0.2005 (public), v2.2.0.2075 (public). With version 2.2.1.2075 (beta), it apparently works correctly in UK English, and the same in French,

@Pauls, wouldn't you have used a Text format on the Excel cell, or an older version of Affinity Publisher?

Hello, @anto, (It's best to use a video format that's compatible with that of the forum.) Could you describe the problem?

The loss of paragraph style for table of contents items was reported some time ago. Reapplying generally doesn't work. Forcing the paragraph style of each TOC item (and the styles they depend on) and then saving it seems to get around the bug.

The telephone format of several countries imposes the initial 0 and is added by the telephone format in Excel.

Hello, @leeking, There does seem to be a fault. The software probably takes the last value you used. Click on the element whose colour you want to impose, and force the colour into the paragraph style.

Hello, @Old Bruce Thank you for your feedback. I understand your point of view on the use of formulas in spreadsheets. However, in this particular case, the formula simply applies a format to a character string that already exists. The initial character string, in this case "0123456789", is already present in the Excel file. What's more, I've been using the import of telephone numbers in my invoices for a long time, and it's only very recently that it's stopped working. So I think the problem is linked to the initial 0.

v2.2.0.2005 (public), v2.2.0.2075 Hello everyone The telephone format starting with 0 is not imported correctly from an Excel file. It shows : 0 followed by several spaces. phone.afpub phone.xlsx

@Panchdara, If you have a registered version, this may happen because of the time it takes for the update to spread to all the millions of users. All you have to do is to open the beta version and go to the Help|Search for updates menu.

I also think that the U+2029 probably comes from the end-of-paragraph symbol in the text box. However, I’ve left it in case it’s important. All the sequences shown are those discovered just after installing version 2.2.0.1986. I was working on a large index of several thousand references. I had resolved the unwanted line break before reporting it by modifying the sequence containing the semi-cadratine space. Whatever the After Topics sequence, it no longer appears in the form once it has been entered. It’s as if there’s a line break that doesn’t exist, but as you can see in the video, there’s still something selected.

I've used the default values in Affinity Publisher. Here is their conversion to UNICODE : Clic, Ctrl a, Ctrl c, Clic, Ctrl v, Alt U. labels-separators.mp4 After Topic: U+00A0U+003AU+0020U+0070U+002EU+0020 Between Items: U+002CU+2002U+2029 Between Ranges: U+2013U+200B Before References: U+002EU+0020U+2029 See: U+0056U+006FU+0069U+0072U+2029 See Also: U+0056U+006FU+0069U+0072U+0020U+0061U+0075U+0073U+0073U+0069U+2029 After See (Also): U+0020U+2029 After Refernces: U+0020 There is a caesura between U+200B and the next digit, or between U+2013 and U+200B (I don't know). In any case, it doesn't seem right that there should be a hyphenation because of the existence of U+200B.

v 2.2.0.1986 Dear developers, 😀 I’d like to start by thanking you for the recent improvements to the management of tags and separators in the index. It’s a very useful and well thought-out feature. However, here are a few remaining anomalies: The ‘Zero Width Space’ character does not behave correctly when used in fields when there is also an ‘En space’ between elements. The ‘After Topics’ sequence does not appear in the settings options once it has been entered. If necessary, I can send the complete file from which this screen shot was taken as a confidential file.