thomaso

What do you mean with 'directly' and 'normal' here? How had you placed the images when the issue occurred? Just in case: visually this look reminds me to a recently reported (logged) issue caused by copy-paste of text + images that were pinned.

It becomes weird: Before recently updating my "recipe" above I had done just a quick trial within APhoto in my current test file (which initially was a JPG opened in APhoto, never an .afpub). I don't know why but I still can reproduce it in this .afphoto – but not in another. For any reason in this file created text frames get by default this background color: afphoto shape convert textfrm w color.m4v I am surprised myself because I can't detect any place in the UI where this background color is set. Maybe this file is someway corrupted, I use it for tests since months meanwhile with many delete and undo actions.

I don't get this option in the context menu, even though 2 monitors are in use. I vaguely remember an option in the system settings, maybe this is mandatory here. I had it activated once, but experienced it causing disadvantages (I don't remember in detail). I understand. Because Affinity can't handle fullscreen mode failure-free yet, this option may have more reasons not to work. Initially I just was wondering only because Thomas K. wrote "I think it didn't help" - he did not say "It didn't work". (Okay now, nevermind)

Ah, indeed it doesn't "just" work, at least you have to activate the Layers Panel first to make it the "current" UI item. I don't know what else may prevent it from working, it seems to help sometimes to activate the Layers Panel without activating a layer yet, e.g. by a click on the layers panel label or in the empty layers area, and select a layer then, either with mouse or with cmd-up/down. Here it stopped working after changing the layer name. After the video I noticed I could make it work again by a click below the layers but inside the panel. layers panel mouseless navigation.m4v

Yes, with macOS Spaces we can define specific "Desktops" for various apps – but assign an app to a specific screen, in terms of monitor hardware (as this thread is about)?

There is a mouse-less workflow: 1. Move through the layers panel with cmd + arrow up/down 2. press return key to enter the layer name field 3. type the name 4. press enter to confirm and leave the name edit state

There is not much to learn about this feature. Just select a stroked object and apply the command. Example: a text frame with the character "v" was converted to curves (> option in toolbar) –> then the menu command was applied –> the result was selected with the node tool to show its curve with nodes: –> –> In the Affinity Help you'll find a bit of description: https://affinity.help/designer/English.lproj/pages/CurvesShapes/expandStroke.html

@Gabe, another macOS example is the Finder.app: here 1 window & tabs offers in menu "Windows" the list of them all + enables this way the user to switch: Well, here one can simply click on the wanted tab instead using the menu. But in Affinity, in particular in dark UI + in a wider window, detecting and distinguishing tabs can be tricky and is less practical this way than a menu list. Compare this Affinity visibility (= tab title readability) of open documents in the following screenshot with the clear view in the menu of the screenshot above.

> (actually the first app I ever worked with, where it works) What about the macOS Preview.app? To me it shows the 100% document size accordingly and even updates it live when I move the window from one screen to the other. (note there is an app preference to make it work this way). How did you achieve to make Affinity start on the external screen? And did Affinity then open all windows on that screen, incl. the "Open..." dialog and new document windows, too? Although we may in macOS decide which screen gets the main menu bar, I assume that mac hardware with an internal screen too often treats this as kind of a master.

> it makes more sense now. Unfortunately it does not, it rather confuses more. Because...: You can see it working as all-open-docs-list in Preview.app: 1. One window with title bar and title of the currently selected document. 2. Below are tabs of all open documents. 3. The menu "Window" lists all open open documents / tabs. This view occurs if you have chosen in the Preview.app prefs the third radio-button. This preference corresponds in Affinity to "Separate Mode" + "Merge All Windows": 1 window & title bar + All tabs below. But different to Preview in Affinity the list is not a list but reflects 1 document only, a copy of the title bar text (usefull?). Note: In your Quote "When a user selects an available window in the Window menu, it comes to the front of the window stack." it seems to make no difference between window & tab view but rather, effectively, treats all / any as a stack of document windows, the user may select from ... and it does list them all, as shown in my recent Preview screenshot above.

Oh, that's interesting. If I leave "Separated Mode" then all document's get tabbed + there is no way to have them in various windows. (I use Separated Mode only to have the tool bars moved and use "Merge Windows" all the time). But in macOS with not-separated but tabbed mode the menu "Windows" still shows as open document list the currently selected only but not all open documents. So, @Gabe, if this open document list is treated different by Affinity in Windows OS than in macOS: is there any chance that the behavior on mac might have been programed this way kind of inadvertently, even though it's obviously "by design"? And therefore maybe worth to get logged?

Ah, I see, in Affinity (and e.g. browser.apps) open documents get listed only for not-merged windows but not for tabbed document windows ... ... while it is vice versa in Preview.app, where the complete list shows up for tabbed document view only. Bit strange user experience. However, thank you for pointing me to this difference. Feature request: I would appreciate to have the option to get the entire open document list in the menu "Windows" when merged/ tabbed view is used. As a supplement to the viewing options 'single document' vs. 'tabbed document' windows (merged).

