lacerto

On Windows 11, you need to add Affinity apps there manually, and there is separately a list for desktop and Microsoft Store apps (the latter of which version 2 apps at the moment at least are even if purchased from Serif): [Could not check this now on Windows 10 Pro, but there is possibly similar method separately for regular and store apps. EDIT: Checked, there is, but I have no version 2 Affinity apps there so could not confirm if they are properly listed as store apps on Windows 10 Pro.]

Note that the actual setting that turns off effect of any guide setting is having both column and row setting set at value of 1: Guidefill.mp4 The setting that you had may have come from another work as it is easy to ignore the effect of column fill if it is near white. The discrepancy between interpreting the fill color value in versions 1 and 2 is clearly a bug and worth reporting (even if the effect is not shown in exported documents).

You have Column Guides defined and then guides turned on. Preview mode turns the guides and fill effect defined for the guides off. The bug seems to be in that version 2 reads the column guide fill color differently so the color value is more gray when read in app version 2 than when read in app version 1.

Basically no, but if you have a display profile for your monitor, you can assign that to any file that you open in Affinity apps to have identical appearance between the apps. So after you have opened the file, go to File > Document Setup > Color (in Publisher or Designer), or Document > Assign ICC Profile (in Photo), and in the former, make sure that you use the Assign option and then select your display color profile, or closest that matches your display gamut (e.g., if you have wide gamut display, you could try Adobe RGB or Display P3). Below on the top row I have assigned the two PDFs that were exported from Figma and opened in Designer v1.10.6 my laptop calibrated display profile. The bottom rows have the default sRGB color profile automatically assigned, and as can be seen colors are duller than when you edit them in Figma unmanaged (using the full gamut of your display). (Note that on the forum colors are mapped to sRGB so here the "bright" colors are mapped to the edges of sRGB and the "dull" colors appear yet more desaturated.) You could of course make your display color profile the default RGB color profile in the Preferences > Color to have an Affinity app automatically assign your display color profile to unmanaged opened files, but it is probably better to leave it to the default and then just assign the profile per file. I did not test what happens if you export your fifes from Affinity apps with ICC profile embedded, but basically you should not embed the profile. But as the desktop app runs in unmanaged color space, it obviously just discards / ignores any profile and accordingly shows the color values as they are. EDIT: Note though that if you want to share your files with other people, then you should embed your display ICC in the files so that other people see the colors similarly as you do (provided that they have a kind of wide-gamut display as you have). EDIT2: Depending on the final target of your designs, it might actually be the best option to use the browser version of Figma as it displays the colors in sRGB, and then use the default sRGB also in Affinity apps. You would get identical colors in both environments, and the audience is then also likely to see colors as they were designed (since majority of displays are only showing colors within sRGB, or narrower color space).

