lacerto

Contrary to common belief, it does not cost anything to have digital swatch libraries for PANTONE colors. Just visit their site, create a free Basic account (there are of course no guarantees but the basic features seem to be permanently available for free), and you can create and save up to 10 named palettes each consisting of max 40 swatches from any of the 16 PANTONE libraries and over 15,000 colors (including e.g. 2023 colors and colors of the year and other fancy stuff) and download them as an sRGB image to be used for creating custom swatches in your favorite app. If you have Adobe account, you can additionally use free account with PANTONE Connect Plug-in, which has some extra uses and can automatically load palette images e.g. into Photoshop. By using the downloaded bitmap, it would then be easy to create permanent palette libraries, including spot color palettes. Below first 10 of the 2023 swatches have been used to create a spot color palette: The color representations are limited to sRGB but that is not an issue for most uses, and does not prevent use of e.g. spot color swatches. Swatch names and sRGB information is all that is needed to create spot color swatches manually. For some reason in version 2 of Publisher, I could not subsequently export an Affinity palette so that it could be imported as a document palette for any Affinity document (only Windows version tested). Version 1 apps do not show this problem. There has been much ado about (mostly) nothing as regards changes in availability of PANTONE libraries but the actual impact seems to be insignificant to most users. Premium account allows limitless palettes and operations and useful tools (e.g. for conversion and lookup) and palette maintenance functions (which probably continue to be available for Adobe users since the available features are not PANTONE specific and also do not limit use of legacy libraries) would not be a significant cost to anyone needing these libraries professionally. Most Adobe users can continue to use their old libraries as if nothing had been changed, and will have free plugin-based access to new swatches should they need them. General access to PANTONE swatch libraries has become more restricted and clumsier, but in color managed environment accurate color references are customarily given in profile or Lab context so significance of trademark color references has diminished. Those who really need custom inks would typically get printed references anyway.

I might have formulated this badly: I mean exactly opposite, to be able to keep live transparency, you need to have PDF/X-4 or any non-PDF/X-based method (which in Affinity apps is always 1.4 or later; Affinity apps do not support PDF 1.3 which would make it possible to flatten without resorting to PDF/X-1 or PDF/X-3 which are the only export methods that automatically force transparency flattening. They both also force native colors to CMYK. I have not tested this intensively but in this instance I switched the blend mode color space in InDesign to RGB which produces greenish Screen mode blend for upper "Proyeccion Astral" text that has C=75 M=5 Y=100 K=0 (or its RGB conversion, there is no really difference) as fill color against the RGB bitmap (as can be expected), and then continued exporting to PDF/X-1. This has no visual change on canvas (within Publisher), nor does it have change even when exporting to RGB, with all elements of the PDF being in RGB color space: blendmodes_from_doc_rgb_purergbvalue_rgbred.pdf Note how in InDesign just changing the transparency blend space makes the blend look pretty much like blending done by Publisher: blendmodes_id_flattened_pdfx1_cmykflatteningspace.pdf As you mentioned, blending in different color spaces gives different results. It is of course important, too, that somewhat predictable results are shown already before actual export.

Note that Affinity apps are pretty much out of their depth when using blend modes and needing to ensure that flattening works (that is, not leaving flattening to the printer by using live transparency in PDF/X-4 or any non-PDF/X-based productions). If you need to use live transparencies, always ask RIP proofs. Compare e.g. the following PDF/X-1-based PDFs produced from InDesign and Publisher (transparencies flattened): blendmodes_apub_flattened_pdfx1.pdf blendmodes_id_flattened_pdfx1_rgbflatteningspace.pdf Some differences that ID does and Affinity apps do not: 1) Flattens without rasterizations. 2) Keeps the text. 3) Lets the user choose blending space (above RGB) yet produces seamless blends without antialiasing. The effect depending on blending space is quite different.

Odd thing. It seems our system specs and files are identical, yet I can consistently experience the following: Artboard_PDFs.mp4 I even rebooted the computer and started a fresh session of Designer 2, and placed all the files in my Documents folder (they initially were and are on the video clip under Shared folder but nevertheless on the local disk). There is also that odd version of the first instance of the page 1 on the first page -- I think that sometimes the distorted page shows on page 3 so that at times all pages are not instances of page 1, but there appears to be some memory corruption.

Illustrator (already at least CS6) can do that, and I think that QuarkXPress can do that. And VectorStyler can now manually flatten other cases than blend modes overlapping regular opacities (but they divide those shapes so applying the opaque value would not be too hard). There might also be other prepress software that can do that.

