Clarify // Each layer is OVER previous means COMPOSITE_SRC_OVER where backdrop is what we've drawn so far

The OT spec doesn't define how variation deltas can be applied to items that are F2Dot14. See discussion in https://github.com/PeterConstable/OT_Drafts/blob/master/COLR_V1/COLRv1_OpenIssues.md#varf2dot14.

@PeterConstable noted on #45:

But what about PaintGlyph > PaintTransformed > PaintComposite.src > PaintColrGlyph > ...?

I would like us to bias toward being permissive. I think the underlying issue is we need to add a bit more discussion around how things combine. My hope is we can define some simple guidelines.

The OT spec doesn't define how variation deltas can be applied to items that are Fixed. See discussion in https://github.com/PeterConstable/OT_Drafts/blob/master/COLR_V1/COLRv1_OpenIssues.md#varfixed.

• Add ISO OFF references to the MD
  • Intent of this is to become able to create the docx for ISO as a direct copy of what is in MD
  • Refer to OFF (ISO/IEC 14496-22:2019 “OFF”)
  • COLR: refer to subclause 5.7.11 “COLR – Color Table”
  • CPAL: refer to subclause 5.7.12 “CPAL – Palette Table”
• List all references for addition to the Bibliography section of the std
  • Probably most notably W3 Compositing
• Explicitly mark any content that should NOT be included in OFF
• Create said docx and upload to GH (work in the open!)
• Submit to ISO

To simplify implementation allocation of a drawing surface the bounding box of the glyph corresponding to the BaseGlyphV1Record should be taken to describe the drawing area for the COLR v1 glyph.

Somehow incorporate that the "non-color / outside-of-this-table bounding box of the glyph..." is used.

Note: A glyf entry with two points at the diagonal extrema would suffice.

Unlike Apple's sbix, with this format, the non-color glyph is NOT an empty. It conveys the same concept of the glyph in simple bicolor outline.

So the note should specify that if the color drawing's bounds are beyond the non-color, then adding "a degenerate outline with two points placed at two diagonal corners of the desired bounding box would suffice".

Some systems might filter out outlines with just one point on them. That's why is better to have both points be part of the same outline than each on its own.

Originally we added an Affine2x2 to linear and radial gradients because necessary. But since we have added an Affine2x3 now, I believe the Affine2x2s can be removed.

Compiling vector graphic sources, such as svgs, to COLR fonts will be significant to icon and emoji use cases (twemoji, noto emoji, and others come to mind). SVG allows application of opacity to multiple layers at once (by setting opacity on a group), meaning effectively render the group then apply opacity to the end result, as I understand it.

The current COLR spec doesn't allow for this. Building equivalent stacks of individually layers with opacity to match a group of layers with opacity appears tiresome. Also, when I tried to construct equivalent individual layers to a simple group opacity setup (courtesy of @anthrotype) by hand I immediately ran into halo effects (from anti-aliasing?).

Off the top of my head there are three main options

1. Use some 2D graphics technique I'm unaware of to build equivalent single layers to match the group w/o introducing artifacts. Hooray, there is no actual problem :)
2. Add the ability to designate groups of layers with opacity to COLR
3. Accept that this is not supported by COLR; the set of things we can represent in COLR just got smaller

In the proposal for COLR v1, all new values can be variable. But a font might want some items to be variable yet others static. The proposal doesn't indicate how to have static values if an ItemVariationStore is present.

See https://github.com/PeterConstable/OT_Drafts/blob/master/COLR_V1/COLRv1_OpenIssues.md#static-values-when-an-item-variation-store-is-present for details.

@PeterConstable raised this. I'll elaborate in a later comment.

There are multiple issues and wrong wording and wrong images and inconsistency about how we wrote this. Dominik and I thought about it extensively (at least half a day at the whiteboard) and we did reach a good solution. It just seems like we failed writing that correctly.

I'm a bit busy right now but within a few days I will fully describe all the issues and make recommendation.

https://github.com/googlefonts/colr-gradients-spec#extend-mode