It is even more complex. Illustrator handles grayscale values also differently when the document is in RGB and CMYK color mode (e.g., if you enter 50% gray and switch color model to RGB, you get 128 128 128 if you have RGB document color mode, and then if you change to CMYK, you would get working color space based conversion to four-color black (rich black). But if you have CMYK document, and you enter 50% gray, then change to RGB, you will get something like 156 156 156 but if you then change to CMYK, you would get CMY 0 and K50. But Illustrator keeps Gray 100 as K100 similarly as e.g. InDesign, and basically interprets it as [Black]. When you open such PDF (produced using a CMYK mode AI document and exported to CMYK), you will get an object that is truly defined in CMYK as 0 0 0 100 and Designer (or other Affinity app) will correctly estimate the document color mode as CMYK. If you were to force the color mode to Gray/8 when opening the document, you would still get the imported color correctly defined as 0 0 0 100, but if you subsequently export it to PDF using Grayscale color mode, you would get those translated gray values, based on CMYK values being converted internally to RGB and then to Grayscale. Confusing? There is more: if you truly want to produce a grayscale (=DeviceGray or ICC Gray PDF), then you need to create a Gray/8 document and make sure that you specify your solid black as Gray:0 (also shown as B:0 internally in Affinity apps), and then make sure that you export using Grayscale color mode, and force conversion of image color spaces. EDIT: But in this specific scenario where you produce using an AI document in CMYK mode and export to CMYK PDF, just use grayscale or K-only values, then open in Affinity app making sure that the document is also opened in CMYK mode, and you should be good.

According to what is stated here: https://help.figma.com/hc/en-us/articles/360039825114-Color-management-in-the-desktop-app ...then if you use the desktop app version of Figma, then the environment is by default unmanaged. Which means that you would get whatever you see in full display gamut. That means that if you have e.g. sRGB+ capable display (a display that can show wider gamut than sRGB), you would typically tone down colors a bit to not have oversaturated images. But if you save such file unmanaged (without an embedded color profile), and open it subsequently e.g. in Affinity apps, which by default assigns an opened unmanaged image an sRGB profile, you would typically see dullened (a bit desatured) colors. Conversely, if you create a document in an Affinity app, you would by default have an sRGB profile as the document color space, and that profile also embedded in the file (if not opted out). If Figma desktop app is in unmanaged state, it would most probably discard the profile and show the sRGB in full display gamut and what you'd see is more saturated colors than when working with Affinity apps. According to what is mentioned in the referred document, you can turn on color management also in Figma desktop app, in which case sRGB profile will be used. If you instead work with browser version of Figma, you should have automatically color managed environment (sRGB) turned on (and probably cannot turn it off), and accordingly should not experience this issue.

If they ever did, I bet they lost the case. It seems a bad guy is needed, and if Microsoft is not available then Adobe will do. Once Apple sued Microsoft on windows (even if windowed UI, as is well known, never was an Apple invention), and of course lost, because Microsoft showed that Windows is all about windows, each and every control is a window with full message and event handling addressable from anywhere [which was unique and different from Apple windowing; the rest being either legally licensed or independent implementations of ideas that cannot be copyrighted]. Perhaps that explains why this is so handless still in macOS versions of Affinity apps. And it just got worse with v2: not being able to detach the main document window is just incomprehensible, it makes the whole idea of detached windows more or less useless, especially combined with restrictions on window sizes. It is not great on Windows (in Windows standards), either, but totally useable [e.g., any number of studio panels can be attached both left and right, all document windows can be detached and much more freely sized than on macOS, and studio presets simply just work, and have conveniently well working default shortcuts]. As a reference, just see how lousy windowing and docking is in CorelDRAW macOS version compared to the Windows version, which is of course a mature product, but docking has been there for ages -- since version 8, in 1997, the same year Illustrator 7 was released, and just having a look on the screenshots, it does not appear that Corel had to learn anything from Adobe in creating a UI: Anyway, this is how it is on Windows (this is from the latest version on Windows 11 but it has been like this probably for a decade or so): coreldraw_win.mp4 And this is how it is on macOS Ventura. The app is a native slick M1 app, but pretty austere otherwise, much like e.g. Pages. I am sure it meets Apple Human Interface Guidelines: coreldraw_mac.mp4 As can be seen from the Windows version clip, most of the controls are dockable/detachable, and when docked, can be dynamically sized; all docks are expandable/collapsible, can be placed within any docking frame, workspaces can be saved (imported and exported), you can have any number of dockable controls attached to all four sides of the main window. In addition, actual document windows can be detached or docked but still tiled to share the available workspace dynamically, or just detach e.g. a single window while keeping the other document windows docked and tiled and dynamically resizable. Toolbars are fully customizable, as are palettes, etc. etc. Corel certainly knows how to create a customizable workspace, but it must be very hard on macOS, even if doable as can be seen not only from Adobe apps but e.g. from apps like FontLab 8. I do not think that anyone creating a customizable UI with dockable dynamical controls needs to be afraid of being sued of what they have achieved… On Windows, at least, these kinds of features and UI automation are in-built, and available both natively and within frameworks. It is just a question of being able to use them.

Yes, I basically just posted to deny my earlier guesses as for possible causes of this issue, and to support assumption that this is not a bug in Affinity Photo (not when run concurrently, and not when running v1 or v2 independently but on two displays).

You can however create multiple views of the same document and this way possibly have better use of your workspace: Unfortunately it seems that the feature is still buggy on macOS, where it is also impossible to detach all windows similarly to be able to arrange them as above. Auto-docking near edges is also a great nuisance [but can be avoided by using the Ctrl-key while moving a window]. On Windows this can be alleviated by using the PowerToys FancyZones tool, but once the Affinity apps have scripting support, these kinds of window arrangements can easily be created by user-created scripts. I expect this community to be particularly productive in creating free scripts! UPDATE: When using split views, it is useful to desynchronize the tools so that they are NOT window-dependent (one might assume that all views on the same document would automatically share the tools, but this is not so):

I just tested this on a Windows 11 laptop with only integrated GPU running Photo v1 (1.10.6) and v2 concurrently, having in both versions multiple windows part of which on main display, part on the extended one, and part sharing both displays, and did not experience any issues, so it is likely a driver issue

I think that the user-added words are saved in "C:\Users\<your account>\AppData\Roaming\Affinity\Publisher\1.0\user\dictionary.propcol" (version 1), and "C:\Users\<your account>\.affinity\Common\2.0\user\dictionary.propcol" (version 2) but it seems to be binary so no easy way to add words. EDIT: On the other hand, it is possible to add words en masse into the fi_FI.dic basic dictionary, which is ANSI and just update the word (line) count. I suppose the added words should be in alphabetical order: PS: Muisti reistaa, sen pitääkin näemmä olla "yliesierikoisapulaisvaravaurioraivausvuorovarausratkaisupäällikkö". https://www.kirjastot.fi/kysy/missa-ollin-pakinassa-loytyy-pitka?language_content_entity=fi

Yes, you're right, and tasks are clearly separate in Task Manager, too. They do have identical task names, though (e.g. Photo.exe for both v1 and v2 processes), and there is a chance that concurrently running processes are incorrectly addressed just by name. Anyway, there is this task killing issue that is bothering v2 apps, and it might be related to having v1 and v2 tasks running concurrently and not addressed properly.

Thanks, good to know at least that this is intentional. I am nevertheless going to monitor if running the versions across has any correlation with apps becoming unresponsive. The new behavior of problems in ability to properly kill an Affinity v2 task is serious enough to make such monitoring worth while.

Only on unstable OS or apps. 8GB is totally enough when working within 2D graphic design, no video rendering. Even on modern macs. But of course it depends on work loads. I share your view as of 16GB being a reasonable minimum when getting a new computer, but if this much is "required" in 2D graphic design, there is something wrong with the app memory management. UPDATE: Based on some initial information, version 2 apps should be able to handle hardware acceleration better than version 1 apps where it basically had to be turned off, even on macs, where you do not have issues related to multiple manufacturers.

Yes, but Task Manager does not display PIDs, and I have noticed that non-responsive v2 apps cannot be killed properly from within Task Manager. The task is terminated (and the app closes), but I cannot relaunch a version 2 app unless I restart the computer. This is going back to the middle ages of the "Windows" of eighties (actually a DOS program) and I have not experienced this with ANY app on Windows (since 95) before. Needing to restart the computer to get an ill-behaving app launching again. EDIT: Not that this means anything at all, but I have Photoshop CS6, CS6 64-bit, CC 2021, 2022 and 2023 installed on the same computer, but I cannot run them concurrently. If I try, I just get the already running instance activated.

Version 1 and 2 processes seem to use identical names. I wonder if this could explain these problems? I run frequently version 1 and 2 apps concurrently and have not experienced any regular problems, but running both versions simultaneously might actually explain some of the recent "not responding" kinds of issues. I also have not been able to always kill Affinity v2 processes from within Task Manager, which might also be explained by app versions sharing the process name.

A very good point. Whether we like variable fonts or not, they are now fairly common and a modern page layout app needs to support them (even if just static instances).

Yes, I have not heard anything to substantiate warnings against using CMYK JPGs, either. I just wonder that if you allow JPEG compression at export time (as is the standard), and you create a CMYK export (forcing conversion of image color spaces) does not that make the exported files actually CMYK JPEGs? As in the screenshot below, where the images are from top to bottom: original RGB JPEG, then a CMYK TIFF and then a CMYK JPG, exported using PDF 1.7 (default), ICC profile off and image color spaces forced to convert to CMYK, and then the resulting PDF opened in Publisher: It is of course possible that files are technically encapsulated in a PDF in a way that somehow differs from CMYK JPEG file format, but why would CMYK JPG cause any issues when used in page-layout apps? Browsers of course cannot show them (or if they do, cannot do it properly) and distributing CMYK images as JPG files might baffle users who have never used anything else than RGB JPGs. Or do Affinity apps somehow have problems with CMYK JPGs so that there are posts on the forum that show that there is some point in that kind of warning?

I'd assume so, too. The other language dictionaries do have word count on first line, as well, so it seems it is needed for correct operation. Worth trying anyway.

Do you have word count on the first line? 88392 A-klinikka AA-liike It is missing from Wilenius supplied file, but I am not sure if Affinity Publisher adds it.

Yes, spelling check is pretty useless also in InDesign (and not just Finnish), at least in CS6 (Windows). But there might be some setting that you have wrong, since I get the following: Do you have something like as the first two lines in fi_FI.aff? SET ISO8859-1 TRY esianrtolcdugmphbyfvkwäüößáéêàâñESIANRTOLCDUGMPHBYFVKWÄÜÖ

If you use e.g. PDF/X-1a, or the default PDF (press-ready), the latter by unchecking "Embed ICC profile" option, and then force conversion of image color spaces, you will get DeviceCMYK PDF without embedded color profiles so values that are not interpreted in any way but passed as they are. If the printer makes subsequent changes to the file and you are not happy with the results, and you have used the CMYK profile that the printer recommended when creating the PDF, they are alone responsible, so you have very good reasons to change the printer, if at all possible!

EDIT: English translation: "On macOS spelling check works much better because it can directly utllize the OS inbuilt feature so that there is no need to install language-specific dictionaries." (This is true at least when using recent OS versions, possibly since Big Sur.) UPDATE: I do not know the reason why Finnish is not included in Hunspell libraries (so they need to be searched and fetched from an unofficial source, and are quite dated and as mentioned, their quality is low even if hyphenation works pretty well). One might suspect that It is because Finnish has 15 gammatical cases that can be used as endings of words, but Hungarian has 28, so that does not seem to explain it. Anyway, the ones we use e.g. with Word, or LibreOffice (which can use "Voikko", a specific high-quality open source dictionary, thesaurus and hyphenation library) are much better than Hunspell libraries in general .

No, you should not (you can, but then make sure that the CMYK images have the same color profile embedded that your document uses, or that they have no color profile embedded, at all). Affinity apps can handle without problems conversion, whenever needed (e.g. when using PDF/X-1a:2003, or when using the CMYK export color space and forcing conversion of image color spaces), and that is definitely the recommendable workflow (I would convert to CMYK only images that are for one reason or another problematic and do not convert well enough automatically). It is just important to use the document color profile at export time and NOT specify a conflicting target profile at this stage, as that would cause retranslation of all CMYK colors, including text, where you typically have K100 (CMY 0) definition, and which would be converted to four-color-black. It is hard to say what caused a single image stay in RGB color space, but one possible explanation is that the image was linked and link was broken, or that an embedded image was somehow corrupt, as in these kinds of situations an image would not be processes at export time but would just be passed through.

You're welcome. I just tried this on macOS version of Publisher 2, creating first a PDF/X-4 containing an sRGB JPEG without forcing conversion of image color space (using PDF/X-3 or PDF/X-4 will leave RGB images as RGB if not forced to CMYK) and then creating a PDF/X-4 and forcing conversion of image color space. When I opened these PDFs in Publisher, it would correctly show the color space of the included image, even if I force the conflicting color mode when opening the PDF. So it does not matter which mode you open the PDF, the Resource Manager does show correctly the color space of the embedded images in the file. [I forgot that you mentioned Designer, but this works similarly in all three Affinity apps, at least on Windows and macOS, and both in versions 1 and 2]