lacerto

Here are fresh screenshots of Publisher and Designer 1.10.3 (on macOS): At first the CMYK sliders used percentage scale exclusively but as I was playing around a while (switching between 8-bit and percentage displays, color definition models, opening the Color Chooser dialog alternately from the Colors and the Swatches panel), the 8-bit CMYK scale appeared and I have not managed to revert to percentage view no matter what in either app (it does not matter which scale is chosen from the Hamburger menu). Affinity Photo is the only one that still displays percentage CMYK scale in the Color Chooser, and might well keep it because it behaves color-definition-wise differently than AD and APub. As mentioned, on Windows the scale is synced with Color Panel (even if the dialog needs to be reopened, and even if RGB 8-bit scale always also triggers 8-bit scale for the Color Chooser CMYK sliders). Windows versions also allow specify 8-bit and percentage scale independently for CMYK and RGB.

No stylistic sets or alternates used here, and when used, none of them remove the use of double hyphen. As mentioned, the code used is Unicode hyphen which is double hyphen "--" in this font, but Affinity apps are the only ones I have tested (so far [EDIT: Xara Designer Pro and CorelDRAW 2017 + Pages + LibreOffice Writer now tested, as well]) that use it for hyphenation.

This font works without problems (is hyphenated without double hyphens) in InDesign and QuarkXpress [or even Microsoft Word]. It seems to be typographically pretty ambitious font so it might do some things in a bit "advanced" way. @LibreTraining @MikeW -- any idea? UPDATE: The font has "non-regular" hyphens: ...compared to e.g. Times New Roman: ...but hyphenation is regular in InDesign and QuarkXpress: [Double hyphens do not show even when using discretionary hyphens, either to force a hyphenation spot, or prevent hyphenation.]

In a way it does make sense when there is no support for showing tonal variations in exact percentages (as decimal display is not supported in Affinity apps for CMYK color values, as it is e.g. in Illustrator, InDesign, CorelDRAW and VectorStyler) -- in input decimals seem to be supported, though. Conversely, RGB values are not typically shown in percentages but it is good that it is supported in Affinity apps, as e.g. Adobe Acrobat Pro shows RGB color values in percentages.

I just installed Windows version 1.10.3 and the behavior seems to be the same as before (or might be partially fixed). I am not sure which conditions trigger which behavior but it seems that that if you double click the color from the Color and the Swatches panel, you can have Percentage reading in one (former) and 8-bit reading in another (latter). Having initially an 8-bit based RGB color selected seems to force CMYK sliders in Color Chooser also be shown in 8-bit scale. When accessed from within the Color panel, having initially a percentage-based CMYK color selected shows the percentage based sliders also in the Color Chooser. If 8-bit reading is selected from the hamburger menu of the Color panel for CMYK sliders, the setting will be honored also when accessing the Color Chooser from within the Color panel. On macOS, the old bug where 8-bit / Percentage display (chosen from the hamburger menu of the Color panel) is used both for RGB and CMYK seems to be still unfixed (I think the user should be able to choose whether 8-bit or percentange scale is shown as per color model, as on Windows, since it is common that RGB values are shown in 8-bit scale and CMYK values in percentages). EDIT: On macOS (I have only tested Publisher) the feature seems to be much buggier otherwise, too, since there does not seem to exist sync between the percentage and 8-bit display of the CMYK values of the sliders of the Color panel and the Color Chooser, so when the display goes 8-bit in the latter, I do not know how it can be reverted to percentage display (it possibly got buggier now in 1.10.3).

But one welcome change, at least, File Explorer and Photos now seem to be color managed. I have it on Surface Pro 7 and no compatibility problems with Affinity apps so far.

Would not adjustment of alpha with Curves do the job?

Welcome to the forums! Can you use preview of data when you set up the data fields? Or can you create the merge if you limit the record range? If you can, it is likely that the problem is related to data in one of the data rows, in which case try with limited data ranges until you find the offending row. If the error occurs even with limited data, is it possible for you to post a sample of the data layout (and any data) that causes the problem?

I am talking about use(fulness) of swatches of the Grays palette (which is an RGB-based palette) when working with documents that are in Gray/8 color mode. In this color mode K-only palette produces inaccurate grays because its values get converted based on underlying working color profiles, while the Grays palette produces accurate and expected grays (also when exporting to RGB e.g. using the digital presets).

