lacerto

It seems my compliments to macOS version of Excel were premature -- I have US English UI language active in the operating system but Finnish regional settings (including date and number formatting), but my Excel (also using US English UI) just keeps on showing all cell formatting using US English regional settings, even if I have the default editing preference (in Excel) set so that the system group and decimal separator should be used! I have macOS Sonoma 14.2.1 and latest Excel 16.8.3 installed. So it seems that the current macOS version of Excel forces US English formatting according to OS UI (and/or Office 365 UI language), no matter what. On Windows it works in a predictable way even if it requires manual intervention: the formatting you had in your Excel sheet shows as being "custom", but after having been changed to use explicit US English formatting (using Excel Windows version), I could open the file in Publisher so that date and number formatting show correctly.

That's the language (and graphic libraries available to it, including ImageMagick) I would use for the task (especially if raster-based). See e.g. https://github.com/ImageMagick/PythonMagick.

These controls also reduce opacity of enclosed text. To reduce opacity of text frame background fill only, I could not find any other fix than replacing the Outline FX with regular outline attributes. After that, opacity of text frame background fill operates as expected. outlinefx.mp4 As this was an .afdesign file, it may be that the oddity with FX Outline was initially caused by applying stroke attributes (with opacity setting?) in context of Appearance panel, or possibly from attributes used in the shape around which the the outer text was aligned (and the ellipse then lost in Designer), but at one point when I was examining this design I managed to create a central object with text with 100% opacity white as text frame background fill, which still had a good deal of transparency, which I could not turn off (the fill could be turned off and then redefined without any change). It did not come from transparency attribute that can be applied using the Transparency Tool. In context of FXs, partial transparency can become from multiple places, some of which are just alternatives (like the controls you mentioned), but in addition to those, color attribute and the layer itself have transparency attributes of their own (blending modes included), as have similar attributes that are available in individual FXs themselves, so it can become quite confusing, even without mixing involvement of multiple apps and tools that are accessible only in them (or sometimes via a Persona). Sometimes also the Fill Opacity setting available in FX Panel is directly interconnected to the Opacity of a Layer panel (but not in this case).

I had another look on this, and now on macOS. There I first changed number formatting to US English style using System Regional settings (from the default Finnish one), and then simply just opened your .XLSX file in Microsoft Excel (latest version). The formatting came correct out of the box, including the date, and surprisingly were not "custom" formats in macOS Excel (which, btw, in many ways seems smarter than its Windows cousin). So what I did was that I just copied the Excel data onto Clipboard, selected all cells in Publisher imported .XLSX file that is otherwise properly formatted, just messing up number formats, and pasted. Alignments come wrong, but it is a simple task to right align required columns, and vertically center align cells. pastefromexcel.mp4 On Windows (using Finnish regional settings, at least), I had to open the .XLSX file in Excel and change number and date formatting that were interpreted as "custom" to standard US formats, and save back. After that, Publisher opened the file correctly (excluding alignments). On Windows, you can also use Clipboard to transfer correctly formatted data via Clipboard (using the default Rich Text Format), but on Windows reformatted .XLSX is read correctly (on macOS it will still be read incorrectly).

Well, it seems it cannot, not at least the test versions that I created from Affinity Photo version 1 and 2, with 5 pixel layers. The default Zip compressed TIFF file additionally showed the active layer with pixel content as corrupt (and no other layers present). LZW and non-compressed TIFFs were shown correctly but the empty layers were not present. And as mentioned, Affinity Photo 1 cannot open TIFF files created from within Affinity Photo 2 with Affinity layers (because they cannot open Affinity Photo 2 files). So the key to the "layer mystery" and why Photopea, indeed, is a solution to share Affinity layers with ANY user (not just Windows!) that have an image editor capable of opening a Photoshop files with layers -- is that Photopea can open native Affinity Photo v1 and v2 files and save them as standard .PSD files with layers that any app supporting PSD import (with layers) can open. So Photopea basically does the job that Affinity Photo should do in the first place! Because Photopea does what it does, one begins to wonder, but hopefully Ivan Kutskir still is (and stays!) independent and just has managed to de-engineer .aphoto format (as he once did with .PSD format before it was partially publicly documented). For more information on Photoshop format and apps that support PSD format, see e.g. https://www.loc.gov/preservation/digital/formats/fdd/fdd000523.shtml.

