[MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements

Wed Jan 6 02:08:55 CET 2021

The COLR v1 proposal does not attempt to provide some means to specify interaction between layers of different colour glyphs, and I think attempting to do that would become very problematic. I can envision how a font developer might like some controls, and in fact I recall some inquiries about exactly this a few years ago. But I think it's too problematic.

To keep consideration of this somewhat simpler, let's assume the COLR v0 model: there are glyph outlines arranged in layers and filled with colors. Potentially, one might want to control interaction of individual layers from one colour glyph with individual layers of another colour glyph-e.g., 

- If layer 4 of the colour glyph for base glyph ID 279 overlaps with layer 6 of the colour glyph for base glyph ID 380, then the layer from 279 is over (or is blended using mode X) the layer from 380.

For two specific glyphs, that would involve specifying interactions of M x N layers, assuming we can ignore any difference in relative ordering/positioning of the glyphs. But of course you'd have to generalize to N^2 glyph pairs. Even with some simplifying assumptions, that's extremely complex and a lot of data, as well as adding significant complexity in the rendering implementation.

If we consider COLR v1, the complexity is even greater since we don't just have painted glyphs stacked in layers. Each colour glyph is a description of a set of graphic operations, and the role of layering in the colour glyph description is different. So, for instance, a portion of the data of a colour glyph description might look like it describes two layered, graphic elements, while in fact it might be a single graphic element. (E.g., see the PaintComposite table and its subtables in Figure 5.38 on https://github.com/googlefonts/colr-gradients-spec#a2-changes-to-off-5711---color-table.) So, in this potential model of describing interactions of individual layers between different colour glyphs, a more complex mechanism would be needed to specify what element in a given colour glyph description is being controlled in its interaction with some similarly specified element of another colour glyph.

There's further complication for COLR v1 because of the re-use mechanisms. For instance, a colour glyph description might be a complete colour glyph description for one base glyph ID, but at the same time be a component composition used in one or more other colour glyph descriptions. So, in describing interaction of its elements with elements of other glyphs, there'd need to be a way to indicate this for the case in which it is used as a complete colour glyph description, but also for each separate case in which it is re-used as a component.

Now, the above is assuming a desire to control interactions between individual graphic elements of one colour glyph with individual graphic elements of another colour glyph. Things might be hugely simplified if the problem statement is reduced to only specifying a blending for one colour glyph as a whole with another complete colour glyph, should there be any overlap. But even this would be somewhat complicated since it would involve describing N^2 glyph pairs (assuming that positioning changes could be ignored): it would be a lot more data, and added complexity for rendering implementations.

Far simpler would be a blanket generalization. E.g., if two colour glyphs have any overlap, then the colour glyph on the right is layered on top of the glyph on the left. That doesn't provide a font author with any creative tools they can control, but it is unambiguous and would be feasible for implementations. Or, the spec could simply state that, if two colour glyphs overlap, then implementations are free to decide how they should be composed, and that they should do so in a consistent way - and perhaps also recommend to font developers that the bounding box of a colour glyph should not extend outside the side bearings, so as to avoid this issue and potential differences in behaviour of different implementations.

Of course, implementations will have to do _something_ if there is any overlap between two colour glyphs. But I think the best thing would be a general statement such as suggested in the preceding paragraph.

Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Laurence Penney
Sent: Tuesday, January 5, 2021 12:55 PM
To: Georg Seifert <typogeorg at gmail.com>
Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements

This is not part of the proposal as far as I know. I have not seen a good description of the problem yet.

A good solution would need to handle:

* Interference between adjacent lines, not just interference between adjacent glyphs. (Indeed the issue applies to all glyphs in the same text box, not just adjacent ones, bearing in mind that "text box" is a novel concept in OpenType.)

* Interfering glyphs with "incompatible" layer stacks; this implies a need to assign a layerID to each layer-glyph in a glyph (in general this would not be the same as its position in that colour glyph's stack), so the renderer knows which layer-glyphs are to be merged for each colour layer.

* Overlapping layer-glyphs in the same layer but having different colours (what is the blend mode?).

- Laurence

> On 5 Jan 2021, at 20:34, Georg Seifert <typogeorg at gmail.com> wrote:
> 
> Hello,
> 
> Is there an option to control color layers between glyphs. What I mean is that the background color from one glyphs is not painting over the foreground of the next (or previous) glyph. 
> 
> In the attached image the shadow of the C is covering a bit of the R. And it needs a absurdly wide spacing to make it work at all.
> 
> Best
> Georg Seifert
> 
> 
> 
> 
>> On 4. Jan 2021, at 22:33, Vladimir Levantovsky <vladimir.levantovsky at gmail.com> wrote:
>> 
>> Dear all,
>>  
>> Happy New Year! I hope you had a nice holiday break.
>>  
>> Please see attached for your review two input contributions I prepared based on the input to this AHG (and public GitHub discussions) on behalf of their respective authors. Since I did not receive any additional comments, I intend to submit these contributions to WG document registry by end of day today. 
>>  
>> Please also note that the contribution m55831 [summarizing COLR v1 updates] includes a number of highlighted unresolved topics that will need to be discussed as part of the break-out group session during the week of the WG meeting (Jan. 11-15, 2021). We need to finalize them by Jan. 15 if we plan to recommend the promotion of the current Working Draft amendment to the next Committee Draft stage.
>>  
>> Thank you all for your contributions, Vladimir
>>  
>>  
>> From: Vladimir Levantovsky [mailto:vladimir.levantovsky at gmail.com]
>> Sent: Sunday, December 27, 2020 1:59 PM
>> To: Peter Constable <pgcon6 at msn.com>
>> Cc: MPEG OT Spec list (mpeg-otspec at lists.aau.at) 
>> <mpeg-otspec at lists.aau.at>
>> Subject: Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
>>  
>> Hello all,
>>  
>> Many thanks to Peter, Rod, Dominik, and many other people who have contributed their review comments to the development and improvements of the proposed text for COLR v1 amendment.
>>  
>> Since the deadlines for registration and upload of input contributions is coming up soon, I would like to propose the following plan of actions:
>> - use the updated COLR v1 text from the public GitHub repo 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Fgooglefonts%2Fcolr-gradients-spec%23annex-a-proposed-changes
>> -to-isoiec-14496-22&data=04%7C01%7C%7Ce1bd520f901d443afd3508d8b1b
>> c3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637454769366086029
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
>> Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kiXwRGBJoU6f2mVaqiC14PC4Y%2Bc
>> 5bJTsjyYnnU%2F3KX4%3D&reserved=0 as the basis for the updated 
>> proposal;
>> - extend the current draft amendment with three additional amended 
>> parts proposed as part of MPEGGroup/OpenFontFormat discussions 
>> (issues 36-38);
>> - submit the AHG Recommendation to consider the proposed changes be used as a replacement to the current content of the Working Draft ISO/IEC 14496-22/AMD2.
>>  
>> Please submit your additional comments and proposed changes (if any) no later than the end of day on December 30. In absence of additional comments, and if no objections will have been raised by Dec. 30 - I will consider the current text of the proposal, along with the additional changes, to be approved by AHG consensus.
>>  
>> Thank you again for your contributions!
>> Vladimir
>>  
>>  
>> On Tue, Dec 22, 2020 at 10:00 PM Peter Constable <pgcon6 at msn.com> wrote:
>>> In the past few weeks, I've been working with Rod Sheeter and Dominik Röttsches at Google to draft updates for the working draft related to COLR version 1. This fills out details for the new formats added in COLR version 1 as well as integrating with the existing text for COLR version 0 (which doesn't go away).
>>>  
>>> The proposed content for OFF Amendment 2 is available here:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>> hub.com%2Fgooglefonts%2Fcolr-gradients-spec%23annex-a-proposed-chang
>>> es-to-isoiec-14496-22&data=04%7C01%7C%7Ce1bd520f901d443afd3508d8
>>> b1bc3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63745476936609
>>> 6024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G2d30Jfit8YiwxUttNvV36G
>>> b3H0cDP7tEkaEfecgUZc%3D&reserved=0
>>>  
>>> When the COLR v1 enhancements were proposed here back in September, the proposal doc had specific details on the structure formats, but not much explanation of the semantics - how the formats represent different graphic concepts and are to be processed. Much of the additional content in this draft is conceptual explanation of the graphic operations that are supported and how the structures are used to represent those, with several figures to illustrate. The intent was not obvious before, but should be clear now with these additions.
>>>  
>>> There have also been some further design enhancements in the proposed draft: additional paint table formats for translate, rotate and skew transformations-the separate formats are more compact than the matrix format if only the specific transform is needed, and the rotate/skew formats specify rotation angles in degrees, which is much better when varying a rotation angle in a variable font than varying the matrix elements.
>>>  
>>> There are a few open issues ("TBD: ." in that doc), but these are limited in scope and shouldn't hinder revision of the working draft considered by SC29 at the January meeting.
>>>  
>>> AHG members are invited to review and comment. I'd suggest that general comments not requiring specific action could be sent to this list, but for suggested improvement, it would be better to track these in GitHub issues-either in the GitHub repo above or in the MPEG/OFF repo:
>>>  
>>> Issues · MPEGGroup/OpenFontFormat (github.com)
>>>  
>>>  
>>> Re COLR v1 and OpenType: I've been preparing a parallel draft for the next OT version. That's in MSFT's typography repo, which is still a private repo. The content will differ from the OFF content only in minor, non-technical wording details.
>>>  
>>>  
>>>  
>>> Peter Constable
>>> _______________________________________________
>>> mpeg-otspec mailing list
>>> mpeg-otspec at lists.aau.at
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>>> ts.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=04%7C01%7C%7Ce
>>> 1bd520f901d443afd3508d8b1bc3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7
>>> C1%7C0%7C637454769366096024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
>>> WmPDtj1Tudx9LaDH9lvXwxdTLiI756i8SJPlDsiTBB0%3D&reserved=0
>> <m55831-COLR_v1_updates-14496-22-AMD2.docx><m55833-proposed_additions
>> -14496-22-AMD2.docx>_______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>> s.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=04%7C01%7C%7Ce1b
>> d520f901d443afd3508d8b1bc3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%
>> 7C0%7C637454769366096024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WmPDt
>> j1Tudx9LaDH9lvXwxdTLiI756i8SJPlDsiTBB0%3D&reserved=0
> 
> <Screenshot.png>_______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists
> .aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=04%7C01%7C%7Ce1bd5
> 20f901d443afd3508d8b1bc3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0
> %7C637454769366096024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WmPDtj1Tud
> x9LaDH9lvXwxdTLiI756i8SJPlDsiTBB0%3D&reserved=0

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=04%7C01%7C%7Ce1bd520f901d443afd3508d8b1bc3f43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637454769366096024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WmPDtj1Tudx9LaDH9lvXwxdTLiI756i8SJPlDsiTBB0%3D&reserved=0