lacerto

I am not sure what you are reporting? If I did not miss something, we have seen identical behavior with Playbox and Patriotic5323, that is, b/w fallbacks producing color fonts on SVG or PDF export? This behavior was first described by @Alfred (for certain kinds of SVG color font), then by me (reporting that Firefox appears to render most kind of SVGs, Edge some, and Chrome none), and then there was my post describing similar behavior in context of PDF export. Is what you describe a new kind of case?

IMO it is basically a "mistake" to export to color font (SVG / PDF only, and supported selectively) when b/w fallback is used in the UI (on app canvas). This is how other apps not supporting the technology revert to what they actually can use, and also export it uniformly to all format. But I can easily see why many consider this at least a happy mistake as it makes the color version available (retaining text as text, and accordingly keeping the vector format).

You can also use the font and its b/w fallbacks and type whatever you wish and then export to PDF, and you will get color version of the font exported. If you want to have the font converted to outlines (e.g., to be delivered unchanged in vector format for editing to someone not having the font), you can convert font to outlines using Adobe Acrobat Pro or Ghostscript (there are other utilities, too. like above mentioned VectorStyler). A PDF with embedded color font can also be placed for passthrough and exported again. Or you can rasterize text containing an embedded color font. It appears that there are no legal restrictions on this specific font but what is described here are just applied use of the font outcome, so you could do this to any font without violating its copyrights as long as the font allows embedding. [NOTE: I tried PDF export for Playbox and it exported fine as a color font, but Emoji One caused an error, so once again, there are differences in SVG color fonts that determine how it can be used, especially in apps that cannot directly use full capabilities of the font.] svgfontaspdf_and_curves.pdf

Yes, I could reproduce this with Firefox (even for EmojiOne and the US Flag font): On Edge Playbox will be rendered in color but the other two will not, so it clearly depends on the kind of SVG font in question (these three are all SVG color fonts). When I opened the exported SVG file in VectorStyler (which supports SVG Color OpenTypes at least to certain extent), it rendered Playbox and the flag font in color. I could then convert both to curves and copy paste them to an Affinity app in vector format (below first shown as b/w fallbacks and at the bottom the curve objects from VectorStyler from Clipboard): PS. All these tests were done with Windows versions.

As a clarification: the sole input source language in my macOS keyboard has all the time been Finnish. The keyboard language does not seem to have anything to do with the issue. In my experience the crucial thing is the regional settings, but I have not tested if having e.g. Finnish UI language AND Finnish regional settings, might fix the problem. EDIT: I now have, and it does not. MacOS appears to have a kind of control-level check which does not exist on Windows, meaning that it seems the UI itself prevents the algorithm from getting "language-contradictory" input, but the code misfires, requiring US-English input in context of US-English UI, even if regional settings are non-US-English. On Windows it appears as if there is input format check/conversion only at algorithm level which correctly honors/processes regional settings, disregarding any other language specific setting: faulty formatting is just discarded and there is no autocorrecting, input-formatting using coloring, or any other kind of "(l)user-guidance".

It seems that this is not enough, or crucial. I have (on macOS) my Affinity apps regional setting as US English, and have US English also as my primary OS language, but had Finnish regional settings. Only after having changed the regional settings, too, to US English, the input formulas work right.

Yes, it only works correctly (and as mentioned) on Windows. I have not checked whether macOS even supports (or Affinity apps honor) things like user-defined system delimiters, and have not actually even checked if macOS uses culturally correct default regional settings for things like list separator. On macOS, either the OS or the Affinity app, knows better than the user and "autocorrects" or marks erroneous the default, correct regional settings, like semicolon as a list separator and comma as a decimal separator when using Finnish regional settings -- I do not understand why, perhaps because I "absurdly" use US English as my OS UI language??? But at the same time, user-written US English delimiters are not accepted, either. Anyway, I managed to get this working on macOS when I changed the regional settings to US English, and accordingly used the native US list separator (comma) and decimal separator (period). This, of course, requires restarting of the computer. I am not sure but it is possible that a these formulas need to be in US English format when used in context of Procedural Texture filter, and similar contexts, even if in UI controls regional settings are assumed.

The syntax is system region-dependent, so e.g. in Finland (and probably in Germany, too) the arguments need to be separated by semicolons instead of commas: clamp(49;15;30) would give 30. [And if you need to specify decimals, the separator is also system region-dependent, so in Finland, and probably in Germany, a comma instead of period] As for abs, as mentioned, it just returns the absolute of a value, so if you had e.g. negative x coord value -3 and you surround it with abs(), the x would be moved to positive value 3.

Affinity apps do support, at least partially OpenType sbix (bitmap based, basically only on macOS [EDIT: Also works on Windows, but Windows seldom has sbix fonts installed]) and COLR (vector based, both macOS and Windows) OpenType color tables, but not the most common SVG color table (which USA Spirit uses).

I found a few articles dealing with LUTs, color-quantization and dithering and will try to find something specifically related to the topic. This interests me because I am well aware of traditional quantization methods which are not useful when dealing with relatively low-resolution images (but which are high-res enough for the human eye seeing this kind of text as "smooth"). Anyway, what I have already demonstrated can be a timesaver in the task of abstracting text from colored background -- it is at least for me (I ran a test of applying the mentioned custom abstract ICC on a few pages of a couple of random scanned books and it worked very well with them with that single curves adjustment. Anyone is of course free to avoid presets, but I do not see the point of opposing them, or arguing against suggestion of making them more available to users, similarly as they are on Windows. But IMO the way Photoshop does this is preferrable, separating different kinds of profiles in context of color conversions, not making abstract profiles available in context of color proofing, and listing LUT presets and abstract profiles as adjustments -- meaning that they are not exposed without some consideration.

Ok, good to know. The document referred did not specify any clear press-specific specs, nor did it accordingly give any instructions on how to meet such specs when producing with Affinity Publisher, so therefore I assumed that they do not have any strict requirements e.g. as for live transparency or color mode, color profile, or PDF production method.

I was referring to possibility to try multiple LUT or ICC based curves for different "standard" situations as kinds of presets, or possibility to combine them with e.g. Curves adjustment that shifts the basic "abstractor" curves to make them work in a bit different situation. Like below, but as far as AI is involved, programmatically (here the abstract ICC I attached above creates reasonably good results after having been adjusted with a Curves adjustment), in Photoshop: You could have alternative abstract ICCs created for the same purpose and used in multiple (alternative) Soft Proof adjustments on top of each other to find the one that serves best for a specific purpose. External "abstractors", as LUT .cube or abstract .ICC files can also be useful to deliver adjustments across different apps (and app versions) and between users. I do not understand why either of these assets should be avoided as too rigid, even if they do not have controls of their own (like Photoshop has, e.g. dithering), since they can be tuned by using other adjustments, as in the example above where an abstractor removing the chroma is adjusted with a single Curves layer. You could have any number of adjustments added but then the point of having one basic abstractor doing reasonably well the basics is kind of lost. Abstract ICCs can be used in any of the three Affinity apps as a Soft Proof adjustment. I am not sure about the best possible use but as far as the document DPI is high enough, you could export or rasterize an abstract ICC along with other adjustments once satisfied (so you do not need to start by first converting to Lab color space and choosing a specific abstract ICC). In that respect they clearly differ from Output Device ICCs that are used e.g. in context of photo printing and where the Soft Proof adjustment needs to be turned off before production. I do not see abstract ICCs as a one-click problem solver, but they, similarly as LUTs, can be a good starting point for a kind of a task OP wanted to have, and both can be created to suit anyone's custom needs and purposes (LUTs can be created from adjustment layers in Photo, and in all Affinity apps by inferring, comparing the source and adjusted export files, and abstract ICCs can be created by using e.g. the above mentioned low-cost tool). If Photoshop makes them easily available (I just had not realized that Abstract list in the Color Lookup referred to abstract ICCs), then why should the feature be obscured in Affinity apps?

I know very little about AI so I use the term vaguely to refer to any kind of algorithmic based examination of source, and estimating the best possible means to get desired results, including some retrying within specific limits, and comparing results, and then offering the best possible as alternatives, and possibly saving feedback to be able to offer "most wanted" results as defaults. IMO that is basically what user-fed and controlled service has always done so not probably AI... I would imagine that it is possible to programmatically apply adjustments (e.g. using Photoshop scripting) that could apply the kinds of curves that produce LUTs that aim at abstraction of "black(ish) text from "paperlike" (to some extent recognizable by the color/tones differing from the text) background, and then apply these to a sample scan and evaluate the results (with user feedback if necessary). So using this kind of approach it would be possible to use alternative, on-demand-created LUTs (or abstract ICCs) and try multiple to achieve the goal. This would be different from traditional quantization or thresholding, and ideally end up in the quality shown in posts by @NotMyFault and @David in Яuislip. UPDATE: Just looking at the Lab curves of the LUT-based abstract ICC using Apple ColorSync utility, I wonder if it is possible to programmatically run tests just shifting the curves a bit, to have them work with "slightly" different papers and text contrast... Possibly not, so a different set of adjustments might be required, created from the scratch (though of course with similar parameters)...

I had another look on abstract ICCs and exported a LUT of the series of adjustments created by @NotMyFault and described above (the original post also contains an attachment where the procedure is applied on one of OP's example scans). I then used the LUT in above mentioned LittleCMS Color Abstractor to create an abstract ICC and applied the created ICC to the same scan. It was interesting to see that while the created abstract ICC (attached below along with the LUT) seems to work well in Affinity Photo 2 and does reproduce pretty well the results of the adjustments when applied to the same image, it works differently when applied on the same image as an abstract ICC in Photoshop (CC 2024 tested). In addition, when applied in Photo 2, it seems that LUT based conversions / transformations, are too specific, so when applied on tasks where the goal is to quantize (reduce tones), the results may vary greatly just for relatively small changes in the source, so when applied e.g. on different scans of the same source, or different pages of the same book, results may vary too much from scan to scan and page to page. Using AI in tasks like these might significantly improve the results and probably AI is already used for this purpose. Nevertheless, it was good to see that an abstract ICC can basically reproduce the effect of a series of adjustments saved as a LUT -- at least when the app creating the LUT and applying the abstract ICC created from it stays the same. As for Affinity apps, it would be easier to just share the LUT which, when applied in Photoshop, would give similar if not identical results when applied as an abstract a LUT adjustment: Perhaps someone with more experience with LUTs (or abstract ICCs) can tell why this difference between these apps (and possibly other apps supporting these features) exists, but the Photoshop Color Lookup functionality directly shows that abstract ICCs and LUTs are used for identical purposes. RemoveScanYellow.icc Yellow2BW LUT.cube

Little CMS was already mentioned earlier in one of my posts as the creator of Apple abstract ICCs, with the link to their web site, so i am not sure why there was need to notify me of the address being included also in your list of addresses? I wanted to pinpoint them just to give something concrete, and demonstrate how simple creation of abstract ICCs is 🙂

I agree. I did not know about abstract profiles earlier, and while it is true that there are far more well-known and more effective and especially shareable methods of achieving similar results, it does not harm to stay curious and learn something "new" -- in quotation marks because it seems that abstract ICCs are not anything new. Based on the fact that many if not all the abstract ICC samples distributed on macOS seem to be created by the same company doing business in the field of abstract ICCs, Little CMS, and that these profiles appear to have been created already in early 2000s, and that Photoshop appears to have supported abstract ICCs starting already from CS4, the technology has been there now for well over two decades. I had not noticed existence of this feature because it is kind of "hidden" as a separate list in Photoshop, and probably very few have noticed its availability in context of Affinity apps because of poor accessibility of these profiles. But I think that they might have some use especially in context of non-destructive soft proof kind of UI with endless capability of combining whatever is primarily achieved with an abstract ICC with other, still more "experimental" adjustments. Personally I think it is good that Adobe implemented this feature separately from other kinds of ICCs (where results are exact and based on ISO standards), and also separately from color proofing, where reasonably predictable results can be achieved with specific manufacturer and production profiles even if adjustments are applied manually and based on perception. The whole concept of having color profiles in context of Lab color mode (a "profileless" color space), is a bit confusing, so in this sense having these profiles listed amongst Soft Proof adjustment is likely to blur the underlying technology (and whatever is achieved by using accurate Lab to Lab calculations), and make the whole feature a kind of a hobbyist widget. But then again, has not the feature now reached a proper home having been exposed in the realm of Affinity apps 🙂 ...which was of course basically just a hunch, and as mentioned above, I am not personally into this kind of approach, either. But it might offer some basic means of achieving kinds of goals initially asked by OP and not entirely off topic. One often learns new things by trial and error, and taking a few side steps. My initial interest in the topic arose because of @David in Яuislip's post, however apparently "Luddite" but nevertheless based on experience and understanding of underlying (analogue) technology, and getting excellent results effectively and elegantly, rather than as a result of "experimenting" with multiple adjustments and controls. So in that sense, looking into something possibly simple, achievable e.g. with a self-made absolute ICC profile with a tool costing EUR 3,95, seemed worth an effort:

They are just symmetrically in /Users/<user>/Library/Application Support/Affinity Publisher 2/profiles /Users/<user>/Library/Application Support/Affinity Designer 2/profiles I suppose version 1 profiles are just in equivalent folders but probably without a version number in folder name. Versions purchased from Apple Store might have profiles in different locations, or might be able to read from general system locations?

Yes, exactly like this.

Here is a demo of usage of abstract profiles installed on macOS (Sonoma) with Affinity Photo and how they can be previewed in context of Softproof Adjustment (they can also be used for direct conversion, but would be more useful as adjustments so that they can be tuned before flattened and rasterized): abstract_profiles.mp4

It is probably that the profile is not available to your Photo app. Try to make it available by using File > Import ICC Profile command of Photo. I am not sure if the location the ICC profiles are placed differs depending on whether the app is from Affinity or Apple Store, but I have Affinity store versions, and then the profiles will at least be available at: /Users/<user>/Library/Application Support/Affinity Photo 2/profiles ....and for other Affinity apps, equivalent app and version specific paths. I renamed the two Black & White profiles as Black & White Gray and Black & White Lab using Color Sync Utility App, and can now use both Lab and Grayscale based profiles independently, so not having both accessible previously was just a name conflict. As for Adobe Photoshop, abstract profiles are available in context of profile conversions as a separate list, and all installed abstract profiles (like Blue Tone, Gray Tone and Sepia Tone) appear to be automatically available (as for Affinity apps, I think that at least Affinity Store versions need to have these profiles copied under the user Library, as described above). On Windows all these profiles are installed in one common place which makes their use much easier (but naming conflict can make e.g. Proof Setup inaccessible). The concept of abstract profiles was new to me so I am not sure how they are typically used. The Lab based Black & White profile would appear to be useful also as a Softproof Adjustment to get a reasonably realistic preview of monochrome output, and when making an actual conversion, the result will be pure black and white image (even if of course not a true monochrome within Affinity ecosystem). But I am not sure if this is "intended" or "typical" use since Photoshop does not allow using abstract profiles in context of Proof Setup. Anyway: this was one step forward in understanding different kinds of ICC profiles and how they are supported and accessible in different apps, and realising that naming conflicts can become an obstruction but be easily resolved with Apple Color Sync Utility was useful. bwprofiles.mp4

They are not. The one I referred to is "Output Device Profile", while the Apple one that comes with the OS, is "Abstract Profile". The latter are primarily useful in context of Softproof and miscellaneous image manipulations, and in RGB color space (more specifically in Lab color mode). They can be potentially pretty useful in tasks like in this thread, abstracting black and white content from a color image (e.g., below, a pretty good conversion can be achieved just by applying the Softproof adjustment and then increasing the Gamma): The Apple Black & White profile becomes also available in context of definition of color profile when creating a document in Lab color mode, or when converting to Lab. Interestingly, when embedding this profile and viewing it in XnView MP, the displayed information shows that the profile creator is actually the same as that of the Output version: Little CMS. It seems that I cannot use the Apple-specific abstract profile in Photoshop, at all -- it may of course be just a name conflict (as both profiles have an identical name even if different filenames). Both profiles, however, can be equally useful in the kinds of tasks presented in this thread.

It is acsp, which appears to be an acronym for "Apple ColorSync Profile".

Ok, I see. The version I use on Windows and also on macOS in context of Affinity apps appears then to be different from the Apple one in /Library/ColorSync/Profiles, and which cannot be used with Photoshop. The profiles just have the same name. I am not sure if the four-letter profile file signature is somehow Apple-related, though. Also, I have no idea where I initially got the profile -- perhaps it was something that cane with some older Adobe software...

It is on my MacBook Air (original M1 that came with Big Sur, currently Sonoma 14.2.1). Affinity store based apps do not read if from /Library/ColorSync/Profiles so I need to place it in my user Library and separately for each Affinity app to have it available. But what is stranger is that Adobe Photoshop 2024 macOS version will not read this profile no matter where it is placed. I think that this profile is basically intended to be used in context of Softproof, and in RGB color space, to create levels for monochrome printout. For some reason it does not work with Affinity Softproof Adjustment, possibly because of the monochrome reference (as this color mode is not supported in Affinity apps), even if it does show grouped with press / device gray profiles in other profile contexts (and can be used). In context of Windows Photoshop (2024 and earlier) it works and basically allows determining threshold for black and white using e.g. the Levels control, so I am not sure how useful the profile might be... It could basically allow the user to set levels of a color image and output it to a monochrome device without needing to convert the image color space... You can try to get more information from the creator of the profile: https://www.littlecms.com/

Check if this fixes it. The links were created using Adobe Acrobat Pro 2020, but I think they could be easily created also with PDF-XChange Editor (available only for Windows, but a perpetual license at about EUR80). PS. I replaced the original as I forgot to add link on pages 2 and 4. I tested also PDF-XChange, and it was even easier with that tool as it could paste a link exactly on the same location on successive pages, so it needed to be placed only once. 2024-clock-MY-VERSION_fixed.pdf