thomaso

Do you indeed "Paste" (= via clipboard), or do you mean "Place" (via menu File, or via Tool in Apub/AD)? To me it always pastes to the upper left corner, also for a copied layer of another opened Affinity document. Only for a copied partial selection of a pixel layer of another opened .afphoto document the pasted position may vary and be not top left, which doesn't mean it gets centered.

Linked or embedded is not a point here, that's why I mentioned the Status column. You can scroll through all entries to detect any not-"OK". Or you click on the label "Status" to get them sorted, if the list then starts with "OK" click "Status" again to switch the list order. The way you get an image into your .afpub may influence this method. Using the clipboard (copy/paste) may place them as embedded whereas using File > Place or the Place Tool will do it according to your Document Setup. Again a check via Resource Manager: If the affected items have their status "OK" then their placed DPI may be insufficient. Can be checked in the column "Placed DPI" (sortable, too). Placed DPI should be equal at least or not be remarkable lower than the documents DPI. For easier investigation it would be useful if you upload an Affinity document. You can delete all other pages and objects then the one with the issue. If the image is not embedded but linked you'd need to upload the image file separately to enable a check on a different computer.

The blurred images are possibly modified or missing, the Resource Manager will note this in its Status column.

Not available yet as simple function – though it's technically no big thing, like e.g. page dimensions can get applied to more than the current page of a document also object dimensions could get an according UI. It's worth to add your vote to this related feature request:

+1

How wise & sophisticated, Walt. What for? Actually no one knows for any bug report whether it's a bug until Serif does confirm it to be a bug or just says "It's by design", regardless of its usability, the initial concept or just the way it came out to got coded. It will be more helpful if you do not feel forced to your need to reply to a topic as long you have not experienced it yourself, especially if it concerns a different OS than yours. Otherwise it's rather just guessing. Here my personal "apparently" experience, this time in APub: 1. The blue rectangle appears quite early, ca. half of the panel covers the docking area. 2. There is a very small area for panel movement where the blue indicator is visible. If the mouse is not released in time you lost. 3. No way to move the panel to cover the blue indicator's position. It loves to hide if you come closer. ––> Who is "we"? – Both the title of the topic and my description ("above" / "on top") are quite clear and do not ask for just any docking workflow. No need for such a comment, and none for the previous ones either. I never would expect or would even demand a response from you but I would prefer if you do not response as long you are just guessing or try to lead the discussion away from its initial subject by suggesting workarounds as the actual solution. No problem if you don't know the answer, and no need to let me know that you don't know, with any words. 🤫

@walt.farrell, hero of cumbersome workarounds & answerer of unasked questions, this is a bug report rather than a topic sort of"How can I send an email if I have fax only?" … "How can I walk with a bike?" … "How can I use a mirror not to feel alone?" …

The question came to mind when the OP mentioned moving, – actually as a time-saver that would otherwise be needed to set everything up appropriately. So @Judy B, you could be the first, the one and only 🏆 to detect if Affinity user preferences copied from Windows work on Mac 😉

I experience this unexpected occurrence, too, in all 3 apps (11.10.4) since several versions at least. It appears not be related to specific characters pressed nor to a specif number of characters nor to a specific time. I just tried in APub typing two characters ("nm") repeatedly and not fast (~3 per second), I got stopped (as if typing the enter key) after about 10 chars (~ 5-20) each time (~10), twice the line got cleared while typing and the characters started at the beginning of the field.

Oh, a typo., sorry! – Let's say I want to position it as top most. So neither aside nor between nor below does meet my goal here. Just On top. At the very top but not as very that it covers the horizontal bars. Might be more medium very in your way of thinking and/or my lack of English.

RED: that is how these specific presets were saved and delivered by Serif. GREEN: this is how you change the unit before creating a new document based on a selected preset. To get presets with mm only you would need to create your custom presets (≠ template) by click on the + symbol at the top of this setting options, labeled with "Custom".

On top – not aside. In my video: above Color | Stroke.

