Spawn a group to work on 32 bit gids

[rsheeter]

I am interested in forming a group to draft an OFF update proposal to break the 65k glyph limit. The reasons this is desirable to my organization are outlined in https://rsheeter.github.io/more_gids. I have not attempted to comment on the value or lack thereof for others. I imagine the group might assemble a more general statement of why (and perhaps why not).

I have deliberately not commented on backward compatibility as I see determining if and how that should work to be part of the groups technical work.

I hope the group will choose to leverage open source to provide a public reference implementation along the way.

My immediate thought was that we might seek to spin up a W3C WG to this end.

There is a similar issue @ MPEGGroup/OpenFontFormat#10 but IIUC the CG is specifically meant to form groups to perform technical work so it strikes me as appropriate to file here. Please advise if not :)

Edit: A W3C CG could also work.

[lianghai]

Good. The following proposal from the original agenda doc is now merged into this issue:

• @murata2makoto: Lift the 16 bit limitation for GIDs

Lifting the 65K or 16 bit limit may be indeed a more appropriate wording for this issue.

Also, cc @reli-msft (Renzhi Li), who I know is (or once was) interested in this idea.

There is a similar issue @ MPEGGroup/OpenFontFormat#10 but IIUC the CG is specifically meant to form groups to perform technical work so it strikes me as appropriate to file here. Please advise if not :)

It’s helpful to expose such critical discussions to a wider audience (which is what we strive for), so it’s good to at least track the OFF-specific discussion here.

We as a group, on the other hand, need to gradually figure out how to be helpful in such matters without unnecessarily diluting people’s attention. I’m thinking we should first keep an eye on the OFF discussion for now, and try to get all interested parties’ attention. Then if the OFF group doesn’t continue to be active on this, we need to help the industry organize an effort.

[vlevantovsky]

A word of caution - creating a new WG within the W3C organization is a fairly involved process, one that usually assumes Recommendation-track deliverables. The WG charter needs to be developed to clearly state the list of deliverables, proposed and well defined development timeline, and approved by the W3C Advisory Committee. Without a Recommendation-track deliverables, getting the WG charter approved by the AC may be not be easy.

If the end goal of this work is develop input proposals for OFF to adopt changes that would lift 64K glyph limit, then forming a WG to do that may be an overkill, and a significant drain of resources of this group to get the WG running. It is feasible to simply spawn a new dedicated CG to develop a set of proposals for new OFF version, similar to how "SVG in OpenType" CG has developed a proposal that ended up being the basis for SVG glyphs in OT/OFF.

IMO, before we get into the technical details of what changes need to be implemented to develop a new spec we need to address high-level concerns that are being discussed as part of the related issue #10 in OFF repo.

[rsheeter]

I'm not overly attached to WG vs CG, I should have been more explicit about that in OP.

[rsheeter]

IMHO we should form a group - probably a CG based on @vlevantovsky comments - that proceeds in phases:

1. Write a high level plan
   • Why the change is desirable, where possible in light of specific consumers of specific implementations
   • Degree of backward compatibility
   • General pattern of implementation
2. Circulate plan to see if anyone becomes enthused or has strong objections
   • If there are fatal objections we are now done :)
3. Draft an actual set of spec changes, update open source tools to provide a reference implementation, etc
   • Work in public and ping key parties along the way to try to ensure no last minute vetoes :)
4. Submit to SC29 or AHG for OFF inclusion

Edit: Amended submission to add "or AHG" based on @davelab6 comments.

[davelab6]

1. Write a high level plan

I'm grateful that Peter has started to sketch this out in MPEGGroup/OpenFontFormat#10

But yet again it shows why not being able to PR files into that repo makes it insufficient for efficient collaboration; each issue discussion there is fettered, and gives the OP and @vlevantovsky access to edit the sketched document as an exorbitant privilege, and there's no license for anyone else to attempt to contribute.

Here on this repo, such a plan seems to me to be better characterized as writing a charter for a new CG.

@lianghai as chair, does collaborating on such plan/charter on this repo meet and not exceed the current (draft) charter?

2. Circulate plan to see if anyone becomes enthused or has strong objections

• If there are fatal objections we are now done :)

I'm optimistic that any process will naturally surface such objections ;)

4. Submit to SC29 for OFF inclusion

It seems to me the submission to the AHG should speed up the process compared to going directly.

[vlevantovsky]

It seems to me the submission to the AHG should speed up the process compared to going directly.

When it comes to the proposals developed by different organizations, making an official submission directly to the WG or to the SC29 is perfectly fine and even encouraged. The WG rarely makes immediate decision on complex proposals, and in most cases will defer the discussion to the AHG with the specific mandate. This has been the case e.g. with the recently submitted CSS WG liaison - it was sent to the SC29, submitted for discussion in the WG meeting, and a specific mandate was issued for the AHG to study it and propose solutions.

[lianghai]

Here on this repo, such a plan seems to me to be better characterized as writing a charter for a new CG.

@lianghai as chair, does collaborating on such plan/charter on this repo meet and not exceed the current (draft) charter?

I think such projects are exactly what the third bullet under https://github.com/simoncozens/font-text.github.io/blob/draft-charter/charter/index.md#deliverables talks about. Basically, the phases 1 and 2 in @rsheeter’s comment #8 (comment) naturally form a back-and-forth feedback loop that we should be able to safely conduct with this CG’s infrastructure and attracted attention.

I’m a bit worried though, that for such a very specific technical issue (the GID limit), will we be able to draft a useful charter without stepping across the boundary of “technical contributions”? But I guess we’ll be happy to try and see.

[danrhatigan]

In batting about thoughts of raising the 16-bit just within our team at Adobe, there's already a lot to chew on with use cases, cost-benefit concerns, and other considerations we wouldn't want to make in isolation, and that still fall short of actual technical contributions. We'd like to align with as many perspectives as possible, so I'm in favor or starting with a new CG and proceeding from there as needed.

[NorbertLindenberg]

Going to 32-bit glyph IDs is going to touch many parts of OpenType. There are a number of other proposals that are likely to touch some of the same parts of OpenType (the GSUB table comes to mind). If we spin up separate groups for each of those proposals, where does the coordination happen to make sure that the results produced by the separate groups play nicely together? Where are the results going to be integrated into a coherent OpenType spec?

When the idea of this Font and Text CG came up, I was hoping this group would be the forum for improving OpenType as a whole, but if we can’t have technical discussions here, then it can’t provide coordination and integration on technical matters. And the Font and Text CG was created because we didn’t see the OFF AHG, let alone SC 29, as the right fora for this...

[simoncozens]

Groups spun off by this CG are encouraged to have liaison arrangements with other groups, including others also spun off by the CG. If I understand correctly, this is one main difference between W3C groups and ISO groups, where ISO groups are not officially meant to take notice of discussions happening in other fora. Practically speaking, if there are multiple subgroups spawned to make proposals in separate areas of the OFF, I think that realistically the membership of these groups will have a high degree of overlap, and so we will naturally be aware of what else is going on. There are not a huge number of people involved in these discussions, and those that are tend to be involved in all of them, so I'm going to assume it will work until proved wrong, rather than the opposite.

And the Font and Text CG was created because we didn’t see the OFF AHG, let alone SC 29, as the right fora for this.

I'm sorry to keep banging on about this, but this is not the case. The Font and Text CG is emphatically not a AHG splinter group. It exists to primarily to create fora for issues which don't sit neatly inside AHG or Unicode.

[lianghai]

If we spin up separate groups for each of those proposals, where does the coordination happen to make sure that the results produced by the separate groups play nicely together?

In order to limit communication overheads, technical groups need to be based on areas of concerns, instead of individual proposals. After all, the point of creating separate technical groups is to maintain a manageable scope of technical contributions so those legal departments are happy. Dividing the scopes into too small fractions don’t help the legal departments. Therefore I assume, for such a proposal, a technical CG more or less on the OpenType format proper should be created, and the exact scope needs to be adjusted dynamically according to the participants’ need.

Where are the results going to be integrated into a coherent OpenType spec?

Until now, and into the near future, it seems like @PeterConstable and @vlevantovsky’s “pens” are still the ultimate places where the integration will happen. Any innovative ways of integrating the changes will need to be able to successfully take over the duty from them.

[vlevantovsky]

Until now, and into the near future, it seems like @PeterConstable and @vlevantovsky’s “pens” are still the ultimate places where the integration will happen. Any innovative ways of integrating the changes will need to be able to successfully take over the duty from them.

In the OFF case, the "pen" belongs to ISO, I am only appointed to hold it. At some point in the future, someone else can be appointed to do this job, but the "pen" will still belong to ISO - taking over this duty won't really change anything.

And, there are many more things to consider in addition to desire to find an innovative way of making changes. The standards are meant to be effective, and to effect change it needs to be developed with the specific goals of the industry it's supposed to serve. Some industries need "evergreen" standards processes, like what is now being implemented in W3C, other industries need stability to give them time to develop and deploy products.

[lianghai]

Vlad, it’ll be helpful to always distinguish the rubber-stamping procedures happening at the SC29 (and whatever management done at the WG3) from the actual, technical and editorial, editing work.

[davelab6]

I intend to create a CG for this. I propose to post the draft charter to this repo as a PR, to invite comment. What should the file name be?

[simoncozens]

I suggest it should be charters/32-bit-gid.md (unless you are widening the scope!). Please (first) submit a separate PR to the (currently non-existant) work-items/index.md.

[tiroj]

Do you want to make the CG specifically about 32 bit GIDs, or should it be more generalised to removing the 16 bit limitation? I mean, going to 32 bit GIDs seems the likely solution, but should the CG do a review of the problem space before settling on a solution? Also, the 16 bit limitation runs through many SFNT tables, so it isn't just about GIDs.

[rsheeter]

should it be more generalised to removing the 16 bit limitation?

Agreed, 32 bit gids is a means not an end.

@davelab6 I suggest you use your favorite filename (lest we build you a bike shed) and make a PR.

[lianghai]

@simoncozens: We don’t have to differentiate charters from other general work items in a work-items directory (or, did you actually plan to host work item files in the work-items directory?). If we do want to make the distinction, naming the directory something like tech-group-charters can be clearer.

[simoncozens]

You’re right, the charters are the work items for this CG. So let’s have draft charters in the work-items directory and do Jekyll magic to get an autoindex.