Google and I are proposing that this be the basis for a proposed new edition of OFF.

Is there any particular reason to recommend this to be processed as a new edition instead of an amendment? The proposed changes seem to be rather localized to few specific parts of OFF text, I would recommend that we should consider doing this work as an amendment of the existing standard like we discussed earlier on the email list, and start a new edition when we are ready to tackle much more substantial changes that might include a significant editorial update at the same time.
Processing these changes as an amendment will be easier from the procedural point of view (significantly lower amount of editorial / administrative efforts), and things that are easier to do will likely happen in a shorter timeframe.

A new amendment would also work.

Two short questions:

• LayerV1List: should we use Offset32 data type for paintOffset[numLayers] fields?
• Also if a layer directly referred a format 1, 2, or 3 paint, then what should the client do? Fill the entire screen or drop this layer?

Discussion of the preliminary Google proposal when back and forth on Offset16 vs. Offset32. You can certainly recommend it be changed to Offset32.

In the attached draft, the Paint formats that take a paint subtable currently indicate constraints on the formats that can be used as subtables (e.g., format 6 allowing only the fill formats 1, 2, or 3.) A constraint glyph be added to LayerV1List that the referenced paint subtables must be one of formats 4, 5, 6, or 7 (not the fill formats).

Alternately, if the general consensus is that those currently-stated constraints are too restrictive, they could be relaxed. But then it would need to be made clear what the intended semantics should be in each case, as with your question: fill the screen, or drop the paint?

I'd like to suggest that, to prevent the length of this issue descending into the depths of ...recent issues on this repo 😂 ...that comments here be limited to simply saying "no objections" (or a thumbs up reaction to the first post) or "I have concerns about these issues" and then filing separate issues. That way Vlad can set up a "colr v1" milestone, and we can all easily see how progress is going on closing out all the open issues related to this set of spec updates.

Milestone can also have a Target Dates attribute applied, so we can see easily how close we are to closing all the issues before the associated date.

Another concern for me is the necessarity of PaintColrGlyph (paint format 7), if such format is introduced only for data sharing: 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 that, format 7 seems unnecessary.

Cross posted: googlefonts/colr-gradients-spec#51

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.

@Lorp @anthrotype : the rotation part of an affine transform definitely needs to have fractional parts (and sufficient precision too) to accommodate arbitrary angles, and the 2x3 matrix needs to have elements all of a uniform same type, for the mathematics to work correctly. So Fixed 16.16 for all 6 is appropriate.

Edit: The rotation / shear part is the other 4, and would take values (sin x, -cos x, cos x, sin x) for a pure rotation by angle x. High school geometry, really.

I'm told that a critical part of the ISO balloting process is that a comment identifies a problem, why it's a problem, and then (preferably) proposes a fix. I can see your fix, but your proposal does not include a clear statement of what the problem is.

Please reformat this proposal to be more consistent in your approach to amendments. I'm sure you don't want to compound the impression that there is one rule for you and a different rule for others.

I'm told that a critical part of the ISO balloting process is that a comment identifies a problem, why it's a problem, and then (preferably) proposes a fix. I can see your fix, but your proposal does not include a clear statement of what the problem is.

From purely procedural point of view, ISO balloting process and a proposal for new standard or amendment are two different things.

Proposals to create a new standard or change something in an existing standard (an amendment) are usually undergo a substantial group discussion before they are accepted as a work item. Comments are submitted in response to the ISO ballot (which is issued after the document, e.g. an amendment, is deemed mature for review), can be issued by any National Body, without consultation with anyone involved in the initial standardization process that produced an amendment, and by people who may or may not have been involved in the original standardization work. As a result, the mandated format for a ballot comment includes reference to the specific part the comment is addressing, the description of the problem it is trying to solve, and the proposed change. Group discussions where an amended content is being presented for collaborative review do not have to follow the same format.

Proposals to create a new standard

Would the next edition of the OFF standard ("OFF:2020"?) count as 'creating a new standard'?

A new edition of an existing standard.

@simoncozens :
First, there is a difference between proposed new content for a standard versus changes to existing content. The vast majority of the content in the proposal docs is addition of new content, not revision to existing content.

Secondly, in my earlier comments (in a different context), I was giving a comparison: it was proposed to wholesale replace existing content without any obvious indication of what problem with the existing content was being solved. Moreover, the replacement content provided entailed technical changes, and that certainly warrants an explanation of what technical problem existed or what is being improved.

Would the next edition of the OFF standard ("OFF:2020"?) count as 'creating a new standard'?

I am not sure I see a relevance between this question and the issue at hand (that is specific to COLRv1 work), but from prior discussions we had on the subject of future work we tentatively concluded that a significant editorial update is needed to update its structure and rid the spec from outdated materials and product-specific references, and that this updated spec would be a good starting point for the "OFF:next" work.

In general, a new edition is desired when the amount of edits [we want to introduce] is substantial, and when doing it via an amendment route would become a huge burden. This is not the case with replacing a subclause that specifies COLR table (the amendment document would simply state that we are replacing the content of the entire subclause with the new one provided, but to do so for the entire spec would be next to impossible - this would be a perfect case to consider a new edition.

{Edit} The new edition is also mandated after two amendments have been published, which means that once we finalize this COLRv1 amendment (that can include other changes in addition to COLRv1) we will have no choice but to start a new edition!

@PeterConstable where are the source files to these PDFs :)

colr_190_draft.pdf
colr_draft_200928_delta-from-183.pdf
cpal_190_draft_200928.pdf
cpal_draft_200928_delta-from-183.pdf
otvarcommonformats_190_draft_200928.pdf
otvarcommonformats_draft_200928_delta-from-183.pdf

where are the source files

Sources are in Microsoft's typography repo.

A small wording issue around line 217:

This graph is expected to be acyclic—that is, a tree.

An acyclic directed graph (DAG) may not be a tree. When we are talking about the Paints, it is possible that two offsets from different Paints points to the same paint.

Could you please clarify that whether sharing Paints via directing offsets to same target is allowed?

Good catch, DAG is correct.

Duh! Yes. I was trying to use wording that would be more familiar to more people, but in this case "tree" is incorrect.

And, yes, for paints that take an offset to a paint subtable, two such paints can reference the same target. After correcting the "tree" error, do you think this needs to be called out explicitly?

two such paints can reference the same target. After correcting the "tree" error, do you think this needs to be called out explicitly?

IMHO if it says DAG then it's clear this is allowed. @reli-msft would you concur?

@PeterConstable Correcting the "tree" word should be enough.

This work is now the main part of the ISO/IEC 14496-22:2019 AMD2 - closing.