Was feather ≠ 0 when drawing the selection rectangle? How did you create the new document? Did you use menu File > New from clipboard ? Footnoting the footnote: sea - land | milk - beer 🤓

Indeed odd, since your iMac has a Retina screen, right? To me it was visible in the OP's image in the browser already & obvious when viewing in 100%. What if you view it on your iPad? How about this comparison, don't the 2 in the middle (fig. 2 + 5) look softened to you? • FastStone ("PhotoFiltre 7"?) | • Affinity bilinear | • Affinity lanczos3n

Usually I have difficulties to get the blue rectangular indicator when moving a panel on top of an existing set of docked panels. Then the highlight occurs if the moving cursor is still relatively far away from the dock + it disappears very fast if I continue moving. Usually I am able to get it docked with several trials only, it seems I need to release the mouse button quite earlier than expected by its visual position. I experience this behavior in all 3 apps and personas. – In this clip it appears not to work at all. – Any hints for easier handling? move panel as docked.m4v

There appears to be an unintended behavior in macOS only if the mouse wheel is set to zoom in the app preferences. While with unticked option each modifier key has a function the keys seem to get disabled by activating this mouse wheel option. Is there a chance to enable modifier keys for mac, too, so they work with zoom option ticked as they do if un-ticked and as in Windows? This topic is discussed in this thread, here two excerpts…

Aren't these rather your current snapping candidates (while bounding box standard would be light blue)?

I suppose you mean v_kyr's hint, the language menu only being set to English by default, right? Is there also a way for me when opening an app's Help via the common landing page to force English as the language for the Help text ? (= to suppress / avoid the local system language getting used instead)

If I open your file, select both layers and apply "subtract" I get the black only first. Then switching the fill mode works – no "divide" needed before. If I choose "Show Orientation" in the context bar + click the button "Reverse Curves" before using "Geometry" then "Subtract" works directly as wanted.

Does one know whether some of the Affinity user preferences of Windows are compatible in macOS? I suppose the .affshortcuts won't because of different modifier keys, also preferences concerning the screen (studio / panels) may vary because of screen resolution/size.

Does it solve if you go menu Layer > Fill Mode > … (choose the currently not ticked option) ?

Depending on the layout and the workflow we can not always avoid rounded values for every object or action, in particular if we set object sizes by dragging in the layout and not defining sizes numerically. I updated my post above with a link to a related topic about such calculations and unexpected results – though your decision to replace existing values appears to be the more reliable way.

A reason that causes unexpected object movement on all pages if pages get added at the beginning of a document could be the number of pages: if the document is set up as facing pages then adding an odd number of pages will force a switch of all following existing pages from left to right pages. It could be worth a closer look, even though, or in particular because you found a way you apparently needed to go to avoid the issue. So, if you could upload any files, e.g. the PDF you used and/or the affected .afpub it might help to investigate what was going on. Alternatively you could start a bug report and ask for an upload link to a Serif moderator in case you want to avoid making the files available to the forum.

An alternative way to fix a document size with rescaling its objects would be using the Rescale option in the Spread Properties (master pages) respectively Spread Setup (document pages). Ideally you would adjust the master pages first, if all document pages have a master applied then there would not be a need to resize document pages via Spread Setup.

Alternatively, select whatever is in the box and replace it with 80% for 80% or 120% for 120%. Just a note: There is a difference in this two methods which may confuse in certain situations: • If you type your calculation after the existing value then the result will get calculated with the displayed value which may be rounded according to your app preference for the number of decimals. • If you delete / replace the existing value and type your calculation in the empty field then the result will get calculated with the not-rounded, internal, mathematically correct value incl. all its hidden decimals. Usually it might not matter and will occur only for certain combinations of large hidden decimals + large calculation (especially multiplication & division). It can occur more surprisingly obvious if you change the unit between quite different scales, e.g. millimeter <> meter, or point <> feet, yard. For instance with 2 decimals the value 5.55 mm gets displayed as 0,01 m, which may confuse already. If they get multiplied by 2 with the two methods and in their different units the resulting differences become visually obvious. A thread about this speciality: