garrettm30

Besides the time to investigate and report the bug, it took me a good deal of time of actual work to clean up the article when I was copying from Publisher to post as our online version. However, I have since discovered a faster way than manually editing all the errors, and it may be relevant information. For Publisher 2 documents, I have found that I can copy a story and paste it into Publisher 1 in a simple frame, then copy again to paste into the external program. In this way, I still have rich text but without the issues. It’s definitely not ideal, but it will help get me through this until the bug is fixed. Thanks @MikeTO for letting me know about the similar post on Windows, and to @Pyanepsion for your work documenting the issue there too.

I have discovered that copying certain strings of characters from Publisher 2 and pasting into various rich text editors results in extra spaces added where there was none before. To demonstrate: Open the attached file in Publisher 2. Copy the French word L’État. Paste it into an external program that accepts rich text, such as Apple Pages, Microsoft Word, or even TextEdit in rich text mode. Below are the results I get, in this case pasted directly into this post. First line is copied from the document when opened in Publisher 1.10.6, which works as expected, and second is from Publisher 2.0.3. L’État (Publisher 1.10.6) L’É tat (Publisher 2.0.3) Notice the extra space after the accented E. I have noticed this pattern in numerous words that have an apostrophe (but not a straight apostrophe) followed by an accented character. I also gave a second example it the file which you can try: jusqu’à la fin (Publisher 1.10.6) jusqu’à la fin (Publisher 2.0.3) In this case one space became two, but I notice it is still the same pattern of a space being added following an apostrophe together with an accented character. Tested on iMac (Retina 5K, 27-inch, 2019) on macOS Ventura 13.1. L'État test.afpub

I am an Antidote user too, and I will be glad to see the day when integration is possible. What is needed is not that Serif specifically integrate this one tool, but rather that they provide an architecture for third parties to build their own integrations. That is surely how Antidote is able to integrate with a number of text-related applications, such as Publisher’s biggest competitor.

Here’s a weird one and hard to explain. Below I have a video demonstration if you prefer. Here is a text explanation: Normally, when copying a paragraph that has automatic numbering (i.e., a “Bullets and Numberings” setting), when the text is pasted into an external program (ex: TextEdit), the number gets prepended as part of the text. But when: The text is in a multicolumn text frame, With “Balance text in columns” turned on, You copy from any column but the last in the frame When you paste into another program, … the number that gets pasted is wrong. It seems to always be the next number (or letter) after the last item in the list. Recipe: Open the attached sample document. Copy the “Line 3” paragraph in Column 1. Paste into TextEdit. What gets pasted is “16. Line 3" Columns 3, 6, and 9 (that is, the last column in each frame) work as expected, but every other numbered item will be numbered as 16 in this document. If you turn off “Balance text in columns,” copying and pasting from all columns works as expected. Numbered List Copy Problem.mp4 I have tested in Publisher 1.10.6, 2.0 and beta 2.0.3.1674, all with the same results. I have macOS Ventura 13.0.1 on a 2019 5K iMac. Numbered List Copy Problem.afpub

Thanks for that. I tested that myself before I posted, and it did not work. It would seem I got tripped up by the “Match case” issue myself.

Thanks. I couldn’t find that report when I searched (I even tried visually scanning all post titles in the Publisher 2 Mac bugs, while it is still just a few pages). I tried to search again based on the terminology you used. I clearly overlooked this one, of which my post is but a duplicate:

Edit: The problem was already reported here previously. --------- Here you see part of the Edit Text Style window (for a Paragraph style). Notice that two of the section titles are cut off: This is with the UI Font set to Large, whereas Default does not have this problem. I suggest some better way to handle longer text, which surely effects not only UI Font size but other languages. For a start, it looks like there would actually be plenty of space for the missing words in English at this font size. By the way, there is a little niggle along the same lines that is not worth making a separate report over, but it just “bugs” me. Why the inconsistency here: Color & Decorations Position & Transform Bullets and Numbering

