New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: extension to COLR table (COLR v1) #20
Comments
+1
Than you Peter.
…On Mon, Sep 28, 2020, 11:54 AM Peter Constable ***@***.***> 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
<#20>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABC4K4CK47PRWOMDTTYRLTSIDEW3ANCNFSM4R4ZUEEQ>
.
|
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. |
A new amendment would also work. |
Two short questions:
|
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? |
On Mon, Sep 28, 2020 at 4:00 PM Renzhi Li ***@***.***> 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
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABC4K6TTOYRIK3QL74SJWTSIEBPLANCNFSM4R4ZUEEQ>
.
|
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 Cross posted: googlefonts/colr-gradients-spec#51 |
The table at line 170 defines an Affine2x3 matrix with two translation elements, |
@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. |
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. |
Would the next edition of the OFF standard ("OFF:2020"?) count as 'creating a new standard'? |
A new edition of an existing standard. @simoncozens : 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. |
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 :)
|
Sources are in Microsoft's typography repo. |
A small wording issue around line 217:
An acyclic directed graph (DAG) may not be a tree. When we are talking about the Could you please clarify that whether sharing |
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? |
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. |
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
The text was updated successfully, but these errors were encountered: