thomaso

The links in my post refer to a bunch of threads, containing several answers, some from a couple of hours ago, others a few days ago. And there are even more related topics, with varying keywords like e.g. replace, picture frame, resource, image, size, scale, property. The forum's search indeed can be cumbersome because of it's lack of "fuzzy" search. Alternatively you can use an internet search with adding the "site:" attribute ("site:forum.affinity.serif.com"), optionally limiting it to the APub/mac-bugs forum, for instance… … with all these 7 terms: 8 results: https://www.google.com/search?client=firefox-b-d&q=replace%2C picture frame%2C resource%2C image%2C size%2C scale%2C property site%3Aforum.affinity.serif.com%2Findex.php%3F%2Fforum%2F81-publisher-bugs-found-on-macos%2F … with only 3 of this 7 keywords: ~200 results: https://www.google.com/search?client=firefox-b-d&q=replace%2C picture frame%2C resource site%3Aforum.affinity.serif.com%2Findex.php%3F%2Fforum%2F81-publisher-bugs-found-on-macos%2F

Answers were given a few times. Feel free to use the forum's or internet search… https://forum.affinity.serif.com/index.php?/tags/afb-4537/ https://forum.affinity.serif.com/index.php?/topic/136717-temporary-delay-in-serif-staff-responding-on-these-forums/

No. But I experienced Affinity try such reinventions, sometimes for no or hardly lucid reason. There's no taboo for ID comparisons but they can fit or can be a helpful idea – or maybe useless & confusing. For instance in case of unknown concepts or especially if "ID's inline object behavior is also somewhat weird".

Sure? Your or any user's idea doesn't have to be congruent to Serif's. That's why it's useless if you try to answer my question, instead of a Serif team member. (if "inline" has wrapping 'by nature': what's the nature of "inside"?) For me, your comparisons with InDesign make the discussion unnecessarily complicated and confusing. ID is not the mother of APub, Serif works completely independently of Adobe. Saying "I'm used to it like this from Adobe..." sounds strange, considering that APub obviously is not interested in copying the UI/UX of InDesign. From this point of view, ID doesn't matter at all. What counts is the concept of Affinity (which might meet ID's but doesn't have to). That's what I was/am asking for.

That's why I specifically asked Gabe , I am interested in the developers view. According to your arguments also "Inline" pinned objects wouldn't got by default their built-in text-wrap feature (one may want to use blend modes...).

@Gabe, I wonder whether "by design" at all… 1. an object pinned "Inline" is expected to wrap text across more than 1 column within a text frame? 2. an object pinned as "Float" and set to "Inside" is expected to cause text wrapping (…like pinning "Inline" does automatically according to its "border" settings)? Or whether a Float object would require by default an additional text wrap setting if "Float" is set to any of the 3 "Inside" options? In case of the latter: • Why doesn't it stick to its pin-position? • What is an use case of pin float inside but without text wrap?

In my experience with this preference file copied from a beta folder it worked to give access to saved presets even when the "Create" option was grayed out. Since it appears to be fixed here in macOS 10.14 Mojave it is possibly influenced/caused by the macOS version? @Mgn, what macOS are you running?

Still in 1.9.1 the Resource Manager UI appears buggy in various ways: When a resource is used more than 1x then RM shows it within a folder. If a resource gets selected on page then the RM doesn't select the according entry but the entire folder instead. Makes it quite cumbersome to detect/select a specif layout item in the RM. Sorting by name doesn't work consistently. Expanding the window width widens the "DPI" instead of the "Name" column, maintaining cropped file names but useless empty space instead. The text layout in the details section insists in wasted space to its left but crops long text entries instead, e.g. profile names or dimensions. Navigation in the entries via keyboard (up/down) doesn't update the details section and requires to mouse-click the entry instead. Searching for a missing resource doesn't display the missed file name in the following window's title bar and requires instead window moves to make long or complex file names visible behind. Re-linking a missing resource via RM > Replace doesn't allow to auto-re-link other missing resources in the same folder but requires to re-open the .afpub + "Yes" instead. [ Re-linking missing resources when opening an .afpub + choosing "Yes" doesn't re-link all missing files even if in the same folder. ] [ Replacing a resource of a picture frame doesn't maintain the frame properties <– is already reported in various threads ] 1. When a resource is used more than 1x then RM shows it within a folder. If a resource gets selected on page then the RM doesn't select the according entry but the entire folder instead. Makes it quite cumbersome to detect/select a specif layout item in the RM: 2. Sorting by name doesn't work consistently: 3. Expanding the window width widens the "DPI" instead of the "Name" column, maintaining cropped file names but useless empty space instead: 4. The text layout in the details section insists in wasted space to its left but crops long text entries instead, e.g. profile names or dimensions: 5. Navigation in the entries via keyboard (up/down) doesn't update the details section and requires to mouse-click the entry instead: 6. Searching for a missing resource doesn't display the missed file name in the following window's title bar and requires instead window moves to make long or complex file names visible behind: 7. Re-linking a missing resource via RM > Replace doesn't allow to auto-re-link other missing resources in the same folder but requires to re-open the .afpub + "Yes" instead. 8. Re-linking missing resources when opening an .afpub + choosing "Yes" doesn't re-link all missing files even if in the same folder. –> see https://forum.affinity.serif.com/index.php?/topic/136142-resource-manger-missing-images-bug/&do=findComment&comment=750650 9. Replacing a resource of a picture frame via RM > Replace doesn't maintain the frame properties <– is reported for v1.9.1 already in various threads

Yes, same to me. But different than before now the arrow key does navigate. – Before: cmd-arrow

That's strange, here it works for JPG, too. – Just curious: what if you rename your APub preference folder (to cause the app to create a new one) temporarily? But I experience another irritation with the UI in the "More" section: clicking the quality slider makes the computer "beep" (the macOS error sound + flashes the screen white according to my macOS setting) … although I may move the slider and get it custom set as wanted.

To me it's fixed. Note you need to have altered at least 1 parameter of a currently selected preset to enable the "Create" option. If there is any entry in the "Preset" menu at the top of this window the "Create" option remains grayed-out.

If this .afpub worked without the extreme delay I get in v1.9.1 then there is at least a chance that Affinity is able to handle this situation. Maybe in v1.9.1 it is not only an app overload but also influenced by the workflow. It seems also the creator was possessed in a way by an idea of max. flexibility + max. resolution + max. automation. I experience the delay as being caused by a combination of various layout features: Within the text frames, linked across the entire document, + are illustrations with hundreds of editable vector objects + set to be pinned within the text (float inside) + and have text wrapping activated + with their detailed shapes a quite complex wrapping outlines The attached .afpub, unpinned & not-wrapping, reacts a lot faster in v1.9.1. The_Spotted_Cow_Menu_Unpinned&unwrapped.afpub As a workaround I personally would make sure that the wrapping outlines would be a lot simpler, with less nodes, possibly via separate wrapping objects. And I would avoid to place the illustrations as editable objects (or .eps) but maybe PDF or PNG (incl. transp.) or even non-transparent JPG (+ multiply blend mode) instead. – Then I guess also pinning wouldn't harm any more. I wonder whether APub v1.8.x worked faster for you because it interpreted these curves for text wrapping as rectangular boxes only? In v1.9.1 their complexity appears to slow the app heavily. The_Spotted_Cow_Menu_Unpinned&unwrapped.afpub

In my example it may feel odd but doesn't feel entirely unexpected to me because I had overwritten already the size defined in the paragraph style. Then a change of "[No change]" in the character style has a conflict: should it apply only for those text which still has the initial ("not changed") size of the paragraph style – or should it be dominant and apply to everything? Without an overwritten paragraph style a change of the hyperlink style font size appears to react immediately, with and without an applied paragraph style. But this video shows another issue: the greyed out "Add hyperlink" button in the Hyperlinks Panel. Though it can be bypassed via menu Text > Interactive it feels like a bug. It doesn't happen continuously, I haven't noticed yet what situation triggers it. Nevertheless, at least in this new, very simple .afpub I would expect this UI to work properly. hyperlink 'add new' button.m4v

Invisible characters: menu Text > Show… In my previous test I selected by dragging with mouse-button pressed. When selecting with a double-click, as it seems to be your way of selection in your video, I can reproduce the issue. The issue is obviously triggered by the way I select the text. So I tried with 3 different apps: • APub, • macOS TextEdit, • Bean. APub seems to handle both double-click & ctrl-click in a wrong way: • A selection via double-click copies one space, though it isn't displayed as being selected. • With a ctrl-click APub even selects text, which feels definitely wrong to me. And it also copies the space, accordingly. TextEdit behaves similar weird: With a double-click it copies the spaces before + after whereas ctrl-click doesn't select and the copy command in the context menu is greyed out. Bean works as expected for both ways. It doesn't copy a space with double-click and it doesn't select with ctrl-click. copy-paste space_in 3 apps.m4v

Should, would … or got? – Two more recent reports for 1.9.1: In this video from 3:30 min: an image replaced by itself gets placed outside its picture frame: