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).