It seems it has been possible to Adobe developers at least from 2012 (InDesign CS6): importing_custom_formatted_excel.mp4 The clip is from Windows that uses Finnish regional settings with space and comma as group and decimal separator, and as text is interpreted rather than using live formats, needs to be find-replaced to set formats correctly. InDesign would probably read the file correctly if system regional settings were changed and the app restarted. InDesign reads the custom formats meaningfully both from .XLS and .XLSX formats, so I think this is basically just a question of maturity of apps, and level of programming skills.

To stretch this a bit further, the trick when using a custom color font, is to use Lighten blend mode so that an Excel sheet can define 1,000 different colors simply by reading hex definitions. On macOS the color of the actual color component can be previewed but the final color is of course result of blending the three components, so the method requires some training 🙂 a) The data source: b) The data merge setup:

The bug seems to be related specifically to incorrect interpretation of custom formatted data. This is how the currency cells are formatted in the original Excel sheet (at least when opened in Windows Excel by default using Finnish regional settings): When I change this to standard currency formatting with US dollar, and specifying in Excel preferences that custom group and decimal separators (that is, the US comma and dot, instead of Finnish space and comma) should be used: ...and then save the document, and place it in Publisher, I wlll get formatting right: I'd imagine that this works identically on macOS, but have not tested. EDIT: So whenever using an Excel sheet that has different number separators from what the system uses, one can specify in Excel preferences exceptions (the setting is global, so once the reformatted Excel sheet has been saved, the regular system setting based formatting can be returned):

Here is a setup where specific Segou UI Emoji glyphs with different background colors are clipped into (heavily zoomed in into) Arial (and also table cells) and where text gets coloring definition from an Excel sheet, so it is not necessary to use a custom font (self-created). I just created one to make it possible to precisely define a color in source by mixing 10 RGB components.

What do you mean "during" (the color font would be defined in the merge setup and clipped into the actual font that will give the shape) -- so cumbersome, but after it has been done, actual merge should be "smooth" (at least in marketing jargon) 🙂

Yes, this seems to happen both on Windows and macOS, so even if the system regional settings match the formatting of the placed (interpreted) Excel document, e.g. the thousands and decimal separators are incorrectly read. On macOS, one can get correct non-rasterized formatting when copy pasting from Excel (apparently the data will be in PDF format). but editing, if necessary, is pretty cumbersome. On Windows, formatted Excel data will be rasterized, and on both platforms, Excel data can also be pasted as tab separated data and then manually formatted, which is of course tedious, but still one way to get this kind of data formatted according to wishes. Here's how the attached .xlsx file (with US formatting) will appear on macOS Sonoma 14.2.1 when placed (above) and pasted from Excel (below) in a system that has US regional settings as system settings (and also as language settings in Affinity apps, should that matter at all).

I have not found any other way than using custom color font that I created myself where alphabetic glyphs are used to specify 10 shades of R, G and B and then an Excel sheet includes this information as part of source data (capable of getting a reasonable palette of 1,000 different colors), and the data merge setup specifies the font in receiving fields as a clipping object so that the text containing a clipped glyph gets the desired coloring. It works, but cannot be said to be an easy work around 🙂 UPDATE: Other than that, the only way would be using some sort of custom encoding as part of source data and using Find Replace (with RegEx) to have encoding changed to colored text after the merge.

