Color Font is not being displayed in Affinity Designer 2 - Desktop

[kenmcd]

Gilbert Color COLRv0 Font
Converted from original Color-SVG to COLR v0.
Has TrueType outlines as monochrome back-up (i.e. black).

Displays in APub as color.
Exported from APub to PNG and PDF in color.

Gilbert.Color.COLRv0.zip

Note: this is a free font (has a CC license in the font).

Example: Export to PNG from APub.

 

[William Overington]

Maybe there was a patch to Affinity Designer later or something, but when we had the thread with the introduction of (the SVG graphic file workaround then displayed using Microsoft Edge), the display in Affinity Designer version 1 was monochrome. The workaround works because each monochrome glyph and the corresponding colourful version have the same Unicode code number.

The two glyphs do not need of necessity to be such that one is a colourful version of the other.

For example, these that I designed that convey the same meaning whether monochrome or colourful, but the designs are different.

https://forum.affinity.serif.com/index.php?/topic/144236-some-language-independent-glyphs-for-museum-shops/&do=findComment&comment=800985

https://forum.affinity.serif.com/index.php?/topic/144236-some-language-independent-glyphs-for-museum-shops/&do=findComment&comment=801007

William

 

[Alfred]

11 minutes ago, William Overington said:

The two glyphs do not need of necessity to be such that one is a colourful version of the other.

*The two glyphs do not need to be such that one is a colourful version of the other.

12 minutes ago, William Overington said:

https://forum.affinity.serif.com/index.php?/topic/144236-some-language-independent-glyphs-for-museum-shops/&do=findComment&comment=800985

13 minutes ago, William Overington said:

https://forum.affinity.serif.com/index.php?/topic/144236-some-language-independent-glyphs-for-museum-shops/&do=findComment&comment=801007

[lacerto]

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 versionCOLRv1?

colorfonts_example_v02.pdf

[kenmcd]

5 minutes ago, lacerto said:

Is it this that causes export to Type3 (not selectable glyphs / text) -- vs. a situation when exporting COLRv1?

colorfonts_example_v02.pdf 1.82 MB · 0 downloads

Sorry... do not understand the question.

Please explain.

[lacerto]

9 hours ago, kenmcd said:

Please explain.

The bottommost version in the PDF is an export from COLRv0 Gilbert and the topmost from the SVGv1 version. 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:

gilbertv0.pdf

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 SVGv1 version of Gilbert Color (even if with different full name) installed on the same system?

[kenmcd]

14 minutes ago, lacerto said:

The bottommost version in the PDF is an export from v0 Gilbert and the topmost from v1 version. 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 Gilber exports as curves:

gilbertv0.pdf 5.59 kB · 0 downloads

I also noticed that in VectorStyler (macOS) 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 a results of having v0 and v1 version of Gilbert Color (even if with different full name) installed on the same system?

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

The original Gilbert Color is only Color-SVG with PS outlines backup (.otf).

There are some conversions available for COLRv0 and COLRv1 (with SVG also) which do have conflicting names in them. The conversion tool does not typically fix the names. So if you have a bunch of those installed you will have name conflicts.

In the COLRv0 font I posted above, I fixed the names manually using ttx.
So it should have no name conflicts.

As far as how the font is embedded, or the image, that is up to the application.
And I am not sure what you have tried with what application and what font.

Additionally some of the fonts have multiple formats in one font,
and this may confuse some applications.
Or the application may just embed an image for some formats.

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.

The Patriotic font I converted presently has COLRv0, SVG, and TrueType in it.
Not sure if I should leave the SVG in there, the safe bet is to delete it.
Some smarter applications will use the "best" format for their needs.
Some dumber applications will see it has an SVG table, and quit, even though there are two other formats in the font which it does support and could use instead.
Affinity appears to be smart enough use the COLRv0, and ignore the SVG.

To check a particular embedding issue, need to see the specific font.

[lacerto]

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 SVGv1 and 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 SVGv1 version 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 SVGv1 Gilbert, 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.

[lacerto]

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. 

[kenmcd]

No, there is not a limitation on embedding with COLRv0 fonts.
How it gets embedded depends on what the application does, and the PDF library.

LibreOffice - both Gilbert COLRv0 and Patriotic COLRv0 embed just fine, as Type3 with Custom encoding, and it can be edited in color, and you can copy the text and paste the text into a text editor (so the ToUnicode is correct).
So my keyboard input is mapped to the COLR table glyphs.

Word - both Gilbert COLRv0 and Patriotic COLRv0 are embedded as TrueType (CID) with Identity-H encoding, and when you edit it is black not color, copying text does not work at all (so ToUnicode appears to be non-existent).
So my keyboard input is mapped to the black glyphs in the glyf table.

I got a different results when printing to various PDF printer drivers.
Each application is different.

What happens when you edit depends on how the characters & glyphs are mapped.
How well the application does this.
And how the font is constructed.
And how well your editor connects the mapping, and works around deficiencies.
Not some embedded fallback.

Affinity appears to "punt" and just embed the shapes, with no text info.

[lacerto]

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

[lacerto]

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.