One further point: the only kind of transparency that Affinity apps do not rasterize when flattening is done is one applied via "Opacity" setting of the color panel and that does not overlap with any other color. But transparency that is applied via Layer panel or as a blend mode, will always be flattened using rasterization, even if there are no overlapping colors. So below you have above the yellow circle not overlapping other colors with a transparency that is flattened while keeping the vector format, while the circle on the bottom part is flattened by retaining the vector format. All other overlapping transparencies are flattened by using rasterization. The export format was PDF/X-3. transparencies.pdf

Hi @nolamike. I can reproduce your problem exactly on macOS Ventura 13.1 and Designer 2.0.3. artboards_and_pdf_pages.afdesign pdfpages.pdf

Affinity apps cannot unfortunately flatten transparencies using vectors, but instead do it by rasterizing transparent areas whenever transparency flattening is required. This happens whenever you export using PDF/X-1a:2003 and PDF/X-3. If you want to use live transparency, please use PDF/X-4 or any non-PDF/X-based export method (they all use PDF v.1.4 or later that support unflattened transparencies in PDF). If you need to use PDF/X-3 (by request of the printer), but wish to keep all shapes in vector, the only method would be flatten the transparencies manually (e.g. by dividing the transparent regions and then manually applying opaque color values).

In case this is still an open issue, the only built-in spot color palettes in Affinity apps are the following three: ...while you had selected swatches like "P 12-6 C" from "PANTONE+ CMYK Coated", which is a process color palette: Spot colors are marked by having a tiny spot on the bottom right corner of the swatch, and having that (inaccurately translated) "Point" written in the "Couleur" panel whenever a spot color assignment is selected.

This was originally posted as a reply to a PM related to version 1 related thread, but as it is relevant to versions 2, as well, I created a new post with a link to the original thread (I am not sure what would be the preferred procedure -- just continue an old related post?).

@EatMoreBacon -- I reply here (instead to PM) as the question related to color fonts in context of data merge (as a device to encode color attributes) might interest other users, as well. You can basically use any color font to pick and encode color attributes to be used with merged data. Ideally the glyphs to be used should be ones that resemble color wells and consist of coherent color regions. If they have details, borders, etc., you can use vertical and horizontal scaling and aligning to use just a specific area of the glyph for coloring. Two free color fonts that work with Affinity apps (which have only rather limited support for color fonts) are Segoe UI Emoji and Apple Color Emoji, which can be used in the attached demo (this is for Windows; on macOS, the font should be changed to Apple Color Emoji, it has its color wells encoded in the same Unicode code points as Segoe UI Emoji). colorcells.xlsx colorcells.afpub colorcells_merged.afpub Some of my other posts in this thread use my own fonts that only consist of color wells, which are used to create a basic sRGB kind of palette (but only consisting of 10 instead of 255 shades per channel; and equivalent CMYK palette) which I then use with blend modes to mix 10 x 10 x 10 = 1,000 shades to be used in data merge tasks. The method is a bit convoluted but if someone is interested, I might be interested to explain and share. But basically the same can be achieved with any color fonts; it is the encoding (finding the glyphs to serve as palette wells) that would be a bit tedious, compared to a specific font that consists just of a "palette". I have not managed to find such color fonts -- if someone knows, please post!

That may be necessary if people keep on asking time even if they have a fancy watch of their own 🙂

Yeah, it was predictable. A simple thing can be made incredibly complex in this ecosystem (without a simple and good recipe; there are of course such available, and free of charge, but I just could not help myself).

(...removed as redundant...correct answers were already provided and they work twice a day.)

IMO Affinity Out of gamut feature in context of Soft Proof adjustment is broken (has always been). If the feature is intended to be used in context of manual adjustment of off-gamut tones (e.g. using things like saturation control), it is clear that it should take into account different rendering intents in situations where these would be applied when the image is sent to printer and the printer takes care of color management (the procedure that is simulated when performing soft proofing). Manual adjustment could then be used to improve handling of single off-gamut color areas or tones so that they would still stand out (in case they would be muted by using standard rendering intents). On the other hand, if color management is done fully in software, then soft proofing would basically be unnecessary (other than just previewing targets in situations like checking adequate contrast in grayscale output, or determining similarity or difference of colors in RGB and CMYK color spaces). The Soft Proof adjustment of Affinity apps has also a silly flaw as it would show the out-of-gamut warning color (instead of underlying image color values) when examining the image color values (e.g. using the Info panel of Photo). I use X-Rite instead of Spyder so I cannot say why Spyder might be behaving similarly as Affinity apps, but IMO the way Photoshop behaves (rendering intent having effect on showing out-of-gamut color values) makes sense.