How did you manage to do it? I tried to save (pixel) layers with Aphoto v1 and Aphoto v2 on both platforms and chose compatibility box at export to PSD, but did not find any way to export content with layers in PSD format. As opening apps I tried Photoshop CC 2024 (latest version), Photopea, Corel PHOTO-PAINT 2023, GIMP (latest version) and even Affinity Photo (both v1 and v2, and on two platforms) but none of them could detect any layers in the PSD file exported from Affinity Photo, so obviously none was saved. Perhaps there is some setting in the app preferences that determines whether layers are truly exported, but so far the customary TIFF format that explicitly saves "Affinity layers" at user request seems to be the only way (in addition to native .aphoto format) to save layers from Affinity Photo, and I am not sure for what purpose, because these TIFF files, when opened in afore mentioned apps (Photoshop, Corel PHOTO-PAINT, GIMP), are not detected (so the only app that seems to read them in TIFF format is Affinity Photo; it should be noted that not even Affinity Photo v1 can read TIFF files with Affinity layers created with Affinity Photo v2). PSD layers as such seem to be well (publicly) documented (non-proprietary part of PSD format) since at least Photoshop, Photopea, Corel PHOTO-PAINT, GIMP, Acorn and Pixelmator Pro can both create and read PSD files containing layers and fully share this information with each other. Affinity Photo, too, reads these PSD files with layers, but if trying to save back, forces change of the file format to .aphoto. Since the title of the thread specifically mentions Windows, I assumed first that this is somehow a "Windows-only" issue but as implied above I just tested this thoroughly on macOS (Sonoma 14.2.1) and the incompatibility problem appears to exist there, too. This sounds odd, since PSD "compatibility" is clearly implied in APhoto Help and .PSD is listed as one of the supported export formats (with only a note that text will be rasterized on export). So as you and @nezumi seem to have achieved a less sad ending, I wonder if I am just missing something?

It is a bit tricky design as the "additional" orange tones probably cannot be removed with this method without using rasterization, since it seems that the brush profile is applied last, causing smooth transition of edge colors even after quantization curves have been applied. There is additionally opacity and Darken blend mode applied on the brush curve that make the case more complex than one that I used in the demonstration recording. So depending on the goal the quantization trick shown might require some further modifications (also considering whether the edge colors which are wanted to be reduced are created with direct color definitions or by using modifiers like coloring, opacity and blend modes). The three quantization "parameters" (Gradient Map Adjustment, Posterize Adjustment and Black and White Adjustment) typically also need to be twiddled a while to get the desired effect. Note that rasterization itself is not a quality compromise since blend modes, effects, vector brushes etc. will cause export time rasterization anyway. The video clip below demonstrates reduction of the original orange tones from 48 to 2: orange_reduction.mp4 I have also attached the design you posted with Quantization group added and the required modifications made to achieve what is demonstrated on the video. Note that if you create a document palette with the complete design (texts and the record itself), the number of orange tones increases so obviously there are opacity / smoothening effects elsewhere in the design that cause this. DiJ 2024_quantization.afdesign

If you can reproduce the problem consistently with a specific file (also after having closed and reopened the file, and the app itself, and especially after restarting the computer), it would be useful to post the file for examination of devs. I have a feeling that the error is somehow related to mouse capture, and for me the error often goes away after I start the app again after it has crashed, or anyway, it cannot be reproduced consistently. But as said, I think that this error has been there as long I have used Affinity apps (and does not happen with any other apps).

I do get this very often, too, but then crashing might suddenly stop. I have not been able to find out what specifically causes it, or which action stops the problem, but I think this behavior has been there forever. And I think this might be only on Windows. It is definitely not a PC problem.

I did not have a closer look on the document at hand but I would assume that ilovepdf does OCG layer merge based on common names (possibly existing on the first page to be merged). Adobe Acrobat Pro, PDF/X-Change and PDF Studio all do layer merging by allowing the user to select the layers (on single or multiple pages) on to be merged (even if having different names), and then optionally pointing the target layer with which the selected layers should be merged with, so if there is complexity in the document, one would probably need a more advanced tool.

IMO they do work natively for many blend modes, but I have not looked this closely, and especially not in context of many F/Xs and diverse contexts where blend modes can be applied, and I suppose there are also bit-depth and color mode limitations (at least practical ones) as for functionality of specific blend modes. Basically the document color mode determines whether RGB or CMYK channels will be used. If an object uses e.g. RGB color definition, the values will first be translated (without converting the colors of objects themselves) to CMYK mode (and vice versa) based on active color profile environment. I have not tested LAB color mode (or anything else than 8-bit RGB and CMYK. As for subtraction or difference, I think you would need to invert the intensities to have a more intuitive perception of difference between e.g. C values in two images placed on top of each other (because difference of e.g. C100 and C99 cannot be demonstrated meaningfully if other components are not involved and would produce M100 Y100 and K100 in three other channels). E.g. the image below would describe the intensity difference of C channel of the flower image I used above between ISO Coated v2 and Uncoated Fogra 29 profile (using less ink), and illustrates how much more C ink would be applied on an image printed on coated paper (or less on uncoated paper). So the Difference blend mode can be used in calculation but it is typically not useful without further manipulation.

Thanks! I have thought that these are pretty much the same tools as on https://tools.pdf24.org/ but no, the merge really merges the layers with the same name while the pdf24 tools do not!

As a side note to doing desaturation in CMYK mode, there are multiple ways without needing to preprocess the image. The major point is that when working in CMYK color mode, you pretty much get what you see: Converting to grayscale (e.g. by using Black and White adjustments with sRGB or NTSC conversion values, the latter being pretty much the same as applying K-only) often produces out of the box the most balanced and rich but still guaranteed neutral results (with no color casts, as black ink only is used). desaturations.pdf

In my experience blending modes can be used in either RGB or CMYK color mode but the results are different depending on whether the resulting color values will be calculated with RGB and CMYK channels. Therefore one cannot use blend modes in RGB color mode (not even using CMYK color definitions) and expect blends to have similar results in a CMYK output, or vice versa. Calculations themselves are accurate and fully predictable in either color mode, but you just need to pick the correct document color mode to get expected output. transparencyblendingspaces.mp4

I now created versions using Glyphs 3, and these show basically correctly in macOS versions of Affinity apps (even if show bigger leading than defined), including showing correct style link behavior. The Glyphs 3 versions also install on Windows and behave more or less correctly in InDesign. But then show badly corrupted in Affinity apps! Glyphs3Fonts.mp4

Basically yes. But as far as I know Apple deliberately messes up with especially supplemental fonts, possibly against misuse (illegal copying). Who knows... E.g., as mentioned, when I initially extracted style corrected versions of Khmer MN using FontForge, and tried them on Windows, the fonts did not work on Windows version of Affinity apps (but did work in InDesign). When I later regenerated these fonts using FontLab 8.3. (and on macOS), these versions worked otherwise fine in Affinity macOS apps (including styling links), but nothing at all is shown in the Glyphs panel. I think these oddities are related to crippled meta data in these fonts. UPDATE: This demonstrates what is mentioned above: macOSSupplementalFonts.mp4 The issue with the Glyphs panel could probably be fixed by adding Unicode ranges and Codepages in font metadata, but then it is a pretty much a mystery why the FontLab created versions will not install on Windows platform at all (but FontForge extracted versions did, and also worked without issues in InDesign). UPDATE2: I only just noticed comments by @kenmcd above as for the Apple AAT fonts and non-standard tables. This obviously explains the issues with Windows installation and the Glyphs panel.

Khmer Bold does not have Bold style link, but Regular, and both fonts also use the same regular weight class (400) so Affinity apps basically behave as expected of an app that reads style links (even if in many cases incorrectly). On Apple, however, many apps seek bold version of the font by using the Style name, some possibly even Full name (or PostScript name), when Cmd+B or Bold button is used, even without style and weight class linking. This happens e.g. in Word and Pages (which basically does not even list the font, but recognizes it if pasted via Clipboard). I corrected the errors in the font styles and generated new ones, but could not get them display right in Affinity apps (probably because of issues with the Khmer script); the fonts behave correctly in InDesign (including styling link behavior) but none of the glyphs show in Publisher. This is in many ways a "typical" macOS supplemental font, with non-standard font meta data.

This is promise-ware in its purest form. "Further cement" -- the first thing we should see is getting rid of marketing clowns that use these kinds of ballooned phrases that have no ground in reality. But I guess there is plenty left where that came from.