lacerto
-
Posts
5,779 -
Joined
Posts posted by lacerto
-
-
On 6/25/2023 at 2:31 AM, Oufti said:
it is possible to set a limit for the total and the rich black ink coverages.
That is fine, but it is good to know that this does not cover effect of blends and overprints so an exported output can have exceeding coverages not spotted by the preflight calculator.
-
On 11/16/2022 at 2:25 PM, NotMyFault said:
A source for repeated questions or feature requests is color separation. This tutorial explain the steps to separate a CMYK color format document into the individual C M Y K channels, and get a preview of total ink (areas exceeding a given threshold)
I think that the repeated questions are typically related to separation preview, while images (and possibly also native elements) are still in RGB color mode. If that kind of tool can also show problems in placed CMYK content (already when it is placed on the canvas and not just in the exported PDF), then all the better. That is, users would like to have a kind of an interactive in-app preflight tool that exists e.g. in InDesign:
In lack of something like that, post-export tools like Adobe Acrobat Pro and callas pdfToolbox, and PackzView (the only one that is free, but with limited availability), are pretty much the only tools that can handle TAC and other preflight related tasks effortlessly and professionally. Everything else that I have seen (including postprocessing of separated inks e.g. with Ghostscript) are rather convoluted workarounds, but of course better than not having anything at all (= dismissals from the printer).
-
Odd, now that I tried, the macOS version of Publisher (2.4.2 on macOS Sonoma 14.4.1) does have native objects CMYK readings updated after a profile change, so perhaps it was just a temporary (memory related) issue. But for placed images, reopening is still necessary.
I tested the profile you referred and it seems to operate correctly:
Color data seems to be very easily affected by memory issues. At some point I experienced problems (on macOS) where I could not get realtime CMYK readings (in Photo Persona accessed Info panel) at all for placed RGB objects, neither for native or placed RGB images.
-
4 hours ago, mykee said:
Here I use FOGRA39 for my prints, so by default I use the FOGRA39L_VIGC_300 profile and put the RGB images on that, but for some reason it still crosses the 300% limit and exports 325%.
Have you tried the save, close and reopening trick, as advised by @thomaso. This should result in RGB images being properly assigned with the "new" (currently active) target CMYK profile so that you get correct reading already when using TAC picker or CMYK picker, but most importantly, when you actually export to CMYK PDF.
-
4 hours ago, thomaso said:
Do you know if this was ever (bug-)reported for V2 ? (… I never have noticed an according bug report for V1 and I have V1 only).
Sorry, no. I am rather lazy reporting and following bug reports... It was very useful to know that just saving, closing and opening again does the required refresh! I had assumed that this happens at export time at latest, if at all.
Closing and reopening might in current versions also work in many other related situations I have experienced where placed images have not been updated. In some situations images can be updated "in-place" by using the "not-found" trick (renaming the folder where linked images are located and updating with Resource Manager at document open time). But in some situation it has been necessary to physically remove a placed file and place it again to have color or profile related information updated.
The macOS versions have generally many issues related to having color date updated (e.g. in the Color panel), but typically these errors have been just kind of "lazy refresh" issues (like having up-to-date reading when deselecting and reselecting a native object).
-
3 hours ago, thomaso said:
or save + close + reopen the document
Phew, that's at least a very good workaround. I had not noticed this!
-
On 4/22/2024 at 6:41 PM, mykee said:
Where and how can I control the black fill ratio in Publisher (like in Acrobat) so that the printer doesn't send my cover back? How can I check which is the darkest point in an image?
If your blacks are RGBs, basically just applying (assigning) an appropriate color profile would limit the total ink to a specific maximum value. If the max TAC is as low as 260% you appear to have uncoated (or very lightly coated) media. Choosing e.g. US Web Uncoated would limit the total ink to 251% and keep the job neutral, not making it diluted or desaturated but basically just limiting excessive ink in darkest areas.
If your colors are already in CMYK, you may consider converting the job (color definitions) to RGB, and then choose an appropriate profile in context of the press conditions and media that limits the total area coverage and manages ink usage with proper methods (like applying undercolor removal and gray color replacement curves). (Converting from CMYK to CMYK is normally not a good idea but if there are clear spots with excessive ink you might get away with it by applying manual tone control.)
But my point is: by using an appropriate profile you will get balanced (non-color cast) properly managed tones and will get excessive ink usage automatically limited. Playing with soft proof and manual tone controls can be useful in RGB based output workflows (that expect the print file to be in RGB color mode), but typically not when using commercial press.
See below how changing from an app. max 330% TAC Euroscale Coated profile to US Web Uncoated effectively limits the inks to max 250%.
Note how Affinity apps appear to require refreshing of placed RGB images before ink limit of a changed profile takes effect (something that does not happen when using e.g. InDesign, so there both early and export-time profile reassignments are correctly applied for RGB objects when exporting to PDF) -- I have a feeling that this did not happen earlier within Affinity apps, either. It also seems that the macOS versions are even more broken as there (at least with native chip on macOS Sonoma 14.
24.1 and latest Publisher 2.4.2) assigning a different CMYK profile does not seem to have effect on conversion of neither native art in RGB color mode (the RGB 0, 0, 0 black rectangle), nor in RGB image, so on macOS profile-based TAC limiting is badly broken.Note that US based profile may not be ideal in European press so you could ask your printer if they have a recommendation for the output profile considering the press conditions and used media.
UPDATE: It seems that on macOS the native objects can be "reassigned" (refreshed) at least by selecting them and switching the color model within the Color panel (without making color conversion). On Windows "refreshing" is not needed (and should not be required on macOS, either).
UPDATE2: Sorry, I read your initial message a bit carelessly and thought that TAC 260 was the goal, instead of TAC 280. You can come pretty close with e.g. Uncoated_Fogra47L_ViGC_300.icc, which has 274% as the TAC.
-
There are surprisingly many PDF/A formats, for PDF/A3 alone three sub types. I have very poor understanding of differences between the sub types but when I had a look on reasons why Apple Preview created PDF/A file failed in Adobe Acrobat, I got the following:
So things related to metadata, and encoding (mapping) of font containing unnamed glyphs (the font that I used was Arial, which has multiple character sets).
PDF/X-Change, on the other hand, creates a report of what is done when converting to PDF/A, and shows the following, when it creates a PDF/A-3a file from the same PDF/X-1a:2003 based test file that I used:
What it also does is that it embeds font sub sets, which means that it does not include all various Arial character sets and glyphs which the document does not use, and my guess is that this (if not done) could be the primary cause for not passing compliance tests. PDF/A measures are basically ones that are done for compatibility and to improve archiving, but as mentioned, I have no clue of details and why there are so many sub types (or which sub type is most common and "most compatible")..
-
On 4/20/2024 at 2:50 AM, Aidren said:
Is there a chance Affinity Suite will add export to pdf/a support.
You can convert a PDF file created by an Affinity app to PDF/A format. On Windows, you can use PDF-XChange Lite (free version) and determine which kind of a PDF/A format the file will be saved in:
PDF-XChange is unfortunately available for Windows only. MacOS Preview can save a previewed standard PDF as PDF/A file, but when I tried to verify the format in Adobe Acrobat Pro, the Preview saved file (formally PDF/A-2b) failed to pass the compliance test. PDF-XChange created version passed all compliance tests. I do not know if there are free tools for macOS (or online) that can convert a PDF to specific PDF/A format (there are commercial solutions available also on macOS, e.g. PDF Studio, that can do this and pass compliance tests).
-
As @walt.farrell suggested, holding down the Alt/Option key while using the Text tool (either Frame or Artistic), lets you alternate between overlapping text layers (the focus changes on each time clicked so if you want to select text, do it when you Alt+click the correct frame). If the Move tool is used, instead, the selection will alter between all overlapping layers (not just text layers).
-
15 hours ago, kat said:
I'm on mac OS, so sounds like my excel will not import correct.
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.
-
5 hours ago, XuCxSxMk said:
Python
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.
-
11 hours ago, lepr said:
Instead of reducing the opacity of the fill colour, use the control labelled with "Fill Opacity" in the Quick FX panel or Layer Effects window or Blend Options window to reduce the opacity of the fill without revealing an FX Outline colour.
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.
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.
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).
-
15 hours ago, walt.farrell said:
Photopea can read .afphoto files, and so it would not be too surprising to me if it could read TIFF files with Affinity layers.
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.
-
34 minutes ago, bbrother said:
I think this is because of the XLSX format specification. Standard formatings are fixed and therefore developers could associate references to such formats and format the regular value accordingly. In the case of custom ones based on user creativity, this is not possible.
It seems it has been possible to Adobe developers at least from 2012 (InDesign CS6):
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.
-
15 minutes ago, kenmcd said:
Any easy way to swap the font during the merge?
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).
-
10 hours ago, TheZBillDyl said:
Is there anyway to change colors of things with Data Merge?
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.
-
17 hours ago, GreenGirl said:
You're absolutely right; it opened the file perfectly and everyone's happy. Thank you again! ❤️
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?
-
15 hours ago, jackjohnbrown said:
I must be doing this incorrectly - when I add those adjustments to my project (copying what is shown in the video) my palette is still just as big, though the tones do change.
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:
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.
Black ink fill rate control in CMYK?
in Affinity on Desktop Questions (macOS and Windows)
Posted
Make sure that you also have "Look inside placed documents" checked! Note however that this tool does not take into account the effect of blend modes and overprints so the total outcome of an exposed file can still exceed the set TAC limit without any warnings displayed.