It seems that you have mixed OpenType glyph-based subscripts and old-style non-glyph-based (forced and font-specific) subscripts in your example, and that explains the fluctuation in sizes and positions. a) This is pure old-style, using the font-specified setting (which InDesign lets adjust as per document using a Preference setting): This means that standard glyphs that are wanted to be super or sub scripted are just made smaller and positioned so that this styling is universally available for any glyph within a font without needing to specify different font size or character shift [or needing a specific glyph like in method b] . This is basically the easiest method to apply subscript and superscript, but typographically often less satisfactory. EDIT: In lack of InDesign-kind of control, you can combine this with character-style based formatting like shown above by @anto to get better and more consistent formatting. b) This is OpenType based and glyph-specific subscript (notice the enabled setting in the Typography section below), and you get it only if such styling is available in the font: E.g., in Arial (at least the version I have installed), there is no subscript glyph for 2 or 4, but a bit surprisingly there is one for lower-case x. You basically should not use this method if you need to subscript or superscript characters for which there is no specific super or subscript glyph (and there seldom is for other than numbers and such characters as a and o etc.). You could of course use method a) for characters which do not exist as sub or superscript glyphs but this often produces uneven results. c) Achieving subscripts by using vertical and horizontal scale (below 80%) combined with vertical shift (below -2pt), and creating a character style that applies these formatting exceptions: The equivalent method would then also be used for superscripting. This method might be a good way to work around typographic issues and apply coherent styling, and it would also make it possible to have consistent font size throughout the text and automatically replace subscript and superscript attributes with a character style. This would be better than using different font sizes to format sub and superscripts as that would show as an inconsistent size usage when having all characters of a paragraph selected. EDIT: Note that effect of auto-correct feature as regards ordinals and superscripting would not typically affect typing of these kinds of expressions, as they would affect things like typing 1st, 2nd, 3rd, 4th etc. and letting the app to automatically use superscript styling (method a) for these parts. But the setting is language-cognitive so you might be accidentally getting e.g. e-characters superscripted when typing French text in combination of numbers, e.g. when typinig 2e, 3e, 4e, etc.

Perhaps you should ask Serif. Just watch the video. A new document does not have a document palette unless the "Default" feature is used to specify that an existing document palette (in any document) should be used as the document palette for new documents of the specific color mode.

I am, because Serif chose to not make the loaded document palette the active palette. But I do not need to save the "default" palette as an external file and pick it from the file system to have my standard global swatches available whenever I create a document of specified color mode. EDIT: The document palettes are listed at the top of the palette list, separated by a line: To illustrate this, I have manually created above two other document palettes, in addition to "My Preferred Palette", which is the default palette that gets automatically loaded whenever I create CMYK document.

Perhaps something like "Load this palette as a document palette whenever you create a new document of selected color model, but do not bother to make it active" 🙂

Perhaps we are talking about different things, but what do you think that happens here? global_ colors_in_the_default_palette.mp4 The exactly same thing happens (for me) on macOS. And on both platforms and with both 1.x and 2.x versions.

I think it is a poorly selected term. But perhaps the palette was designed to be activated, too, but the feature just is not properly implemented.

I would rather define a few default palettes and have them available with any kind of document (disregarding the format etc.), possibly with just color mode specific variations, than creating various templates using different formats just to have a standard palette available. Interestingly default palettes do not seem to be loaded with a template based new document (of the defined color mode). Perhaps this is a bug (only tested v2 apps on Windows for this feature).

I have tried to explain this above. But try to create a custom palette that behaves like a document palette so that you can have global swatches included (they are needed to be able to apply Overprint attribute, and to be able to create parent-child tint relationship). Application-wide palettes cannot have global swatches. It would be useful if Serif improved the feature so that the user-defined default palette would also be automatically selected as the active palette whenever creating a document with a specific color mode. Perhaps this happens one day, but I'm not holding my breath.

The point is that "default" palettes can behave like document palettes when creating a new document. Application palettes do not have capabilities of document palettes (as mentioned above).

1) Whether a palette is loaded, depends on the color mode. This allows to optimize to some extent print-specific, gray and digital media palettes. 2) By specifying a palette as "default", you can work around the limitation of application-wide palettes not having a capability of having global swatches (and accordingly, parents of tints, and have an overprint attribute). [That is, the "default" feature allows document palettes becoming kind of color mode specific application palettes.]