In case you are looking for a workaround (and I recognize that maybe you are not), you can use [:upper:] and [:lower:] inside of character class brackets, and that will work with Publisher’s regex. One word of caution: if “Match case” is not checked, then both both expressions will match both upper and lower.

Ventura 13.0.1, on a “iMac Retina 5K, 27-inch, 2019” (Intel).

I don’t think so. I regularly see it in various places in the dark UI style as well.

A laver is “a basin used to wash the body, especially for ritual purification.” An undocumented feature?

Maybe Serif can work out something, but in the meantime I recommend you don’t work on files on a network drive (pCloud or otherwise). I also use pCloud, and almost all of my Affinity documents are on pCloud, but rather than work on them from the pCloud Drive, I have those folders set up as synced folders by pCloud. There are no issues with this arrangement, since the files are local copies not affected by the whims of an Internet connection.

On Mac, usually programs won’t launch at all if they fall short of the required OS version, and I think that is the case with Affinity. So I think that is likely not the issue here. I would ask @suntrop whether this happens in a new document made from a default preset. There may well be some condition in an existing document that is exposing a bug.

I’m sure it will. I have it running on a 2016 iPad Pro. Here is the official compatibility list from Serif’s site.

Stepaan’s stated intention was to thank Serif, not help them. Posting it in a forum seems appropriate. He may also wish to help in various ways, but that is not the point here.

Admittedly most of this is subjective: my opinion of the new document window is that I really like how it turned out. Trying to find something objective to compare, the thing that comes to mind is that the previous version wasted so much space on visually displaying all the presets with the same icon-like rectangle that gave no information at all to the user, while the new preview does update to visually represent current settings. To contrast my positive feelings on this dialog with the export dialog, here it is mostly quite positive while there it is mixed: somewhat more functional but visually unattractive.

I’m not so sure it is, because people keep forgetting that Serif has already stated that they can’t offer upgrade prices because the app stores where they get a significant portion of their sales do not allow upgrade pricing. So their only choice is to either offer deals on their own shop and not the app stores (which might not be allowed) or offer the same price everywhere. Regardless of what we want, or even what Serif wants, those are the only options. Arguing about any other option is just theoretical, and basically just stokes continued negativity.

This may be by design, but it took me by surprise and seemed a little counterintuitive. When in the Photo persona of Publisher, if I use the File -> Open command, I am not able to open PNG files (and maybe other graphic formats). They are grayed out and cannot be selected in the Open dialog. This is a little unexpected, as Photo itself (not the Publisher persona) can open them, and Publisher also can open them if you drag the PNG from the Finder directly onto the Publisher icon in the dock. This is Publisher 2.0.0 on macOS 13.0. Note that I also tested on Publisher 1.10 and found the same thing. I searched the forums and didn’t find anything on it, but I would be surprised if this has never been reported. (Admittedly, I didn’t spend much time searching.)

I have noticed that the add character style button in the bottom left of the Character Studio seems grayed out as compared to the other two buttons, yet clicking it still works to bring up the Edit Character Style window. In the screenshot below, I have included my display preferences, as perhaps they may affect how this appears. While you’re at it, the alignment doesn’t look great either: Publisher 2.0.0 on macOS 13.0

I also noticed what I think I think is the same thing: documents set up without background transparency are still transparent in the preview. But then I discovered that this is apparently always the case, even with documents exported in V1 and InDesign, so I concluded that it has always been this way and I just never noticed before.

You can change that in the Layers Studio options.

I have seen Serif mods in the past say that one can post in whatever language. However, as a practical matter, I would recommend the poster use a translation site when making the post rather than rely on the readers to do so. Otherwise, fewer people will read the post. I always just skip over posts in languages I can’t read because it breaks the flow to keep switching to a translation site, especially when I am reading on mobile. But I say that as a personal recommendation and by no means a requirement, so each can do as he likes.

I'm starting to get that impression.

I am not familiar with any particular wonkiness regarding character and paragraph formatting. Do you care to elaborate? Maybe we could help, or at least confirm whether something does or does not work.

Thanks for the video link. There were a couple tricks I missed or forgot about.