thomaso

As usual "beauty" is a matter of taste. For text justification it concerns the balance of black & white (text, ink <-> blank, paper, gaps, spaces). Concerning "justification" it refers to the look of line end/start in left/right aligned text and to gaps in justified text. For justified text and apart from hyphenation it mainly focuses on "rivers" that may prevent a balanced gray (black vs. white). To detect those areas it helps to zoom out or look at the layout from a larger distance. It gets influenced by hyphenation settings + word / character space settings. The latter gets mainly set as Paragraph Style attribute (but may also get set as Character Style attribute, in particular for more individual adjustments, especially in short text or line length/column width). Affinity starts with a useful default spacing: Characters: 0% | Words: 80% / 100% / 133%. There are many web articles about these aspects, for instance:

… whereas the issue appears more problematic than usual issues because this doesn't get obvious neither in .afpub nor in an exported PDF. (… unless the user checks the TAC as you did in your video, which should not be necessary after assigning a profile to the document or for PDF export, especially for PDF/X). Do you know if this was ever (bug-)reported for V2 ? (… I never have noticed an according bug report for V1 and I have V1 only).

What a nasty issue. It also occurs to me in APub V1. After assigning the other document profile then switching the colour model in the Colours Panel does not refresh the image and TAC values (but applies a fill colour, even if the wells are set to none before). Instead I can either replace the image (which is not useful) or save + close + reopen the document to get the profile with correct colour values / TAC displayed. Without this additional workaround also an export shows the values of the former document profile (when placing the image) though PDF/X-1 is using the correct intent for export.

The current workflow for such issues asks users to change their current hardware acceleration setting to see if an issue they are experiencing still occurs. If this helps prevent the problem, the situation is considered resolved – regardless of a possible alternative culprit or solution. The mentioned self-test routine might work similarly with the corresponding conclusions. As Walt says, it doesn't seem useful or necessary to discuss any further details in the forum – nor is there any need to convince you.

If you have APhoto you could try the "Benchmark" feature to get an impression for your specific hard-/software configuration. Run it twice, 1x with Metal, 1x with OpenGL activated. https://affinity.help/photo2/English.lproj/index.html?page=pages/Extras/benchmark.html&title=Benchmark

I don't think that's quite right, at least for Windows. I can't follow your conclusion. The fact that faulty GPU driver software causes issues does not affect the question whether Affinity is fully compatible with Hardware Acceleration in general. If Affinity would be fully compatible then all these issues were caused by faulty OS or drivers but not by Affinity – which appears odd if you consider that apps and documents are coded for specifications given by the OS, not vice versa. For Windows it appears additionally confusing that Hardware Acceleration is an Affinity System Requirements although + while this feature in particular may need to get disabled by users in case of lacking compatibility. True, a feedback of screen rendering versus display might be required to control the reliability of both input + output. I assume such an interface exists already in particular for GPU or monitor development. But hardware acceleration not only causes rendering/display issues, but can also cause Affinity to freeze or crash, according to related posts. Could Serif use their existing "Benchmark" test code, perhaps augmented with display feedback, to provide a reliable recommendation for an "optimal" performance setting for any specific, individual hardware/software configuration?

The V1 preference files might still exist in your system folder. (The location depends on your operating system + its version + the used Affinity store for app purchase/installation). If you did not delete the related V1 folder then this two posts might help to get wanted V1 content transferred to V2:

… for what in particular?

Instead of searching for an Affinity(?) user or photographer or designer I used a search in the Affinity help, maybe that is what you are asking for? If not you might show, describe or link the wanted workflow or feature for more efficient forum response? https://affinity.help/photo2/English.lproj/index.html?page=pages/LiveMasks/mask_liveLuminosityRange.html&title=Live Luminosity Range Mask

Sorry for my imprecise "slow down" (to me an issue caused by activated acceleration results in a 'slow down'). My question rather concerns the general handling of this performance setting: It appears that Affinity doesn't fully support "Hardware Acceleration" of various computers and/or operating systems, right? So I wonder if the app would be able to selft-test its compatibility on a specific configuration with the goal to choose the 'optimal' (most compatible) setting automatically … instead of a need for "trial & error" executed by users and/or "guessing" by Serif moderators, as in this current/recent thread for instance: Accordingly, I would like to understand whether a particular setup (= hardware + operating system + Affinity version) causes the same/identical results (in terms of compatibility + possible issues) across all identical setups or whether its compatibility may vary even in these cases and if yes, what else does it depend on? While it is known that the compatibility also depends on certain tasks executed by/in Affinity it is not useful or possible to activate/deactivate the according performance setting for certain tasks selectively, especially since changes require an app relaunch, right? Thus it appears useful & required to make a general decision for a specific hard-/software combination. With other words I wonder why it happens at all that Serif/Affinity appears not to know what setup (= hardware + operating system + Affinity version) will cause issues and which will be fully compatible? Of cause Serif can't test all possible configurations but it appears odd that this topic still occurs even though "Hardware Acceleration" is used on various hardware & operating systems since years (i.e. on Apple years before the switch from Intel to Silicon chips) – but wouldn't each of the existing reports complete a possible list / table of compatibility to reduce the need of "trial & error" done by users / Serif moderators? Wouldn't a table like this shed light on general compatibility of hardware acceleration & certain Affinity tasks and enable Serif developers to a prediction about (im-)possible compatibility? https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

While there is no way to hide this selection box for the app in general, you might activate the option "Hide Selection while Dragging". If pressed, it affects all types of objects, not an object individually. To hide the bounding box of unselected objects (e.g. the Picture Frame in your screenshot) you can activate the option "Toggle Preview Mode". To hide the bounding box of unselected Text Frames there is also the menu option "Show Text Flow" which affects text frames whether they are linked to others or not. And for Text Frames there is also the menu option "Show Special Character" to toggle their visibility regardless of "Show Text Flow":

