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

William_J_G Overington wjgo_10009 at btinternet.com
Fri Jan 22 19:21:54 CET 2021


Hi Peter


Thank you for replying. I had not seen your email until after I had sent 
my previous email.

> I believe the terminology used in the spec is clear and that no 
> additional terminology is needed.
Fine, I accept your expert opinion.
> How concepts are referred to in font development tools is up to the 
> designers of those tools.
Again I accept your expert opinion.
There does however remain the parlance available in more generic textual 
contexts, including my novel, general manuals on fontmaking and so on. 
It would be good if someone could move from one proprietary brand of 
fontmaking software  to another proprietary brand to a generic text book 
and be able to use the same parlance and not need to keep learning 
different parlance for each. So maybe the parlance used in my novel will 
become the norm, maybe not, maybe there will not be a norm.
>> 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.
Well, that is one vote for and one vote against. So maybe others will 
vote too, and we can note the result.
> 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.
Actually I think that that is not necessarily the case, because dec col 
1 and dec col2 would each have a default colour in the specification and 
a fontdesigner could change either or both of those colours during the 
fontmaking process. So an application program would always have a 
default colour provided to it for dec col 1 and dec col 2 as if they 
were any other colours.
> 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.
Well, that sounds like a good idea. I had not thought of that.
> 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.
Well, the idea is before the group so let us leave the matter open and 
hopefully get some more views from the group.
Whichever way it goes maybe in one way or another the display effects in 
the end user produced document that can be produced by application 
software will be enhanced because of ideas people get implemented as a 
result of this discussion. In fairness it does seem to me that your 
suggestion would also work using COLRv0 fonts as well as COLRv1 fonts 
whereas my suggestion would not work with COLRv0 fonts even if my 
suggestion were to be accepted for COLRv1, so that seems a big advantage 
for your idea in the short term at least and maybe in the long term too.
Best regards,
William Overington
Friday 22 January 2021








------ Original Message ------
From: "Peter Constable" <pgcon6 at msn.com>
To: "William_J_G Overington" <wjgo_10009 at btinternet.com>; 
"mpeg-otspec at lists.aau.at" <mpeg-otspec at lists.aau.at>
Sent: Friday, 2021 Jan 22 At 16:47
Subject: RE: [MPEG-OTSPEC] Requesting progress update on COLRv1 in 
fontTools, FreeType, etc.


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









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


More information about the mpeg-otspec mailing list