Hi synthetic, Welcome to the Affinity Forums! I'm not sure if I understand correctly, maybe you can upload screenshots? What kind of mask did you use? Note there is a known + logged issue with the Vector Crop Tool and layer opacity, though this issue doesn't affect masked parts. In this sample I placed masked images in various ways, none of them shows their masked parts in the exported PDF (preset 'for export').

Good point. Apparently this value must be 50% or above to make any calculation start at all.

Some elements in your PDF seem to be grayscale and print in max. 100 K. Since you print from preview.app I assume you don't have Acrobat installed, so to check the color values in your PDF you might like to use this online tool https://www.pdftron.com/webviewer/demo/color-separation/ Un-Tick the Black in the left column to see those parts disappear, which will print in black only and therefore might not be as dark as wanted. In this screenshot those parts are marked yellowish.

That's odd, since I can not make the file name get transferred, and Jon P comments: @Jon P, can you please clarify whether copy/paste should transfer the file name, or under what circumstances it worked for Jens in various macOS versions? I just tried once more, now without Separated Mode, unsuccessfully.

> True, then (...) now is Affinity's turn… I still don't see a bug here, and therefore no "Affinity's turn". – You have an UI with two different approaches to define page sizes, one of them has three options to choose a page range and opens its dialog window with one of them preselected. – So what? Why would "current spread" be a bug whereas "selected spreads" wouldn't? How about "All spreads", or without preselection, would they be bugs, too? So in your eyes the export dialog window is buggy as well cause it always opens with "All spreads" preselected? How do you understand "bug"? It seems you confuse it with "not my preferred way".

This sounds contradictory to me: While not writing to the file is non-destructive, the inability to recover previous adjustments is destructive. However, the Develop persona definitely is destructive because you can't undo any of your actions once you have left the Develop persona. Then you continue with a virgin, empty History Panel and just 1 layer. Even going back to the Developer persona doesn't allow to refine or undo any previous action; the Develop persona has no Layers panel. So, the only way for non-destructive is to close the file in AfPhoto, reopen it and start developing it again. From that perspective no application would be destructive as long you don't save your changes.

I don't now a recipe either but it seems to help understanding what's influencing what if you consider the total number of six possible properties which may even contradict each other, and to inspect their actions one by one. So it appears to be best, at least as a start, not to use/activate/set all of them but to choose the relevant to achieve a wanted design. Since the baseline grid does override the other settings it may be wise not to use it unless necessary. I occasionally experience redraw issues while adjusting table properties, so it also may be useful in case of an unexpected occurrence to slightly move the zoom wheel to force a redraw. I am not aware whether this was reported already in the bugs forum. – See redraw issues at 0:33–0:37 min and 1:00–1:04 min in this video: table text vertical, grid, leading, inset.m4v

But in macOS also Acrobat seems not to get the ppi info from the system but has to be set by the user to show "Actual size" accordingly. It's interesting that even the macOS Terminal command "system_profiler SPDisplaysDataType" does neither mention ppi nor physical dimensions (e.g. diagonal inch) of the connected monitors. By the way, here is an online calculator for monitor's ppi: https://www.sven.de/dpi/

In the same way as an .icc file, they appear to differ only by the suffix, not by content. So in macOS you might need to rename the suffix to .icc to be able to e.g. import it in AfPhoto via menu "File" > "Import ICC Profile". What me confuses is that I already do have a profile named "Schwarze Druckfarbe – ISO coated v2 (ECI)" (without "300%") in my export options profile menu but I am not able to detect an according file on disk, even the APub app package doesn't seem to contain this profile. – Additionally odd: this profile does not appear in AfPhoto (but I can add the 300% version via import). – Maybe anyone can shed more light on this?

Interesting. I tried embed/link as document preference and used images from my ~/Images folder, inserted jpg, tif and png and in either Finder's list, column and icon view – but I am not able at all to get a file name appear with the image in APub this way. In what macOS version does copy/paste cause the successful name transfer for you as shown in your screenshot?

What do you mean with "this" ? To me an image placed by copy-paste from the Finder (or another non-Affinity app) never transfers the file name with the image but always gets a name "Image" in the layers panel.

Note that also the option "Selected Spreads" does not reflect a custom selection in the Pages Panel but requires you to make the page selection in the list to the right. Only the state of "current" is transferred to commands in the menu "File", e.g. for spread properties and for print and export, where also currently selected object(s) on a page gets transferred as "current" and are used for the print and export option "Selection".

I'm afraid it is not. I don't know of any document specific setting you could set across various documents synchronously. And this even appears to be not stable within one document and session, though I had activated it for my current document recently, I now experience it to be deactivated again, caused by any unknown action but not related to object specific settings in this document. Bit weird. And new documents seem to start with this option always as disabled. May be someone more experienced with this feature comes up.