Jump to content
You must now use your email address to sign in [click for more info] ×

garrettm30

Members
  • Posts

    1,558
  • Joined

  • Last visited

Everything posted by garrettm30

  1. I am seeing the English word “above” in a text with the language set to Français. Should I assume that strings these have not yet been localized?
  2. @MikeTO Thanks for the information, particularly the observation about the two left masters being applied with no right, which I had not yet noticed. Other than that it can be interesting, this is ultimately for Serif to figure out. I still have the full document, and I can work around where I must. My intention with my post is to make sure I am doing my part to report to Serif what is happening and offer further files or information if needed. This is a serious failing of the software, and it should not be left like this. I can appreciate that it may be a difficult problem to solve. But if a fix is not to come any time soon, then Serif should disable the ability to move, add, or delete master spread pages singly until it can be fixed. It is better for the user to be aware he must work around a software limitation than for him to rely on features that are presented as though they work when in fact it can lead to major trouble down the road.
  3. I ran into a problem today and have spent some time looking around for similar reports before starting my own thread. It appears this thread may be similar to my issue. Mike, I noticed you have mentioned a few times something similar to the quotation above, but do you know whether there is another report where Serif has acknowledged the problem or where a recipe was given to reproduce the issue? Today I noticed it when I needed to reposition a page and a later I happened to notice that some entries were missing from my table of contents. I backtracked and then eventually discovered the TOC items disappeared because the source text itself was wrongfully deleted in the process of reordering the pages. In case it may be helpful, I am uploading a cut-down version of the document I was working on earlier as well as a video demonstrating the issue. The video was recorded of Publisher 2.0.4 (release) on a 2019 5K iMac running macOS 13.1. Page Moving Problem.mp4 Page Moving Problem.afpub
  4. I can confirm this behavior. I have run into this issue before, and I don’t know to solve it other than to recreate the problem style. I don’t believe this is accurate: [No Change] is a distinct setting from auto. [No Change] says do whatever the parent style says to do, while setting Auto would override the parent style to revert to automatic behavior. So if the parent style has a leading override of 12pt, and in the child style you have set some different leading override, it is impossible redefine the child style to follow the parent style. You can only explicitly define the child style to the same value as the parent style, but of course, if you later change your mind on the parent, you would also have to change the same value in the child. Apparently for this one setting, if you ever make a child style go its own direction, you can never revert to inherit the value from the parent. And this is not consistent with other options. For example, kerning and tracking in the same pane both have auto as a setting, but in those cases, you can revert to [No Change] and expect it to be saved.
  5. 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.
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. 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:
  11. 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
  12. 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.
  13. I don’t think so. I regularly see it in various places in the dark UI style as well.
  14. A laver is “a basin used to wash the body, especially for ritual purification.” An undocumented feature?
  15. 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.
  16. 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.
  17. I’m sure it will. I have it running on a 2016 iPad Pro. Here is the official compatibility list from Serif’s site.
  18. 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.
  19. 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.
  20. 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.
  21. 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.)
  22. 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
  23. 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.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.