Radial gradients can contain a 2x2 affine matrix to transform the two circles into ellipses, but without affecting the position of their centres -- unlike SVG's gradientTransform, or "graphics systems like Skia or Cairo that apply their (often called user-) transformation matrix to everything".
When rendering CORLv1 radial gradients using the latter graphics systems, one should thus apply the inverse matrix to the centres' coordinates to undo the effect of applying the matrix to everything.
But of course some matrices are singular or degenerate (with 0 determinant) and cannot be inverted.

The draft spec notes that even these have a "well defined shape", however it is not clear to me what this shape should look like. A visual example could help a lot here.

This is the relevant paragraph:

Note: Implementations must be careful to properly render radial gradient even if the provided affine matrix is degenerate or near-degenerate. Such radial gradients do have a well-defined shape, which is a strip or a cone filled with a linear gradient. Implementations using the inverse-transform approach noted above can fall back to a linear-gradient combined with a clipping path to achieve proper rendering of problematic affine transforms.

It's going to cause all sorts of fun if our offsets cannot "reach" things. Make more offset16's into offset32's, as @behdad pointed out in #48 (comment).

I suggest upgrading all Offset16's to Offset32. I have changed my position on this since it was designed (last week?)

This is particularly concerning:

// Glyph root
// NOTE: uint8 size saves bytes in most cases and does not
// preclude use of large layer counts via PaintComposite.
typedef ArrayOf<Offset16<Paint>, uint8> LayerV1List;

+1 to the friendly names.

The name PaintGlyph for format 6 doesn't clearly indicate what is distinctive about it vs. PaintColrGlyph.

The latter provides a color composition (an entire tree) for re-use. It's functionality has a lot of overlap with Transform (format 4); it's just that ColrGlyph uses a GID while the Transform uses a paint offset, and Transform includes a 2x3 while ColrGlyph doesn't. These are more similar than ColorGlyph is to Glyph.

PaintGlyph provides a geometry and fill, and it's the only way to put a fill into a geometry. But "PaintGlyph" doesn't really indicate that.

PaintColrGlyph reasonably indicates its functionality since it references a composition by the base glyph ID.

But perhaps "PaintGlyph" could be replaced with something like "PaintGlyphWithFill" or PaintOutlineWithFill?