Alternatively to copying the image you could copy the shadow only + use this (inverted) as mask for the (nested) shadow (or vice versa). "Lock Children" allows to move / scale the parent layer independent from its nested masking layer.

Apparently not true: It was already resolved/answered in the first reply of this thread:

Hi @Conny Gu, welcome to the Affinity Forums! What method do you use to add the gradient ? – Doesn't it work if you click the "Add current…" icon?

Its 'handyness' may vary with the spread aspect ratio (+ document/screen resolution) because it zooms to the centre if it gets used in the full spread view (i.e. after double-click in the Pages Panel or CMD-0) which zooms to the spine on 2-page spreads. Unfortunately even having a layout object selected does not ensure a 100%-zoom reliable to this specific page area, neither with trackpad double-tap nor with keyboard shortcut CMD-1. (unlike zooming via the scroll wheel, which takes the cursor position into account quite well)

To avoid possible confusion with your recent thread: This "Anchor" setting is not relevant when defining page/spread Margins nor for PDF export but only when you change page or spread dimensions in your layout document with the anchor as fixed position of scaled objects relative to their (single) pages or (2-page) spreads. The Help says: >> Scaling (both dialogs, any scope): Position—when changing page size, you can anchor the existing page content to the page or spread (they remain the same size) or rescale it in relation to the new page size. Anchor—sets the anchor point to which existing page content will be anchored to upon page resize. <<

Does this mean that Hardware Acceleration in some situations improves the Affinity processes while it slows down the performance for other tasks and thus there is no 'optimal' setting for a general app usage on a certain hard-/software configuration? I wonder because the app "Topaz Giga Pixel" offers in its app preference an option to "Calibrate" settings for best performance, which doesn't need an adjustment once it was run which appears to imply that it runs a test on a specific computer to detect the 'optimal' setting. (while this app does resampling only, no vector data handling for instance) Also this description by James Riston doesn't make it clear to me (with limited technical knowledge) whether there is an 'optimal' either/or setting for general use in a certain setup or whether Hardware Acceleration would 'ideally' need to be switched on/off depending on specific tasks (which is rather uncomfortable for general use but may be useful if specific tasks are in focus / main usage).

If I choose on mac a menu entry in the Studio menu with the according left/right studio currently hidden then the app auto-switches the according panel dock to visible. No need to choose "Show Studio" before or after selecting the panel in the menu. Is this different on Windows?

If this was the answer of the print shop I would assume they offered a correct re-print, without your need to literally request it.

Also when using the spage/spread numbers in the bottom left corner the zoom level gets reset. While using the arrows left /right of this numbers does maintain the zoom level this tools move + centre the page/spread instead of maintaining its current horizontal coordinate. While it maintains the zoom level, also this method does not maintain the horizontal position but centres the page/spread. So it appears only manual scrolling can be used to switch a page with keeping zoom level + horizontal position, which is rather imprecise and does not allow to jump to a certain page number.

I quick+dirty way in APub would be using a vector mask + layer fx to blur its edges -> then duplicate this masked tile with overlapping in the blurred areas. Of cause it works better if the selected detail has no gradient or 'obvious' large item (as the vignette + the diagonal in your marked example).

On mac you can use the Help menu, enter a term an get auto-lead to an according menu entry with an animated arrow. For instance in APub V1: Alternatively you can search in the Online Help:

Oh, in this case I obviously misunderstood your various mentions of "print" + "booklet" + the rescale "Anchor"… (but no "export"). If you delivered an exported PDF with single pages in A5 portrait then a brochure printed on A4 landscape should indeed keep your settings and sizes as set in your layout. In this case I assume the printer had a scaling value applied in its pre-press process. You can check if the visible elements in the printed result have the same size as in your layout document. If they aren't identical you might request a print in the correct size.

How it currently works: "Strings" + "Unicode UTF-16": For what purpose / advantage? Not only the interface layout requires adjustments to make "hundreds of languages" fit without cropping or other issues, also the Help and all tutorials, static or video, various websites (incl. store and forum) would need an according translation to make sense of "hundreds of languages" for the app interface. Apart from the required effort to complete your vague and superficial "idea" its sense gets reduced if you consider who could in fact benefit from this work. It is not the users of "hundreds of languages" who might not even be able to purchase soft- or hardware but this would also require understanding of all the localised terms: For example, while you can translate "Leading Override" or "Curve Adjustment" into any language, it might not have the meaning used in DTP. So, without additional education of users + translation of related documents, an app interface in "hundreds of languages" isn't useful but simply redundant – while with education also one of the existing interface languages got learned quite likely and thus an interface in "hundreds of languages" is redundant, too. (Not to mention the "idea" that automatic translation will become carried out by AI in more and more areas, without a need for extra manpower or feature requests)

The entire workflow appears unclear to me. 1. You seem to have used the print-to-PDF option to create imposed booklet pages to achieve a PDF with spreads as single print pages… 2. … while I don't understand your "Anchor" question (which concerns the scaling of document pages before output). 3. Additionally you seem to have send the resulted PDF to a printer or print service while it is unknown what scaling option has been used for printing. Means the reduced margin may result from the scaling option not only when creating the PDF but also when printing the PDF. So, what outer margin width does your print-to-PDF result show? Can you upload this PDF? – And, if you used a print service, why did you create an imposed PDF (booklet) instead of exporting a single page PDF (not print-to-PDF) and let the print service do the imposition of pages to create the print spreads?