Stalled proposals

[lianghai]

This is to keep track of and migrate the proposals recorded in the original agenda document so we can deprecate that doc soon.

I’d like to see volunteers take up each proposal and open a dedicated issue to further introduce the ideas and attract some discussions. If a proposal is confirmed by the proposers to be no longer relevant, we just archive them here.

Still stalled

1. Closer coordination with the Unicode Standard, especially on complex scripts’ shaping requirements

Proposed or seconded by: Liang Hai @lianghai, Norbert Lindenberg @NorbertLindenberg, Ben Yang @iwsfutcmd, Peter Constable @PeterConstable

• Ideally the Unicode Standard should only specify how to do “text representation” (ie, how to digitize/encode analog texts into Unicode strings, in other words, how to represent texts in Unicode characters).
• Unfortunately in reality many aspects of Unicode text representation are tangled with text shaping (how to reproduce analog texts from Unicode strings), and the two sides’ relation has been seriously underspecified for complex scripts.
• This relation must be discussed, clarified, and standardized to some extent, and eventually it needs to either live in the Unicode Standard or a separate standard.

3. A significantly updated (or brand new if necessary) font format

See also §11 (An Open Proposal: Fixing the Font Format), which may be considered to be a revised proposal.

Proposed or seconded by: Behdad Esfahbod @simoncozens behdad, Liang Hai

• OpenType BE (Behdad’s “OpenType 2.0” wishlist/agenda!) (last updated in 2015)

Suggestion from Bram Stein @bramstein:

I like this idea. Please consider pulling in some people from the W3C Fonts WG working on progressive font enrichment. Any significant changes (or a new format) could simplify "font streaming".

4. Standardized script run segmentation (itemization) algorithm

Proposed or seconded by: Liang Hai, Norbert Lindenberg, Ben Yang

• Like the Unicode Standard, OTL has a fundamental assumption of “scripts”, and all OTL operations are limited inside a script run.
• It’s however never been clear how the script run boundaries should be determined around Unicode characters that have a weak Script value (Common or Inherited).

5. Registered glyph naming schemes and conversion

Proposed by: Liang Hai

• Glyph names are lightweight identifiers for font development time. Being able to systematically generate them—especially for complex scripts—and convert between different schemes is gonna hugely benefit the industry’s workflows.
• This is however a rather application-oriented proposal and shouldn’t affect other ideas much.

7. Relax the dependency of shaper’s knowledge of complex scripts

Proposed by: Liang Hai

• OTL’s predefined script-specific shaping behavior was intended to simplify font development for complex scripts, but nowadays causes more difficulties than it eliminates.
• Newly encoded Unicode characters are locked out of script-specific complex shaping until a shaping engine is updated.

8. Review and patch vertical layout

Proposed or seconded by: Liang Hai, Norbert Lindenberg, Makoto Murata @murata2makoto, Ben Yang

• Clarify baseline alignment between rotated and upright glyphs.
• Clarify glyph rotation criteria.

10. Architecture for visual fidelity of documents

Proposed by: Makoto Murata

• Define interactions of document rendering and text shaping
• Make clear how fonts are used by them
• Establish a framework for visual fidelity in an open environment

11. An Open Proposal: Fixing the Font Format

See also §3 (A significantly updated (or brand new if necessary) font format), which may be superseded by this one.

Proposed by: Behdad Esfahbod

• Document

13. Metrics beyond Western/CJK

Proposed by: Elika Etemad @fantasai

• https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
• https://lists.aau.at/pipermail/mpeg-otspec/2020-August/002156.html

Taken over by dedicated issues

2. Standardized shaper behavior specification

Dedicated issue: #11

Proposed or seconded by: Simon Cozens @simoncozens, Adam Twardoch @twardoch, Liang Hai, Norbert Lindenberg, Ben Yang, Peter Constable

• Right now the OpenType Standard describes the font format for OpenType Layout but very little of how layout should be processed by the shaper. This behavior should be standardized and documented.

6. Shaping Ideographic Description Sequences

Dedicated issue: #33

Proposed by: Fred Brennan @ctrlcctrlv

• Document (version 1)

9. Lift the 16 bit limitation for GIDs

Merged into a dedicated issue: #8

Proposed by: Makoto Murata

12. Fixing responsive text tooling

Dedicated issue: #12

Proposed by: Scott Kellum @scottkellum

• Control over variable font parameters as text resizes. Clamp and locks do not support this.
• Control easing of text scaling, this is particularly useful on smaller screens like watches and small phones. Another limitation in Clamp and locks.
• Allow text to respond to its container (intrinsic typography as opposed to responsive typography). This may need to be developed alongside element query initiatives. The authoring needs of typesetting for every area of a layout right now are enormous and this will reduce typographic styles significantly.

Disclosure: Typetura (Scott Kellum) has one patent and one patent pending regarding applications on top of this approach. There is prior art for the approach itself in the form of FlowType.js and Textblock.io along with the Typetura JS engine.

[simoncozens]

I'm planning to develop item 2 (shaper docs). Will open an issue with description tomorrow.

[davelab6]

@simoncozens posted https://github.com/simoncozens/sff-spec - is this part of (3)?

[simoncozens]

I’m not intending that to be part of discussions until I have a proof of concept. For all I know it might be rubbish - anyone can write stuff in a spec, but implementation matters.

[mpsuzuki]

@lianghai , I'm interested in your proposal (5). Also I think this could be related with the idea to introduce new LABL table ( OpenType/opentype-layout#18 ). Could we discuss your idea on a separated issue? I want to know whether you got some difficulty.

[lianghai]

@mpsuzuki, I just had a quick look at the PR and yes, these two ideas are more or less related, although coming from very direct directions. I’ll try to write up some introduction of my intentions (mostly for font development) in a separate issue, and spend more time fully reviewing both the PR and twardoch/opentype-layout#1.

[mpsuzuki]

@lianghai, thanks! If I understand the proposals correctly, the big motivation for LABL table is the localized and flexible searching of the glyph from the collection of the keywords. I think your proposal is mainly for machine readability, not for the human readability. But I guess, the idea to have a registered vocabulary for the glyph name, and the clarified syntax how to concatenate them could be a substitution for LABL table for English users. It could be useful to consider the idea of LABL table. I would participate the discussion. Thanks in advance!