Sorry, I was inaccurate, when exporting grayscales, they produce device grays converted via K-to-RGB-to-gray values (basically uncontrolled, unexpected gray values), while when exporting from grayscale documents to CMYK, they produce four-color-blacks (as would gray-palette swatches). I just meant to point out that K-only are not a guarantee of black-only (or accurate grays), and that the RGB-based Grays-palette is useful in context of how Affinity apps handle grays when working in grayscale mode.

The Grays palette is of course still useful when working with Gray/8 documents, as its swatches produce RGB grays that export with true G values (device grays) when exporting to grayscales, while K-only definitions produce rich blacks.

I tested your file and did not have problems with the bleeds, either (I used 10mm on each side), but I left out everything else than the background layer (that has the stuff that extends over the edges), as the PDF export size (using PDF/X-4) is over 138MB just with the background (the FX will cause everything to become rasterized). I wonder if full render of all elements could somehow cause this problem? (Note, too, that when you include the bleed, the printer's marks are not automatically included so without e.g. crop marks it is not immediately obvious that bleeds are included.)

You could try the following (that is, add a master that has the correct margins, then apply it on the last page): fixmargin.mp4

If it is the converse process (creating grayscale separations from CMYK), you would do something like this: After this the separate grayscale layers could be exported to grayscale files.

I am not familiar with the process you mention, but see if the following clip could give you an idea on how to achieve your goal. Here spare channels containing grayscale separations of CMYK plates have initially been created by placing grayscale separation files in a grayscale document, after which each layer is saved into a spare channel representing the C, M, Y and K inks, before converting the document to CMYK color mode. Then a grayscale layer is created (which in CMYK document gets CMYK channels) and the spare channels are copied into the equivalent layer channels and finally inverted to restore the original composite CMYK.

The problem itself seems to be non-fixable, but its behavior can be restricted by selecting the offending row, rotating its orientation and then hiding the offending text ("Sa" below), and the weekday name, and simply just ignoring the row (and if new table rows need to be added, add them before the offending row): But it would be better to just create a new table. If the "text on the curve" ("Sa") is tried to be deleted, this will immediately crash the app.

I have the basic 8GB M1 MacBook Air model (besides having several mid and high end Windows laptops and desktop PCs + a mixed bag of 10 or so older MBPs, one Mac Pro, Mac Minis, and iMacs), and I think this is price-quality-wise the best computer I have ever had. M1 chip has its limitations, and 16GB RAM can probably make a difference with certain tasks (according to some benchmarks I have read and also posts made on this forum), but as long as heavy multitasking is not constantly needed and very large files are not regularly processed, I have not noticed any significant bottlenecks after about a 10-month usage with Affinity apps, some Xcode and VisualStudio app development, and Photoshop. "Professional" is a subjective attribute, IMO, and it should not be used, at all, without a definition (ruling out this kind of a device would, after all, make much of pre-2016-or-so computing "non-professional", which is just absurd). Affinity-apps themselves could well be rendered "hobbyist", or "semi-professional", at best, in the same vein, so these kinds of labels really do not mean anything. So to be able to give accurate answers, more specific task specs should be known, to make meaningful comparisons. 2D graphic design [exclusive video processing aside] generally is pretty low-end as regards computing requirements, so as a general note I'd say there is very little what this specific "entry-level" M1 computer could not do without any problems, at all. Affinity apps themselves have some serious problems with memory management, long documents, etc., and a more capable computer might alleviate handling (or avoiding facing) these kinds of situations. [The results as for the amount of RAM available seem to be mostly comparable disregarding the kind of a mac M1 chips are used on.]

Here are yet other two ways to change the color of a pixel layer with antialiased edges, retaining semitransparent pixels, one non-destructive (Color Overlay Fx), and another destructive (use Paint Brush protecting the Alpha):

It does it after export, too, if you view it with the correct target profile. Uncoated profiles are often a bit brownish on screen, trying to simulate lower TAC on uncoated stock (sometimes clearly exaggerated). This is from Photoshop, PSO Coated and Uncoated side by side, with K100:

Yes, to change the definition, instead of Grayscale, choose CMYK model from the dropdown and then change to a K-based definition (you would initially see e.g. G0 be converted to a four-color black, because Grayscale color mode is actually RGB based in Affinity apps; therefore G0 would not be the same as K100, but instead R0 G0 B0, so its CMYK equivalent would be a profile-based conversion from RGB black to CMYK black):

To try more "PS-like" approach you might try the following: 1) Make the desired selection in one of the images (you can adjust the selection by using Q for quick mask, and the Move tool to resize the selection). When making adjustments to selection size, you might want to turn on snapping on whole pixels. (It is a good idea to change the decimal accuracy of pixel unit to 3 so that you can see from the Transform panel whether you have integer pixel alignment and width and height). 2) Make sure that the quick mask is turned off, then choose Select > Save Selection > To File to save the selection to a file so that you can load the same selection to be used with other images. I think this would be the closest to using the PS predefined selection width and height. 3) Make sure the quick mask mode is not active, then choose Edit > Copy Flattened (Ctr+Shift+C) / Copy Merged (Shift+Cmd+C). Then paste to a new image by choosing File > New From Clipboard. 4) Activate another image window, then choose Select > Load Selection From File, and select the previously saved selection. 5) Hit Q to activate the quick mask and then use the Move tool to place the selection frame at the desired spot, then deactivate the quick mask and choose the procedure described above to copy paste to a new image. You can use the same method for making selections with a fixed width/height ratio by using the quick mask and corner handles to scale the selection frame. You could then copy flattened and paste in an image window that has the correct final width and height and use the Move tool and snap to image edges to easily rescale the pasted images to final image size.