The Affine2x2 is record-like in having a fixed size (though there's not an array of them). This spec makes it table-like in being referenced at an offset from its parent. Any particular reason why it wasn't just embedded in sequence within its parent?

Currently it's not. In GSUB/GPOS most offsets are from the beginning of whatever parent struct was referred to by an offset. I'll add followup comment with details of the problem. Filing for now so we don't forget.

PDF allows for extend behaviour to be defined separately for the start and end of a colour line. Should we extend the proposal to allow for that?

See discussion in <The OT spec doesn't define how variation deltas can be applied to items that are F2Dot14. See discussion in https://github.com/PeterConstable/OT_Drafts/blob/master/COLR_V1/COLRv1_OpenIssues.md#extending.

I'm looking at the noto-handwriting-colr_1.ttf file here, and not making sense of the data I see in the COLR table.

That's not a valid glyph ID.

So, either I'm mis-interpreting the spec, or the data, or both; or else the data and the the spec don't match.

(I suspect what's happening is that the font was written assuming that GIDs are always uint16, including in BaseGlyphV1 record -- the pitfalls of changing from past conventions!)

@behdad says in #57 "One thing not shown is color-lines where defined internal is NOT (0,1). Showing both intervals that are a subrange of that, as well as broader (eg. (-3,.5)) etc would be great as well."

&

@rsheeter suggested to show the simple case of P2=P0. I'll track that as an issue to update the examples further.

Add examples for a full glyph, consisting of several layers, using a variety of gradients.

If a font as a format 5 paint with an invalid / unrecognized compositeMode value, what should the rendering engine do?

https://www.w3.org/TR/compositing-1/ defines a "normal" mode in which the source is overlaid on the destination with full opacity (B(Cb, Cs) = Cs). The CompositeMode enum doesn't include normal (and normally it wouldn't be needed).

In the unrecognized mode case, should the "normal" mode behaviour be used? Or multiply? Other?

In the current proposal, format 6 can be used to reference a glyf outline and map it to a Paint table:

// Paint a non-COLR glyph, filled as indicated by paint.
struct PaintGlyph
{
uint8 format; // = 6
uint16 gid; // shall not be a COLR gid
Offset16 paint;
}

What does this enable that can't otherwise be implemented by creating a BaseGlyphV1 record using a virtual glyph ID, then having an associated LayerV1List with a single Paint? Is format 6 just a short hand that saves a glyph ID and a few bytes?

In #3 LP mentions the "white on black" issue. He notes a mechanism that's already defined in the current COLR spec:

"A palette entry index value of 0xFFFF is a special case indicating that the text foreground color (defined by a higher-level client) should be used and shall not be treated as actual index into CPAL ColorRecord array."

And so suggests that an additional special case be defined in COLR, 0xFFFE, to mean "punch a hole in all previous layers".

Another approach that could be considered would be to add a separate flags field in the layer record. The flags could be used to indicate different blending options with previous layers, including "punch all previous layers", or "punch previous layer". (When punching, the separate paletteIndex could indicate a fill for the punched area?)

Note: I haven't thought through in detail what potential benefits are, or what problem would remain if not provided. (E.g., wouldn't it work to just add another non-punch layer on top?) The original issue that brought this up had to do with winding interactions of overlapping contours within a single glyph, not any interaction between different glyphs. So, I'm just throwing this out for discussion.

In PaintTransformed, the transform is currently shown as an inline record, in contrast to format PaintRadialGradient in which the transform is a table at an offset.

I just want to confirm that's the intended design.

In every 2D graphics spec I've looked at today (HTML canvas, PDF, Skia, Direct2D), I've noticed that linear, radial and conical gradients are specified using separate coordinates, "x0, y0, x1, y1" rather than combining xy pairs into structs. (GDI was different in that regard.)

Would it be better if, instead of defining a Point struct we just used a pair of VarFWords instead? (One less struct to document, and more similar to current 2D graphics APIs.)

The current proposal is missing support for mesh gradients. Should this be added?

High level: it wasn't quite clear how the introductory content folds into OFF. Make that clearer. I think that means much of it needs to be landed in the COLR table.

The color table currently exists in 5.7 Optional tables. I think we should propose it moving up (5.x COLR) similar to how SVG is 5.5.

I believe the suggested order of content for COLR was:

• intro section describing primitives
• table structures / formats
• examples 

We might want to emphasize the variable capabilities more.

In #74 there was some discussion of where the Constraints section should live: under COLR table or at a higher level. Currently it is at OFF Changes > COLR table > Constraints, which is roughly where it appears it would land in OFF.

I think if we think about how closely we want to align with OFF the answer to where Constraints and some of the content in Introduction (Back compat, Graphical primitives) should land will become more clear. The advantage of trying to align very closely with OFF is it minimizes the need for an editor to restructure the content. The disadvantage is it may put the content into a layout we wouldn't otherwise choose.

I'm happy to move things around based on what we decide.

@drott wdyt?

@Lorp noted on MPEGGroup/OpenFontFormat#20 (comment)

The table at line 170 defines an Affine2x3 matrix with two translation elements, dx and dy. It it intentional that these are VarFixed (16.16) rather than VarFWord (16-bit integer)? It seems to imply that a renderer needs to keep track of fractional point locations.

In glyf table the component x and y offsets are integers, just like the simple glyph point coordinates are. Also in this draft spec, the gradients' end points are encoded as integers (VarFWORD).
Allowing fractional point locations as result of PaintTransform would be inconsistent with that.

The spec needs to be clear as to how the transparency values that go with each paletteIndex should interact with alpha values in CPAL entries. If they are combined, how they combine needs to be made clear.

Currently the data structures and table strucuture are expressed in a C-style syntax. Consider moving those to an appendix and rephrase normative parts to match style in the OpenType specification.

It's clearly misleading; it clips not fills. PaintClipGlyph?

Explain nesting of clips == intersection

I think normally the center of one circle (the gradient origin, stop position 0) would be within the circumference of the other circle (stop position 1). But the possibility exists that it is not: you could have two overlapping or even non-overlapping circles.

So, what should be expected if that were the case? Do we need to treat that as invalid in OT, or just let different graphics libraries handle that however they will? (That could mean a font displays differently on different platforms.)

Is there some limit to avoid circular definitions? Or does the layout engine just check to see if a Paint at a given offset occurs more than once between any root/leaf path?

The proposal has this:

Implementations should track the COLR gids they have seen in processing and fail if a gid is reached repeatedly.

But formats 4 and 5 reference paint tables without using a gid.

The draft introduces a pattern for structures that doesn't have existing precedent in OpenType. It's certainly implementable. But would it be preferable to stick with existing models already used?

I noticed this while trying to implement the draft in a old parsing implementation I have in VB: For an array of base glyph records each of which has an offset to a (different) array of layer records, I was going to end up creating a collection of collections. I had previously only ever done that for an interpretation of structures (e.g. glyph IDs in a glyph class).

A different approach that would follow an existing precedent would be to have v1 BaseGlyph be a table (not record) that includes an array of layer records, each of which has an offset to a Fill table. That would match the model currently used for ScriptList and FeatureList.

The LayerV1List no longer contains an array of LayerV1Records. It now contains an array of Paints. What used to be called a "layer" record is now subsumed as another Paint format 4 (PaintGlyph).
I find it a bit confusing that we subtly change terminology while we define the structs from talking about "layers" (e.g. in the name "LayerV1List") to talking about "paints" (e.g. where we say "LayerV1List" contains list of "paints").
I believe I would find it clearer if we only talked about Paints instead of layers.

I understand that multiple paints are "layered" (as if composited with previous paint using SOURCE_OVER operator) following the z-order of LayerV1List. And that a single "layer" is understood as one (bounded) DAG of paints; so the LayerV1List is a sequence of paint DAGs layered over each other.

What do you think of renaming LayerV1List to PaintList? We'd also ditch the "V1" from the name, since this new structure is quite unlike the V0 one.

Feel free to dismiss/ignore, I don't mean to open a can of worms.

Explain in more detail what happens when the range is defined on an interval other than 0 to 1. Smaller, larger, partially overlapping, etc.

From the draft I read, it looks like that, this format is created only for sharing data across glyphs. However, since paints are referenced with offsets, it is simple to reuse the same paint for multiple glyphs / upper-layer paints, by pointing the offsets to the same target.

So should we either remove this format, or specify that using a PaintColrGlyph instead of just stretching the offsets do carry semantics, and they are semantically different, even if they are visually the same?

Currently, there's one Affine2x2 for both circles. That allows the cylinder defined by the two circles to be uniformly elliptical. But conceptually it would be possible to have a cylinder defined by two separately-transformed circles.

Adding a second offset field could allow separate transforms for start and end circles. If one offset is null, the same transform could be applied to both.

Thoughts?

I'm of two views in general, both of which have not been followed in the spec consistently before:

• Use types that are wide-enough that won't run out of space, even for (reasonable but) unanticipated uses (eg. 60k axes!). Avoiding Offset16 in most cases is part of this design philosophy.

• Don't waste bytes if not necessary. Before we've been using a lot of uint16 version numbers, even separate uint16 major/minor ones. That's a waste. Currently proposal use of uint8_t for format / Extend / CompositeMode is in line with that.

Now. The very issue of alignment that Peter seems to be obsessed with in other parts of the spec, is fully ignored here.

We should introduce an Offset24 type, and use it next to uint8_t types when possible, to save a byte without limiting what's reachable, and making it faster as well because fetching one (aligned) int is faster in modern memory systems than fetching one unaligned int, which is implemented as two aligned int fetches.

I'm wondering generally about the smaller, more basic structures: to what extent to define and name based on usage in this context versus naming more generally based on data types (and perhaps internal validation constraints).

Also, I'm thinking for structs that combine a basic type with a delta-set index the name should be prefixed with "Var" to reflect that.

• "Scalar": In this context Fixed is used to scale / as a coefficient. Other things could be scalars (e.g. F2Dot14), and Fixed could be used in other ways. An alternative name "VarFixed" would reflect the type without assuming how it's used.

• "NormalizedScalar": alternative possibility: "VarF2Dot14"

  • There is a variant used in Color that limits the range to [0, 1]. That's a different validation constraint. So, something like "VarF2Dot14Magnitude" (magnitudes are non-negative) could perhaps also be defined.

• "Position": since the type used in the template is FWORD, that does limit the context to design-grid values. Otherwise we could generalize to int16 and call it something like "VarInt16".

  • "Position" can suggest (x, y). I think "VarCoordinate" or "VarCoord" would be clearer.

• "Distance": similar to the previous item, use of UFWORD does limit the context to design-grid values. Otherwise, we could generalize to uint16 and call it something like "VarUint16".

• "Point": alternate suggestion "VarPoint"

• "Color": Incorporating "Var" here is trickier since there are two primary members, paletteIndex and transparency, and only the latter is variable. "ColorIndexVarAlpha" is a bit awkward but clear.

All the other structs in the proposal (ColorStop on up) are more complex. I wouldn't propose prefixing "Var" on any of those names.

V0 fields:

"Color stop position 1 maps to the end point of a linear gradient or the center of the second circle of a radial gradient."

This is non-intuitive. (More intuitive would be going from the center of one circle to a point on the circumference of a second circle.) The figure for linear gradients showing P2 being different from P1 is informative and helps make clear what was non-obvious: why a linear gradient would be defined using two vectors. It would be helpful to have a figure for radial gradients that similarly illustrates the non-obvious aspect of how the second circle is used in defining a radial gradient.

The proposed spec defines

template <typename T, typename Len=uint16>
struct ArrayOf
{
  Length count;
  T      array[/*count*/];
};

A consequence is that, if an array of records is referenced by offset, then the count is located at that offset.

There are several other places in the OT spec where there is an array of records at an offset. E.g.

CPAL: offsetFirstColorRecord, offsetPaletteTypeArray, offsetPaletteLabelArray, offsetPaletteEntryLabelArray
EBLC: indexSubTableArrayOffset
MERG: offsetToClassDefOffsets
STAT: offsetToAxisValueOffsets

In no case is the count for the array stored at the start of the array.

Moreover, storing the count at the start of the array can create redundancy and potential for inconsistency. For example, the arrays in CPAL all have the same count. If the count were stored separately for each array, that would create a possibility for inconsistency that doesn't exist by having a single occurrence of the count outside of the arrays.

Also, by changing this convention, we increase potential for confusion and for buggy implementations. (I stumbled over this myself.)

So, count for the BaseGlyphV1Records array should be in the CPAL header.

(Similarly, the definition for BaseGlyphV1Record needs to have numLayerV1Records as a field, and ColorLine needs to have numStops or numColorStops as a field. Those cases are structurally the same, so not quite the problem that exists for the BGRV1 array at an offset.)

The draft makes use of C++ templates and unions. These are fine for implementations but should not be used in the OpenType spec.

(Not really a problem since conceptually these are just notational short hands to save writing out multiple structure specs.)

the CORLv1 draft says

If the dot-product (P₁ - P₀) . (P₂ - P₀) is zero (or near-zero for an implementation-defined definition) then gradient is ill-formed and nothing must be rendered

However, the SVG spec says that when the end points overlap, one should render as a solid paint with the last stop's color and opacity:

https://www.w3.org/TR/SVG/pservers.html#LinearGradientNotes

If ‘x1’ = ‘x2’ and ‘y1’ = ‘y2’, then the area to be painted will be painted as a single color using the color and opacity of the last gradient stop.

Can we not do the same when P2-P0 vector is perpendicular to the P1-P0 vector?

https://github.com/googlefonts/colr-gradients-spec/blob/master/colr-gradients-spec.md#color-palette-variation currently reads "Colors expressed in sRGB r/g/b channels cannot be easily interpolated. Another solution is needed, perhaps involving transforming to a linear color space and back."

Courtesy of Romain Guy I have a concrete suggestion on how to interpolate in linear space: "apply the color space's EOTF before interpolating, then apply the OETF." I hope I'm not the only one who had to look up the terms :D

Android implements this for animated colors and users seem satisfied. https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/animation/ArgbEvaluator.java. Related, https://developer.android.com/reference/android/graphics/ColorSpace.Named gives names and equations [in source] for a bunch more color spaces.

I suggest we might consider directly adopting this approach; it's been used in real world animation and has a well defined implementation :)

https://www.colour-science.org/posts/the-importance-of-terminology-and-srgb-uncertainty/

It's unclear what the thinking was behind using 32-bit glyph IDs in the base glyph and layer records. (Note that v0 structures use uint16.)

• building in forward compatibility to a future in which fonts can have > 64K glyphs?
• keeping 4-byte-integral structures?
• other?

Note that this adds at least 6 bytes of padding to every colour glyph. For an emoji font, that will be an additional 12K to 20K (or more?) of padding.

(I'm not opposed, just want to understand the thinking behind proposing it, and to make sure the size implications are understood.)

The CPAL table uses "alpha", not "transparency".

CSS uses "alpha" in a context of specifying color values, e.g., rgba(). In other places, it uses "opacity".

• "transparency" would suggest that a value of 1.0 is fully transparent.
• "opacity" would suggest that a value of 1.0 is fully opaque.

I believe the latter is intended. So, I suggest that field in the Color struct be renamed "opacity" or "alpha". I think "opacity" is clearer.

I would be pleased if another issue can be considered in this round of CPAL/COLR updates.

The “white on black” issue concerns colour-inverted b/w glyphs as seen in this image, from @adobe-fonts’s white-on-black-vf repo, which contains a test font with this glyph.

Top: actual behaviour. Bottom: desired behaviour

As can be seen, the “white” or transparent parts of the glyph cannot use the overlapping contours that are useful in the “black“ or opaque parts of variable fonts.

In May 2019 @readroberts started a discussion on the [email protected] list (subject line Need new path fill rule for variable fonts with white on black glyphs), in which I suggested a COLR/CPAL approach. Later that month, @kenlunde posted the Adobe test font mentioned above to GitHub. In August 2019, Read summarized three possible approaches in an issue posted to the opentype-variations repo: “White on Black” VF Rasterization Issue:

1. a new rendering rule treating negative and positive winding differently
2. a COLR/CPAL solution
3. support for more complex graphics operations proposed by Renzhi Li

Read’s summary is well worth reading in full. He comes out firmly in favour of (1), a new rendering rule.

To me the rendering rule solution seems lined up for years of incompatibilities while rasterizers catch up, elegant only if we had a blank sheet. As Read acknowledges, it requires methods to export normal text glyphs as composited graphic objects for the vast number of system components that use OpenType fonts.

Back to COLR/CPAL

It seems to me that COLR/CPAL is a pretty good solution. It is explicitly about layers. And it has a built-in fallback mechanism (to a b/w simple or composite glyph) for rasterizers that don’t support it (or that version of the tables). It lacks the ability to define masks, but we can spec that easily. An updated COLR table would define certain layers as "mask". We already have one special value in COLR, 0xFFFF:

A palette entry index value of 0xFFFF is a special case indicating that the text foreground color (defined by a higher-level client) should be used and shall not be treated as actual index into CPAL ColorRecord array. — COLR table specification

We can define 0xFFFE as the “mask” paletteIndex. Any layer “coloured” with paletteIndex 0xFFFE would punch holes in whatever had been built up so far.

Typical use would be to have a single mask layer at the top of the stack, but it may be useful to have multiple mask layers at various positions in the stack.

COLR glyphs already piggy-back on top of the existing rasterizers, and this extra step seems to me less onerous than updating the core rasterizer. The SVG <clipPath> element makes this technique easily translatable to SVG.

Read had three objections to the COLR solution, which I list here for consideration:

The problem is really one of rasterization for normal text fonts. Since the ‘COLR’ table conveys the meaning of being a color font, it doesn’t seem to be the right place to be solving this problem, which is fundamentally a non-color one. Also, this could lead to problems with heuristics, such as font classification.

There may also be some loss of effectiveness of anti-aliasing and hinting. Text renderers have been heavily optimized over the years for different environments. We suspect that some of this optimization could be lost when the ‘white’ paths are applied as a mask.

Use of the ‘COLR’ table currently requires explicit opt-in on the part of the user, which is passed down through the API. This new use of the ‘COLR’ table would need to differentiate between the current use case, which is opt-in only, and the new use case, which involves the ‘COLR’ table being applied to the glyphs in question.

In respect of the anti-aliasing and hinting issue, it may be a worthwhile optimization for renderers, when processing COLR glyphs that only use paletteIndices 0xFFFF (opaque) and 0xFFFE (transparent), to use a rasterizer path tuned for font rendering.