lacerto

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

Yes, but I can see your point. E.g. as far as I can see No style does not determine OpenType features, and I have understood that this means that the style does not specify whether a specific feature is on or off, and accordingly, the attribute is indeterminate, and therefore has a dash: However, if I have manually added e.g. a slash zero and then use "Apply Test to characters" (having the slash zero included in the selection), the slash zero is reverted to regular zero even it is not defined in the underlying paragraph style (it is not turned on or off, but left indeterminate). (E.g., in InDesign, OpenType features are explicitly on or off, when being part of paragraph style definitions.) What is worse is that if I apply another paragraph style (which does not explicitly specify that slash zero should not be used, either), the slash zero will be removed just by applying the paragraph style without asking to remove overrides or apply styling to characters. This does not happen in InDesign (I am not sure about QXP), but this behavior of Affinity apps makes it basically an obligatory task to fix local formats with character styles, to avoid catastrophic formatting errors. EDIT: Correction, this actually does not happen in situation of "indeterminate" attributes, unless styling is explicitly applied on characters; but it happens with determinate attributes, so local "conflicting" attributes are lost by simple paragraph style attribution. I am not saying that Affinity apps define styles "incorrectly" or "illogically", but it is good to understand that there are significant differences between different apps.

More generally: Affinity apps are far from being consistent in their use of UI to signal mixed state of attributes in selections. Just compare this InDesign view expressing more or less consistently indeterminacy or mixed state in UI for a selection that contains multiple attributes: a) InDesign: Note especially how the Color panel indicates indeterminacy (even is also showing color values of a partial selection), and has the underline and superscript buttons in off state (which of course is not accurate, either but IMO better than having them in on state just because part of the selection has these attributes applied). b) Affinity Publisher: Note how the Bold and Underline buttons are on (while Italics is off), and how Super/Subscript box says "None" instead of being blank. No break box would not express indeterminacy, either, even if it is a check box, and OpenType features do not show indeterminacy, at all. It would be possible to use checkboxes instead of radio buttons whenever such functionality is needed, and have radio button behavior created programmatically (which is also Apple recommendation in XCode documentation, to be used instead of radio buttons even if indeterminate is available also with radio buttons). In general, use of indeterminacy / mixed state in UI is a thing that requires programmatic involvement, so whether an app shows this or not is much an indication of maturity and culture awareness of an app. I think that Apple (and any software company with some history and culture) still cares about these kinds of things, even if there is no longer quasi-scientific agenda behind to back up idiosyncratic choices like one-button mouse, bottom-right-corner only window resizing, etc.

I think that the dash is also used to indicate indeterminate state. That means: it does not indicate actual presence of mixed states, but that there is no underlying rule that determines whether a certain attribute is on or off.

Does the resulting grayscale TIFF look like off topic? 0630gray.tiff

Note though, that if you actually opened the PDFs, as far as I recall, you mentioned that your scores are in RGB color mode. When you open a PDF for editing in Publisher, you can let Affinity estimate the document for correct color mode, or you can force a specific color mode. Disregarding of what you choose, the original color definitions of the opened document will stay, so they would be RGB 0, 0, 0, and only appear to be four color CMYK (something like shown above) when viewed e.g. in Color panel. You can see the true color value if you temporarily turn off the lock in the Color panel (you do wisely to normally keep the lock on, so that you do not inadvertently convert colors of selected objects). This means, too, that you should look for RGB 0, 0, 0, instead of the equivalent CMYK conversion, to be able go through all your objects. See below how this would work for this demo score: findreplacecolor.mp4

In version 2, you can select all objects of the whole document by specific type (e.g., text, shapes, etc,), and then apply common attribute, like value of fill color to them: Or, you can select one object, and by using its one attribute, like fill, to select all objects within the document that use the same value, like color, in that attribute, and then change the color to something else: In version 1 of Publisher, the Select feature is available only via Designer Persona, but it does not select objects document-wide but just page-wide, so you would need to repeat the process for each page. If I recall right, you ended up placing PDF documents (either to be passed through, or interpreted), rather than open them, in which case you could not do this. This would be possible only if you have opened the PDF(s) for editing. If your printer is willing to do this for you, I would recommend leaving this to them, especially if this is a job where RGB 0, 0, 0 (which would appear as four-color CMYK if viewed as a CMYK simulation) needs to be converted to K0. EDIT: Note that since your notation is practically "text" (as it is laid out using fonts), you could actually use Find Replace and use its Format feature to find all text that uses common Fill / Stroke Color, and then replace it with another Fill / Stroke Color, and you can do this document-wide even if you have "text" in separate frames, and you can do this also in version 1:

It does not need to be a character style, it is enough if no break attribute is active in the position where text is placed within an existing frame, and if it is an attribute last applied on any frame, it will also become an attribute of a new text frame that is created when a Word document is placed on canvas. I am not sure if No break exists as a Word attribute: non-breaking space of course does (and is imported), and probably some other non-breaking glyphs, but they do not cause the same non-wrapping behavior as no break, but just forced word breaks at (probably) random points.

Odd. My only advise would then be to resize the document page size (trim box) to match the physical sheet on which the dot grid will be printed. E.g., in the attached file, the original page size of 7.5 x 9 in is changed in Adobe Acrobat Pro to US Letter (8.5 x 11in) without scaling the original art (that is, centering existing content by adding 0.5 in to horizontal margins and 1 in to vertical ones). Test 2_letter.pdf

Thanks for the update. This was an instructive thread, because the job at hand appeared to be very simple, and what was confusing, was basically the very different way Adobe InDesign and Affinity apps handle "grayscale" (or basically, press-oriented black). InDesign does not basically offer "grayscale" color model at all, but uses instead Lab for specifically light intensity oriented color definitions, and for print intent documents always handles "gray" as K ink. So it is very straight forward. Whatever is defined in print intent document and using the factory default {Black] swatch (including tints) will end up on K plate when exporting to press, and stay "grayscale" in that sense. Similarly, imported grayscale images will aways stay on K plate, there is no need to explicitly tell that gray is not a composite RGB but needs to be treated as black ink. What however was particularly confusing was bringing in PDF/X-1a and combining it with concept of grayscale, and specifically in context of InDesign, since when using this standard, conversion to grayscale proper is not available at all in InDesign (at least up to CS6), so to be able to produce specifically grayscale PDFs, anything else than PDF/X-1a needs to be chosen! PDF/X-1a is often asked for the purpose of guaranteeing that the job will be in CMYK-only color space and will not contain live transparencies, and is therefore a kind of fool-proof export method. So, to wrap up, what seemed to have happened was that as you had a pure b/w press-oriented job, you initially chose the Gray/8 document color mode and assumed that text and native art is safest to specify in CMYK, using K ink only (as you would do in InDesign or Quark, where gray is not even available). Which in Affinity apps is wrong, since K would be handled as an RGB value in a grayscale document and would end up being either a four-color black or a diluted black (dark gray) depending on whether exporting to Grayscale or CMYK. So: in a Gray/8 color mode document, you need to define blacks (text and native art) that are intended to end up on K plate, as Grayscale or RGB color values, and make sure that you also export using Grayscale color mode (using CMYK at export time would convert grays to four-color black). Placed grayscale images would also be converted to rich black. Using PDF/X-1a in context of a grayscale document, would work if you had press-oriented grayscale profile available (which Generic Gray Profile or D50 are not), so in this sense the color preflight warning that you would get trying to export using PDF/X-1a in context of a grayscale document, is correct. You will end up having four-color blacks if you use PDF/X-1-a:2003. The next step you tried was probably switching the document color mode to CMYK/8. You already had your text and possible native art defined in K100 so it would seem obvious that you will have correct output having K-only color definitions and placed 8-bit TIFF grayscales. But no, your placed TIFFs would now be exported using four-color-black, as they would be treated as RGB images within Affinity apps whenever placed in Gray/8 or RGB color mode document, but handled in CMYK context, and would be exported as rich black when exporting to CMYK. Using PDF/X-1a would not change anything here. At this stage, at latest, you might have heard an instruction from the printer to produce in true "grayscale", in the meaning: everything on one/black plate. The trick, in Affinity apps, is to apply the "K-Only" button on all placed grayscale images. This would not be done when placing these images in other than CMYK document color mode, and it won't be done automatically if switching the document color mode to CMYK. The button is also visible on the context toolbar only when using CMYK document color mode, and unfortunately you cannot apply "K-Only" for all document images at once, but need to go through images one by one and make the change. Note that when you have a document color mode in CMYK, placed grayscale images do have K-Only button automatically applied (and the mode will be retained also if you subsequently switch document color mode even if the button itself is hidden, which would also change the way these images are treated in these alternative document color modes when exporting to different color spaces). After this, you would finally get what you need: "a simple grayscale" job where what you have defined in K-ink only and with imported TIFF grayscales, will be delivered as expected on one (K-plate) only (whether exported using PDF/X-1a or not). You should additionally be careful not to change color profile at export time, since that would, again, convert K-only colors to four-color values. [ALSO: It is good to remember that letting Affinity apps embed ICC profile in the document (= default), will produce an ICC-dependent PDF where using wrong simulation profile will show incorrect CMYK values in Adobe Acrobat Pro so there is still this additional confusion related to complexity of defining black ink values within Affinity apps.] Part of this is related to clash of different technologies and underlying color engines, and terminology (some say "cultures", but I personally disagree), and the fact that you are not likely to get proper instructions from printers / print shops. The Affinity apps are also under development, and there seem to be recent changes e.g. in the way placed CMYK images are treated when they contain embedded profiles (nowadays they are discarded similarly as by default in InDesign). How could anyone expect to get step-by-step instructions from a third-party when they are not provided even by the first-party, practically ever?

It is possible, since I initially created this file in Illustrator and used a different blend mode in each rectangle, and additionally applied 50% opacity for all objects. There were no groups initially, but I saved this file as SVG 1.1 from AI CS6 just to see that Illustrator at this point did not export blend modes in any of the attribute encoding styles (I am not sure if CSS Level 3 and blend modes were even developed at that time (around 2011). Anyway, I think that I opened one of these SVG exports in Designer and then exported directly to SVG again to see the differences. I thought that I had checked from the code that there were no blend modes but just opacities. I, too, tried to manually reproduce the strange random rasterization using similar group and passthrough inherited opacity values, but could not, so perhaps this is somehow more or less a unique case.

I am not sure what you ask... This scenario was already explained and demonstrated above: having a Gray/8 document color mode, defining colors in grayscale or RGB (virtually same) and exporting using PDF/X-1a method to produce DeviceGray output (no ICC-dependencies, but just output intent description, so nothing to be resolved), the crucial thing being ability to choose a press-specific grayscale profile (which has to be fetched and installed separately). Obviously OP did not have such a profile installed so they were not able to produce such a file, so in lack of an appropriate profile, the ICC profile field is left blank, and Affinity app will use the app default US Web Coated v2 as the target profile, resulting in all black definition becoming converted to four-color black. So OP ends up using a workaround, producing PDFX-1a in CMYK document color mode with K-only definitions, producing DeviceCMYK file on mere K plate, and converting the file afterwards to Grayscale 1-ink file. As mentioned, the printer's requirement appears to be unreasonable, but it is possible that they have been offered grayscale exports with 4-color black, and PDF/X-1a CMYK exports with 4-color black, either as a result of profile conflict (document vs. export time), or because of PDF compatibility violation (and resulting rasterization), etc. Or, because of having been offered an ICC-dependent file (even if otherwise meeting the specs). Some printshops have automated preflight checks that may discard a job for practically irrelevant reasons. So the advise given for "Grayscale" might have been a reference to need of having one ink (grayscale job), whether DeviceGray or DeviceCMYK with K plate only, and with no ICC-dependencies. PDX-1a is probably referred as for requirement of needing to have transparencies flattened. As explained in many posts on this forum, this primordial requirement is probably made in sincere belief that it is easy to achieve, and that it is a fool-proof method of guaranteeing expected results on paper (as basically what the client sees is what they get, since nothing will be left to be resolved at RIP-time). But within Affinity ecosystem, depending on complexity of publication, producing PDFs meeting these kinds of primitive specs, can become a challenging job that takes lots of knowledge and experience, or long trial-and-error workflow -- especially if a proper preflight tool is not available.

Thanks, @Hangman. For additional information, I actually managed to export using this specific file at least partially rasterized SVG files also in a situation where I had all or part of the objects selected. Clearing the selection and selecting again might have resolved the problem, so I could not determine a clear reason for the rasterization. It might be related to the structure of the document, having all transparencies specified for the group container and then objects themselves having passthrough as inherited blend mode.