You first need to change the document color mode to CMYK/8 and pick the mentioned CMYK profile. You then need to select all objects that you need to have in K100 and change their color definition from gray to K-based (C, M, Y being 0). This should not be too tedious if you have text in long stories, or tagged with styles. You can also change formatting globally by using the Find and Change feature. When you export, make sure that you have CMYK (or document color mode) selected as color mode, and the document color profile selected as the target profile. If you have grayscale images, they should be usable as they are (and would be exported as "K-only" based, as device gray images, even when exported with a CMYK target).

It can be seen from the screenshot that you have 2050 x 780px in the document where you paste the image in focus, so in this context the placed image would have around 500 px width when the document is flattened no matter how it is placed (via Clipboard or File > Place). Affinity Photo shows any raster element using the document DPI so even if a hires image is reduced in size and has a high PPI value, it would look pixelated when zoomed in close (e.g. if an image that has a 1500 px width would need to be shown in 1 in width in a document that can show only 72px per inch). If it is an image layer that you have, you can see the PPI value on the context toolbar while you have the layer selected (with the Move tool), but if it s pixel layer, you cannot would see it grayed out but could not directly edit the value. PPI value would tell whether you can afford enlarging an image considering the document PPI value.

It depends on how you place it (and whether you place an "image" image or a "pixel" image). Here the source from a 300dpi document is saved on disk as a PNG image, resulting in 2016 x 1962px size bitmap. Then this file is placed in a 72dpi and 300dpi Affinity Photo A4-size documents, showing that the pixel dimension is retained (the image just looks much bigger in the low resolution 72dpi document). Additionally, the same image is also copied via Clipboard from the source document (where it is 300dpi and has 2016 x 1962px when rasterized to a pixel layer) to the destination documents, and here it can be seen that Affinity apps resize (by design) the image placed on the Clipboard according to the DPI of the destination document. So when pasting the same image to a 300dpi document, the pixel dimension is retained, but when to a 72dpi image, this results in reduced size of 484 x 471px. When copy pasting via Clipboard across Affinity apps, whether the resizing happens depends on whether an image or pixel layer is copied. If a rasterized layer is converted in Publisher to an image object, the source DPI is retained in image meta data, and the original pixel dimensions would be retained, even when pasting to a document with different document DPI. In this case this would result in having the same size of image pasted in a 72dpi document as the image file placed by using File > Place. UPDATE: I might have unnecessarily complicated the problem by showing behavior that might not be part of your specific problem, but since you appear to have experienced at least apparent reduction of resolution (understood as loss of details in the image), what I described above might be relevant. But I forgot the situation where the destination document has pixels as document unit (like you have in your screenshots): then placed and pasted raster images should directly be rendered using their pixel dimensions and complexities related to conflicts between document resolutions (DPI) have no effect. But as document unit can be changed simply by changing ruler units, this may easily happen inadvertently, and change of unit from pixel based to physical dimension based (like inches or millimeters), or vice versa, will change the way image data (including vector objects) will be exchanged and dimensioned when pasting between different apps (including Affinity apps themselves).

Alt codes only seem to work in Affinity apps up to 255 (and as mentioned a zero must precede the codes above 127), thereafter you can directly type in a hex Unicode [preceded by +U notation, so e.g. +UEA60] and press Alt+U to toggle between the code and the character within the selected font.