[MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.

Fri Jan 22 17:47:40 CET 2021

Hi, William

I believe the terminology used in the spec is clear and that no additional terminology is needed. How concepts are referred to in font development tools is up to the designers of those tools.

> Does the system now allow/ will you please consider allowing, similar 'tunnel through' colours

I don’t think defining specific palette index values as special “accent” colours is such a good idea. Whereas all text necessarily has some “foreground” colour, that is not the case for “accent” colours: in many contexts, they simply will not be defined, and so there would be no predictability as to how they would appear.

There are certain applications, such as PowerPoint, that have content colour palettes that would provide “accent” colours, but such applications are very much the exception. And in such applications, there is nothing to prevent the application from providing UI for users to define custom palettes that get used instead of the palettes in the CPAL table. Since the usage scenarios for your feature would only make sense for such apps that have UI for content palettes, I think having such apps allow the user to define the palette for the font makes the most sense.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of William_J_G Overington
Sent: Friday, January 22, 2021 2:39 AM
To: mpeg-otspec at lists.aau.at
Subject: Re: [MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.

Regarding the parlance, maybe I am wrong about this but it seems to me that there is a gap, in that it seems to me that three terms are needed, yet there are only two defined.

I refer to the specification terms base glyph and colour glyph. I was familiar with the term base glyph but not colour glyph as used in the specification.

In my writing I have used three terms, as follows.

base glyph, as the specification has it.

coloured glyph for each glyph that is one colour

colourful glyph as what the specification has as colour glyph

For example, as in the following from page 2 of Chapter 3 of my novel The Mariposa System.

http://www.users.globalnet.co.uk/~ngo/the_mariposa_system_the_novel_chapter_003.pdf

> ‘Now to try to build the colourful glyph!’

> Mariposa goes into colour mode and adds the two coloured glyphs to the monochrome glyph, noting that the monochrome glyph had disappeared when she enters colour mode.

For information here, that is describing the process used in the High-Logic FontCreator 8 software that I use. I do not know how construction of the colourful glyph is done in other software, but it seems to me that three items of parlance are needed generally, because a completed OpenType COLR/CPAL font has some of each of what I have named base glyph, coloured glyph and colourful glyph.

On a different aspect of the specification, originally if one used FFFF as the colour index it allowed the colour actually used to be set by the end user as the foreground colour. Does the system now allow/ will you please consider allowing, similar 'tunnel through' colours, so that there would be a feature whereby an end user could also select in an application first decoration colour and second decoration colour so that, say, one could have, for example, a font with some glyphs of holly with berries and the end user could choose to have green leaves with red berries or gold leaves with silver berries or whatever colour combination desired, with the way that the specification is done such that there is a default colour? So, for example, displaying the glyphs in an application that does not have a decoration colour choosing facility, or it is switched off, the holly appears as green leaves with red berries yet the colours can be chosen by the end user in applications where a decoration colour choosing facility is available and switched on.

William Overington

Friday 22 January 2021

------ Original Message ------
From: "Peter Constable" <pgcon6 at msn.com<mailto:pgcon6 at msn.com>>
To: "Chris Lilley" <chris at w3.org<mailto:chris at w3.org>>; "mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>" <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>
Sent: Thursday, 2021 Jan 21 At 17:03
Subject: Re: [MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.
FYI:
While the draft provided before the recent SC29 meeting already included linear and radial gradients, we have had in mind to also propose adding support at some point for some other gradient types: sweep (or “conic” / “angular”) gradients, and mesh gradients.
Mesh gradients are _very_ different from other gradient types both in nature and in how they are defined, and there are two types (Coons patch, which use bilinear interpolation, and tensor patch, which use bicubic interpolation. Those definitely will need some time for investigation and design discussion.
But sweep gradients are, comparatively, similar to linear and radial gradients: they are defined by a color line that gets applied to a surface in some geometric way. Linear, radial and sweep gradients are the three basic gradient types that are commonly supported in 2D graphics apps or libraries.
With that in mind, we’ve decided to extend our proposal for COLR version 1 to include sweep gradients. See our proposal doc at https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md; a description of sweep gradients is added in new sub-clause 5.7.11.1.2.4.
Peter
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto:mpeg-otspec-bounces at lists.aau.at>> On Behalf Of Chris Lilley
Sent: Saturday, January 16, 2021 5:05 AM
To: mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.

Combining the graphical expressiveness of SVG with the typographic expressiveness of font variations (and of course using vectors not rasters) will make COLRv1 the clear leader among the assorted chromatic font options.
On 2021-01-14 23:04, Peter Constable wrote:
But it also goes beyond the SVG table in that everything (for which it would be meaningful) in the formats is variable. So, for instance, in a variable font, things that could be varied include the placement of colour stops in a gradient, alpha values, rotation angles, and more.

--

Chris Lilley

@svgeesus

Technical Director @ W3C

W3C Strategy Team, Core Web Design

W3C Architecture & Technology Team, Core Web & Media

________________________________
_______________________________________________

mpeg-otspec mailing list

mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>

https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210122/8e631262/attachment-0001.html>