search

MPEGGroup / OpenFontFormat

Official MPEG repository to discuss issues on Open Font Format (ISO/IEC 14496-22)
31 stars 6 forks source link

Proposal: extension to COLR table (COLR v1) #20

Closed PeterConstable closed 3 years ago

PeterConstable commented 3 years ago

Google has prepared a proposal to extend the COLR table with significantly enhanced capabilities. This followed from initial discussion at a meeting in 2019 that included people from various companies, with a general consensus to proceed. I was commissioned by Google to adapt that into proposed revisions to the OpenType spec and to OFF.

Attached are preliminary drafts related to this:

Two variants for each are attached: one showing changes from OpenType 1.8.3, which would be approximately the same as changes from OFF:2019 + Amd1; and one showing the net result, with line numbering for easy reference.

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

Note: There is not a new edition in ISO's balloting process yet. That means that the technical content is not yet final, wrt ISO process. Assuming work on a new edition were approved at the next WG3 and SC29 meetings, technical balloting on the new edition would go well into 2021.

The draft for the proposed COLR table revisions is not yet complete, but there's enough in place that should allow a technical reader to get a pretty good understanding of proposed new structures and how they work. Also, the specifics on how the color gradation is calculated for a radial gradient have yet to be added, but the description of the structure used for it should, I think, give a clear idea of what the capabilities are. Some visual examples are forthcoming that will provide greater clarity.

The Google proposal was prepared by Behdad Esfahbod, Dominik Röttsches, and Rod Sheeter, with input and review feedback from several others including: Dave Crossland, Laurence Penney, Adam Twardoch, Cosimo Lupo, Rossen, Atanassov, Roel Nieskens, "Pomax", "bungeman", and myself. (Apologies if I missed anyone.)

Update, October 2, 2020

The COLR section has been updated:

The idea of using a solid/gradient shading to fill a glyph outline would be a familiar extension from version 0, but it under-represents the version 1 capabilities and can lead to confusion. A better way to think is that a glyph outline can be filled by a potentially complex composition. In terms of how it will be implemented in 2D graphics libraries, a more accurate description would be that the glyph outline defines a clip region that applies to nested operations defined in the sub-graph. The above changes are an initial attempt to clarify that.

Update, October 1, 2020

The COLR section has been updated to reflect revisions in Google's proposal as well as certain corrections. Here are the key changes from the previous draft:

Also, the Font File section has been added to the collection of docs. There is only a small change: addition of the Offset24 data type.

**Second update, October 1: made corrections from review feedback (e.g., corrected occurrences of "tree" to "graph").

colr_draft_201002_delta-from-183.pdf colr_190_draft_201002.pdf

otff_190_draft_201001.pdf otff_draft_201001_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

behdad commented 3 years ago

+1

Than you Peter.

On Mon, Sep 28, 2020, 11:54 AM Peter Constable notifications@github.com wrote:

Google has prepared a proposal https://github.com/googlefonts/colr-gradients-spec/tree/rs to extend the COLR table with significantly enhanced capabilities. This followed from initial discussion at a meeting in 2019 that included people from various companies, with a general consensus to proceed. I was commissioned by Google to adapt that into proposed revisions to the OpenType spec and to OFF.

Attached are preliminary drafts related to this:

  • revisions to the COLR section—the bulk of the changes
  • revisions to the Variations Common Table Formats section
  • revisions to the CPAL section

Two variants for each are attached: one showing changes from OpenType 1.8.3, which would be approximately the same as changes from OFF:2019 + Amd1; and one showing the net result, with line numbering for easy reference.

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

Note: There is not a new edition in ISO's balloting process yet. That means that the technical content is not yet final, wrt ISO process. Assuming work on a new edition were approved at the next WG3 and SC29 meetings, technical balloting on the new edition would go well into 2021.

The draft for the proposed COLR table revisions is not yet complete, but there's enough in place that should allow a technical reader to get a pretty good understanding of proposed new structures and how they work. Also, the specifics on how the color gradation is calculated for a radial gradient have yet to be added, but the description of the structure used for it should, I think, give a clear idea of what the capabilities are. Some visual examples are forthcoming that will provide greater clarity.

The Google proposal was prepared by Behdad Esfahbod, Dominik Röttsches, and Rod Sheeter, with input and review feedback from several others including: Dave Crossland, Laurence Penney, Adam Twardoch, Cosimo Lupo, Rossen, Atanassov, Roel Nieskens, "Pomax", "bungeman", and myself. (Apologies if I missed anyone.)

colr_190_draft.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294023/colr_190_draft.pdf colr_draft_200928_delta-from-183.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294024/colr_draft_200928_delta-from-183.pdf cpal_190_draft_200928.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294025/cpal_190_draft_200928.pdf cpal_draft_200928_delta-from-183.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294027/cpal_draft_200928_delta-from-183.pdf otvarcommonformats_190_draft_200928.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294028/otvarcommonformats_190_draft_200928.pdf otvarcommonformats_draft_200928_delta-from-183.pdf https://github.com/MPEGGroup/OpenFontFormat/files/5294029/otvarcommonformats_draft_200928_delta-from-183.pdf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MPEGGroup/OpenFontFormat/issues/20, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABC4K4CK47PRWOMDTTYRLTSIDEW3ANCNFSM4R4ZUEEQ .

vlevantovsky commented 3 years ago

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.

PeterConstable commented 3 years ago

A new amendment would also work.

reli-msft commented 3 years ago

Two short questions:

PeterConstable commented 3 years ago

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?

behdad commented 3 years ago

On Mon, Sep 28, 2020 at 4:00 PM Renzhi Li notifications@github.com wrote:

Two short questions:

  • LayerV1List: should we use Offset32 data type for paintOffset[numLayers] fields?

Indeed. Already since this morning I suggested and Rod changed ALL Offset16's to Offset32.

  • 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?

Dropped. See section on boundedness.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MPEGGroup/OpenFontFormat/issues/20#issuecomment-700307172, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABC4K6TTOYRIK3QL74SJWTSIEBPLANCNFSM4R4ZUEEQ .

davelab6 commented 3 years ago

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.

reli-msft commented 3 years ago

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: https://github.com/googlefonts/colr-gradients-spec/issues/51

Lorp commented 3 years ago

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.

HinTak commented 3 years ago

@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.

simoncozens commented 3 years ago

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.

vlevantovsky commented 3 years ago

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.

davelab6 commented 3 years ago

Proposals to create a new standard

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

PeterConstable commented 3 years ago

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.

vlevantovsky commented 3 years ago

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!

davelab6 commented 3 years ago

@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

PeterConstable commented 3 years ago

where are the source files

Sources are in Microsoft's typography repo.

reli-msft commented 3 years ago

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?

rsheeter commented 3 years ago

Good catch, DAG is correct.

PeterConstable commented 3 years ago

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?

rsheeter commented 3 years ago

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?

reli-msft commented 3 years ago

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

vlevantovsky commented 3 years ago

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