Aleksandar Kovač

@Old Bruce This is precisely what I did. Reported bug anyway.

Affinity Publisher 2.2.0 This one is reproducible even on fresh documents with untouched default text styles. On Ventura 13.5.2. Sample document is attached, and a screenshot of what happens. Edit a text style/Initial words on a text style that is based on some other style. ‘End characters’ input will show [No change]. Try editing this variable by clicking on the dropdown and choosing TAB or anything else. ‘End characters’ still displaying [No change]. But, if user clicks inside the input box, actually TAB is added, right after [No change] label. However, there is no effect on the text. I would expect that choosing TAB (or something else) would set end character to be TAB and work according to this setting. This would remove [No change] label from the input. However, this does not happen. Besides, I have noticed while working that some other Text style settings get lost, malformed, ignored… if a text style is based on another style. However, this bug above I am able to reproduce consistently. Inital words not working as expected.afpub

I agree with @Welsbach. Regarding the ‘synchronization’ of master pages, the process that is executed when pressing ‘synchronize’ is not synchronization but rather ‘propagation’. If this is indeed ‘by design’ this is by very bad or incomplete design. As it is now, it is: damaging to the fluidity of the workflow – good preparation is important, by all means, but having to make absolutely perfect layouts beforehand eliminates the advantages of using this tool and this medium fully to the benefit of the user; unnecessarily wasting user’s time – if there are more than one master in the style source chapter, time needed to delete all the unneeded propagated masters (one-by-one!) in other chapters grows exponentially; propagated master versions accumulate quickly. Unless a user has been diligently renaming them before each synchronization/propagation, obsolete masters will have the same names as newer masters, which makes cleaning and maintaining the file a pain. E.g.: 3 changes on 6 masters in a book with 10 chapters will propagate 120 obsolete masters. 2000% increase of unneeded masters! confusing – text styles synchronize, masters propagate. Two different processes are executed with the same command; self limiting – Books concept should help manage complex publications but complex publications are precisely the kind of job where the current synchronization shortcomings are the most crippling. I’d say all the above are no-nos, and that the Books feature is not up to the task. Of course, I could be wrong. As I have been before...

Thank you for verification on this and your time @Hangman, @Puck! I am adding a ‘bug’ tag on this. And starting to hope for a fix, because... notes. They’d be handy, right?

Oh, here is another certain way to crash Publisher using the file attached before. For example, position cursor in the first column, at the note marker after the word ‘vivamus’ and try to delete this note. The result here is invariably – crash.

Working with footnotes and sidenotes has been a crash-y experience. I believe there is a bug or two somewhere here. File attached consists of one text frame with 4 columns and some styled text on A4. In that file, I can reproduce the crash consistently by reducing the number of columns on the text frame. This file does not include any pinned images (or any images) so previously proposed workaround does not apply. There were some other user actions that resulted in crash, too, but I have not isolated them. E.g. tinkering with footnote’s gap before would crash Publisher, if I remember correctly. If anyone has some free time to verify if they get the same crash? Thank you! 2023-06-30 crash on footnotes.afpub

A simple use scenario is to use a compound shape as a part of a master page. A master page is applied to 10 pages. Shape operations on the Master page consistently propagates the change to 10 pages with that Master applied. This consistent propagation is not happening here. @Return Actually, I have stumbled on this while editing the shape on Master page. 'Edit linked’ was not used at the time. I think Edit linked does not propagate the changes throughout… might be wrong on that one.

@Return Yes, but that could be destructive, possibly? 🤔 Another workaround (verified on Mac) is to create the compound shape on Page and then move it to Master. @Hangman Yes, that is visible from the layer panel. What worried me is that this seems to be due to no user action. Additionally, if ‘Edit linked’ is used on this compound, and operator is changed by hand, the result is as it should be. But, it should not happen in the first place, right?

Using Publisher 2.1.0 on Mac Mini M1 with Ventura 13.4. Reproducible bug on new documents, too. Example file attached. Recipe: Open AP, start editing a master page. Make two shapes on master page, enter Designer persona. select both shapes, and execute compound subtract operation on them. (ALT click on or Layer>Geometry>ALT+Subtract) Go back to Publisher persona. Bug: In Master page, our subtracted compound looks fine. But, in regular page we have Compound Add and NOT Compound Subtract. Even the layer panel says so: Pages layers …vs. Master layers Expectation: Boolean operations are coherently applied regardless of Master/Page contexts. I.e. a subtract should remain subtract. compound subtract not working.afpub

All (most?) of UI palettes in Affinity products are top-aligned. I.e., when the palette is larger than the content, the content floats up. But in Export persona, Export options, the content mostly sinks to bottom. (see image with that strange empty space in between). Add to that, when the palette is smaller than the content, a slightly odd positioned scrollbar appears. All this makes me think that this is unintended. And, possibly a bug.. or a papercut. This issue is present in Designer 2.1 betas, too. — Theme song: Brian Eno, Long Way Down (album: Another Day on Earth)

Thanks @Dan C for looking into this. Attached is a zip file. Please let me know if it is still corrupted. If so, I will try again... Some other way. Contour tool not working on text with character style.zip

Hello, and first of all, thank you for hard work on fixing v2 applications. Praises! Problem Unable to change decimal character for decimal tab alignment when accessed in Text Style settings... (image) Publisher 2.1.0.1732, M1 Mini, Ventura 13.2.1 (problem is present on v2.0, too) However, on Paragraph palette it works perfectly... Result, when set properly: (capital Es are tab aligned)

In a bit of rush here, excuses for shortness. This might be related to this report. Problem When applied to (in this case) frame text with character style(s) applied, Contour tool produces unexpected/unwanted results. I behaves alright when applied to 'untouched' text. (clearer to see in the file attached) — Theme song: Enya/Björk mashup... but I was unable to find any. Contour tool not working on text with character style.afpub

Yes. Or 1 or 2 columns when undocked. Not a showstopper in any way. Still, seemed like a UI bug... actually, a papercut. I will edit the post above.

Problem In Photo, when customizing the tools panel. Try setting the Number of Columns to a larger number. 5 or more. Then, the complete list of icons cannot be displayed. See attached image. The lowest line of icons is cut off, with no way to scroll. Not a showstopper, but worth noting for future development.