lacerto
-
Posts
5,783 -
Joined
Posts posted by lacerto
-
-
41 minutes ago, paleolith said:
How should I be set up so that my RGB export has R0 G0 B0 text, and my CMYK export has C0 M0 Y0 K100 text, while doing normal conversion for non-text?
You basically cannot, if your job also has color content. You could have RGB 0, 0, 0 black exported to RGB black for digital purpose and K100 (actually gray 0) for press, but then you'd need to export the press job using grayscale mode, and that would not work with native color RGB objects (which would be in gray). There is no equivalent of "[Black]" swatch of InDesign that exports as K100 in press exports, and RGB 0, 0, 0 in digital exports so if you want to have that, you need to convert text black for both purposes (which is not necessarily a big job since you can use e.g. Find / Replace to convert all K100 text to RGB 0,0,0, or vice versa, in one go; or use text styles, which, though, is less reliable way to do it).
As you are going to export to press, too, I would choose CMYK as the primary color mode and define text as K100, and all native art in RGB (that is perfectly possible, since Publisher will keep your RGB definitions without converting them to RGB (just remember to have lock turned on in the Color panel if you use that to define object colors). You would naturally also place all your images in RGB color mode. When making the final digital export, you would then convert K-100 black to RGB 0, 0, 0.
There are benefits of primarily using CMYK color mode, e.g., to have the "K-Only" button available, which would let you have your grayscale images automatically processed as grayscale (or control the conversion/non-conversion manually for each image) when exporting to CMYK, instead of being converted (typically inadvertently) to four-color black. Keeping the job as CMYK will also make your press-related exports more relaxed, considering the need to have the optimum CMYK document target profile applied, as you would not need to make document color mode swaps just to make the right CMYK color profile assignment.
-
5 hours ago, rzolau said:
This is problematic as each time I import I have to correct the color. Any suggestion how to "force" AD to preserve CMYK colors from the PDF?
Hi @rzolau, and welcom to the forums.
You mention that you drag and drop your PDFs onto a Designer artboard. This is equivalent to using File > Place, and using the default placement mode, which is "Passthrough". Please check that this mode is shown on the context toolbar when you have the placed PDF selected.
On the other hand, you also mention that you can select the "imported" text, specify formats like ligatures, etc., and this implies that instead of placing the document, you have actually opened a PDF for editing? It is crucial to know which way you have your DeviceCMYK PDF brought in Designer, since the advises vary depending on what you have done.
Also, please ensure that you are viewing the resulting PDF with an app that does not show recalculated color values. E.g. Adobe Acrobat Pro might use a simulation based on target ICC profile and show translated color values, in case the viewed PDF has embedded ICC target, and in this case the simulation profile must match the embedded target profile.
As for your second question, if it is a document that has been placed for passthrough, all native formatting is retained and whatever you have active in the hosting document, only applies to text that you have created in that document. As for interpreted or opened PDF, I would assume that formatting of the source document is used, but I have not examined this thoroughly, and know that certain settings, like overprinting attribute, is not correctly read by Affinity apps, so there is point in checking all these kinds of formats when not just placing for passthrough.
-
8 hours ago, kenmcd said:
Still not sure what you are trying... but it sounds like you have multiple versions installed, and that is most likely the issue (the corruption).
Yes, sorry, I was confusing. I misunderstood what you had done: I thought that you had created COLRv0 table instead of an assumed COLRv1 table, and totally lost the track and forgot that the original font was based on an SVG table. It seems that Affinity apps always export PAL/COLR based font as curves instead of embedding it, which does not much matter when exporting symbols like emojis, but is a clear minus when exporting alphabetic content.
-
Try exporting your PDF using PDF/X-3 or PDF/X-1a. Both of these formats will flatten the transparencies included in your placed PDF content, and should fix the problem.
The problems other people are experiencing are related to print-time flattening of live transparencies. They often get flattened with miscellaneous issues.
-
In which way do you need to "fix" the scores?
If you open a Sibelius-created PDF v1.4 file in Publisher, you need to have all Sibelius notation fonts installed on your computer to have Publisher render the text (and notation) correctly.
If you place a Sibelius-created PDF 1.4 file in Publisher, and leave the placement mode at its default value ("Passthrough"), you should make sure that you also export using PDF v1.4 or later non-PDF/X-based export method, since all PDF/X-based export methods will rasterize non-PDF/X-based placed PDF content left in "Passthrough" mode.
If you let Affinity app to "Interpret" placed content (which the "Fix" operation of Publisher Preflight does), you need to have all fonts embedded in the placed PDF installed and make sure that the fonts also get correctly mapped.
Whenever you place PDF content for "Interpretation", you cannot edit the content, so if your intention was to edit the content, you need to open the Sibelius-created files instead of placing them.
Note, too, that Sibelius files are in RGB color mode. You should ask your printer if it is ok to have them in RGB color mode (where black is RGB 0, 0, 0). This is important, since if you export interpreted ("fixed") placed RGB PDF content to CMYK, all RGB 0,0,0 content will be converted to four-color-black, which you probably do not want. When you export "passthrough" content, the original RGB color mode is retained (unless the content gets inadvertently rasterized), but this may be unacceptable to the printer who expects the file to be in CMYK color mode (and using K-ink only).
There are ways to do a properly created K-only PDF export from a Sibelius RGB content, and it basically involves exporting to Grayscale color mode either Interpreted content, or opened content (or opening the content and converting everything to K100, and then exporting to CMYK). What needs to be done much depends on what you need to edit, and what your printer expects.
-
4 hours ago, kenmcd said:
Affinity appears to "punt" and just embed the shapes, with no text info.
Yes, but only COLRv0 version of Gilbert (the font that you created).
COLRv1The SVG version shows the b/w fallbacks on canvas, but when exported to PDF (with Affinity v2 apps), embeds the font and the exported text stays as text (selectable/copyable, and searchable in the PDF, which may be important factors when using a color font that has alphabetic content). -
One further thing that I forgot to mention: the feature where PDF export creates color versions of b/w fallbacks of an SVG OpenType color font, is Affinity app version 2 feature. In v1 version apps, exported fallbacks stay black and white. SVG exports, however, are rendered in color (at least in Firefox) also when exported from version 1 apps.
-
7 hours ago, kenmcd said:
it sounds like you have multiple versions installed, and that is most likely the issue (the corruption).
No, I ensured this now by first uninstalling the original Gilbert, and only having the v0 version that you created installed. When exported (tested from Affinity apps), the font is converted to curves (in my attached version above where I used both SVG
v1and COLRv0 versions of Gilbert, and the COLRv0 shows as if being Type 3, but I think this is false, but it is not selectable text, either)-So when checked in Adobe Acrobat Pro, no fonts are embedded, and the exported text is converted to curves (the font is not embedded in the your PDF, either):
--while when exporting the original SVG
v1version of Gilbert, the font is embedded and the text can be selected (and searched) in Adobe Acrobat:...and when COLRv0 font is used in VectorStyler, text is encoded strangely, so when "Gilbert" is typed, the following is shown:
These things do not happen with the original SVG
v1Gilbert, and as mentioned, this behavior is identical on macOS and Windows (and when the original Gilbert has been uninstalled).7 hours ago, kenmcd said:The original Gilbert Color SVG does not have anything in it which requires COLRv1,
so I am not sure why anyone would include that - just confuses things more.I was wondering if COLRv0 might have been limited in this way, not allowing embedding (but always been converted to curves), and also, if some apps, like Pages on macOS, might ignore COLRv0 versions and only support COLRv1 and up (because it does work with SegoeUI Emoji, which I assume is COLRv1)? VectorStyler false encoding seems to be specific just for VectorStyler.
-
9 hours ago, kenmcd said:
Please explain.
The bottommost version in the PDF is an export from COLRv0 Gilbert and the topmost from the SVG
v1version. The upper version can be selected as text and the lower version cannot.I am not sure whether "Type 3" is correct, because in other instance the v0 version of Gilbert (v0) exports as curves:
I also noticed that in VectorStyler (macOS and Windows) there is something wrong with the encoding ("Gilbert Color SVG OTF" is the text typed in here):
I also noticed that In Pages the v0 version of the font is not listed in font menus, at all.
Do you know if these are something that can be expected with v0 version? Or could these be results of having v0 and the SVG
v1version of Gilbert Color (even if with different full name) installed on the same system? -
11 hours ago, kenmcd said:
Converted from original Color-SVG to COLR v0
Is it this that causes export to Type3 (not selectable glyphs / text) -- vs. a situation when exporting the SVG version
COLRv1? -
6 hours ago, firstdefence said:
If most mainstream popular apps can handle colorfonts why can't Affinity? Vectorstyler is a new kid on the block and handles colorfonts very well.
I might have my version somehow broken (1.1.122), but I am currently experiencing following:
a) VectorStyler (UI and PDF export):
b) Affinity Publisher (UI and PDF export):
-
12 minutes ago, William Overington said:
CPAL/COLR was, I think, the first font format for colour fonts yet might now be regarded as semi-obsolete.
There is a pretty good general description of the three most common color font technologies on Glyphs web site (all within the specs of OpenType). The CPAL/COLR based version is described here:
https://glyphsapp.com/learn/creating-a-microsoft-color-font
CPAL/COLR(v1) is not obsolete by no means, but in many ways the most advanced (and also rarest on field).
As described in my first post within this thread, Affinity apps support at least to some extent sbix (bitmap based, common on macOS) and CPAL/COLR based (vector based, both Windows and macOS) fonts. What was surprising (at least to me) that they also support OpenType SVG-table based color fonts, for which I earlier believed that only the b/w fallback versions would be supported. But as shown within this thread, certain kinds of SVG-OTF color fonts will be exported as color fonts (or sometimes converted to outlines, but still in color) whenever exporting to SVG or PDF.
In a way Affinity apps prove out to be supporting color fonts at least on a level that is work(around)able...
Color can be worked in to fonts so well using other means that one could say that the whole color font technology is kind of obsolete, it never really fired, partly probably for reasons implied in this discussion: they are pretty complex, and still not widely supported (even within browsers).
-
6 minutes ago, William Overington said:
I responded to the statement made that my idea, put forward in 2021, being referred to as a "mistake".
I completely see your point and that is why I placed what I said in quotation marks, and also mentioned that I can see why it is a "happy mistake" to some. Edge, indeed. might be broken at the moment, but who knows (considering that Chrome currently does not render any of these examples as color fonts -- this was a totally new phenomenon to me so I cannot say if Chrome has sometimes behaved differently).
-
1 hour ago, Alfred said:
which would explain why Playbox doesn’t now display as I thought I remembered
@Alfred, please check this:
...I at least was fooled by this, since in above case Playbox was exported actually as curves by Affinity. Then in next instance it exported it as font, and then b&w version was shown in Edge!
-
8 minutes ago, William Overington said:
So I got a good result using the facilities that I had available.
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.]
- Sam S - TO and Alfred
-
2
-
16 hours ago, Alfred said:
Until they are, it seems that the best we can do is export to SVG, view the result in a web browser (or any other app that displays the text correctly) and take a screenshot.
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".
-
1 hour ago, thomaso said:
language of macOS + Affinity app need to be identical
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.
-
1 hour ago, thomaso said:
Good hint; unfortunately while the semicolon seems to work to type the second comma … it gets altered automatically when I type the next value.
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).
- Sam S - TO and Alfred
-
1
-
1
-
19 hours ago, thomaso said:
In my understanding LUTs or .ICC profiles are not really useful for this thread's color-to-b&w goal. What does it help if I have LUT but need to add separate adjustments to make the LUT work properly for a specific image?
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.
Converting images to CMYK within Publisher (Maybe using Persona Photo)
in Affinity on Desktop Questions (macOS and Windows)
Posted
It should be your principal workflow to always place photos and other RGB images in RGB color mode and just have them (automatically) converted to CMYK at export time, using the correct CMYK color profile. You can have your press-oriented document in CMYK/8 color mode and place and define native shapes in RGB and then convert to CMYK (CMYK document color mode does not mean that the app automatically converts colors to CMYK when placed or defined; Affinity apps allow kind of dual-color environment, similarly as e.g. InDesign). There is typically no need to convert images to CMYK beforehand.