[MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
William_J_G Overington
wjgo_10009 at btinternet.com
Sat Jan 9 11:44:12 CET 2021
Hi
Could there be a one-bit flag somewhere such that a font designer may
choose which form of overlapping transparency behaviour is desired?
Or maybe two flags, each of one-bit, the first to indicate whether the
font designer has specifically indicated which form of overlapping
transparency behaviour is desired and the second to indicate, if the
font designer has made a specific choice, which form of overlapping
transparency behaviour the font designer has chosen.
William Overington
Saturday 9 January 2021
------ Original Message ------
From: "Peter Constable" <pgcon6 at msn.com>
To: "Vladimir Levantovsky" <vladimir.levantovsky at gmail.com>; "'Georg
Seifert'" <typogeorg at gmail.com>; "'Laurence Penney'" <lorp at lorp.org>
Cc: "'MPEG OT Spec list'" <mpeg-otspec at lists.aau.at>
Sent: Saturday, 2021 Jan 9 At 03:30
Subject: Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
While reading the CSS Color Module Level 4 draft
<https://www.w3.org/TR/css-color-4/> , a related complication was
brought to mind by figure 11:
If two elements of a composition overlap and have alpha < 1, their
alphas would combine. What figure 11 is showing is a case in which the
alpha is applied to the text as a whole (the containing text element).
But it brings to mind an issue for color fonts if glyphs are
overlapping: In the case of a font like Use Your Imagination, the colour
glyphs’ layers have alpha < 1, the glyphs intentionally overlap, and the
expectation is that the alphas in the overlapping regions combine. E.g.,
But one could imaging a different colour font for a cursively connected
face in which overlapping glyphs have connections with fills of the same
colour and alpha, and with the intent that the alphas do not combine but
that the overlapping regions are intended to display with the same
alpha as the stroke from each glyph would have—as in figure 11 above.
The main point here is to point out one more way in trying to control
compositional interactions between adjacent colour glyphs is non
trivial, and a single example isn’t a sufficient representation of usage
scenarios.
Peter
From: Vladimir Levantovsky <vladimir.levantovsky at gmail.com>
Sent: Wednesday, January 6, 2021 2:23 PM
To: 'Peter Constable' <pgcon6 at msn.com>; 'Georg Seifert'
<typogeorg at gmail.com>; 'Laurence Penney' <lorp at lorp.org>
Cc: 'MPEG OT Spec list' <mpeg-otspec at lists.aau.at>
Subject: RE: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
> Your suggestion below sounds relatively simple, but I’m not sure it’s
> as simple as it seems.
+1!
I don’t think it’s simple. If we assume it’s implemented …
* the number of layer groups can’t be prescribed, it would be up to
a font developer to decide. We may think we do not need more than three
layer groups but it’s not up to us to decide;
* we cannot assume to know the “meaning” of the layer group.
Something simple, like e.g. “background” or “drop shadow” may seem
straightforward, but like Peter said, even that can be problematic
because shadow directions cast from a virtual light source would affect
rendering results based on direction;
* even if we think it’s ok to allow overlaps between glyphs in the
same layer group – the overlaps of translucent background layers may
still need blending;
* applications would have to completely change their text rendering
pipeline, starting with the need to determine a number of layer groups
from the font [possibly, per glyph]. Combining different glyph ranges on
page may require different number of rendering layers (e.g. color +
monochrome glyphs on the same line of text), multiple layers need to be
rendered, and it would have to be redone every time there are any
viewport / layout / spacing / scale changes …
* in my opinion, any proposed change that affects how applications
interact with fonts is a non-starter.
Thanks,
Vlad
From: mpeg-otspec [mailto:mpeg-otspec-bounces at lists.aau.at
<mailto:mpeg-otspec-bounces at lists.aau.at> ] On Behalf Of Peter Constable
Sent: Wednesday, January 6, 2021 2:35 PM
To: Georg Seifert <typogeorg at gmail.com <mailto:typogeorg at gmail.com> >;
Laurence Penney <lorp at lorp.org <mailto:lorp at lorp.org> >
Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at
<mailto:mpeg-otspec at lists.aau.at> >
Subject: Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
Georg:
To discuss what might be feasible, I think we really need a better
understanding of what set of problems might be solved. There has to be
some limit to the functionality—we can’t provide Illustrator in a
TTF—and I think to be feasible any additional capabilities would need
to be very minimal. The original use case that made colour fonts a
reality was emoji, and I think none of this is needed for emoji. But
this question really pertains to text faces. What are the kinds of
effects
You've given one example, with letters that have a 3D extruded
appearance, with the bodies of the letters not overlapping, but each
having a layer for a shadow that extends (at least for some glyphs)
beyond the left side bearing. Of course, the shadows could have gone to
the right (virtual light source on the left), in which case the problem
might not occur at all (at least for some implementations) because of
how rendering is done. Note that the problem, in the most general case,
isn't limited to colour fonts, but can also arise for achromatic fonts
if adjacent glyphs overlap and are styled with different colours. Here's
an example using Calibri with letter spacing condensed to create
overlap:
ABCD
ABCD
Here’s a screenshot of how this appears in my mail agent:
Now, each glyph overlaps on top of the glyph on its left. Someone might
say, “Oh, but I want them to layer the opposite way.” That doesn’t imply
there’s a compelling business case for text layout engines to add an
option to control how overlapping glyphs layer.
I do understand that this non-colour font example isn’t entirely
applicable to colour fonts, but it raises a valid question: how much
machinery does it make sense to add, and what is an appropriate
threshold of diminishing returns.
Btw, I mentioned the Use Your Imagination
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fontspace.com%2Fuse-your-imagination-font-f43274&data=04%7C01%7C%7C57c87363b8634946d3d408d8b2919cd9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637455685753903745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=knql33%2BclsVAiNEn17ZxPntDmbcfcdtgDVZoYlIKryY%3D&reserved=0>
font, which has overlapping glyphs that have some transparency and so
blend with simple alpha blending. If you look at the examples or try it
out, you’ll notice the same right-over-left layering of adjacent glyphs,
which is manifested by the drop-shadow effect (a transparent black
layer). The shadow effect used in this font didn’t require any
additional data in the font. (That font was implemented using OT-SVG,
but could just as well have been implemented using COLR v0.)
Your suggestion below sounds relatively simple, but I’m not sure it’s as
simple as it seems. First, there’s the question of what additional data
is needed to describe layer groups. As I mentioned earlier, this
wouldn’t be difficult for COLR v0 colour glyphs, but for COLR v1 the
notion of layer is not so simple. Then there’s a question of what
controls for blending of corresponding layer groups from adjacent glyphs
should be provided: would only simple alpha blending be sufficient?
Without example use cases, how do we decide that?
Then, there’s the implication for text rendering engines: it implies
that engines must render all colour glyphs in each line in three
separate passes: layer groups 0 for all glyphs in the line, then layer
groups 1, then layer groups 2. Is that additional complexity in
rendering implementations worth it? I think more business justification
would be needed to convince implementers.
Peter
-----Original Message-----
From: Georg Seifert <typogeorg at gmail.com <mailto:typogeorg at gmail.com> >
Sent: Wednesday, January 6, 2021 9:55 AM
To: Laurence Penney <lorp at lorp.org <mailto:lorp at lorp.org> >
Cc: Peter Constable <pgcon6 at msn.com <mailto:pgcon6 at msn.com> >; MPEG OT
Spec list <mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at> >
Subject: Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1 enhancements
I don’t think we need to have control for M x N layers. Assigning a
layer group ID would be sufficient. And I don’t think in most cases we
need more than three groups (e.g. background/shadow, body, highlights;
and in most cases body and highlights can be drawn together). This will
not add much complexity. Draw all layers from each group for all glyph
in the text box. I don’t think special control for blending between
glyphs is needed, just draw then as it is now.
so instead of drawing:
A.layer0, A.layer1, A.layer2, B.layer0, B.layer1, B.layer2
we do (assuming that layer0 and layer1 are in one group):
A.layer0, A.layer1, B.layer0, B.layer1, A.layer2, B.layer2
Georg
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210109/f1037a1c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 65003 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210109/f1037a1c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 160708 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210109/f1037a1c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6225 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210109/f1037a1c/attachment-0005.png>
More information about the mpeg-otspec
mailing list