<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I agree that a cleaned up, regularized, audited rewrite of the
current functionality, which uses terms in a consistent way, would
be very desirable.</p>
<p>It is also an awful lot of probably thankless work.</p>
<p>I have seen this happen at least twice. Once was the rewrite of
PNG 1.1 lus updates to become the ISO specification for PNG 1.2. I
think that took about three years, the last of which was checking
that the two specifications actually said the same thing. The
other was the subsetting of SS 2 int the interoperably,
implemented subset CSS 21 (plus adding some clarifying details.
Just a few. Ahem) which took over ten years.</p>
<p>Gating any updates behind successful completion of a rewrite is
asking for a lot of patience. It may still be the right thing to
do. It would certainly make discussing the impact and correctness
of any new update much easier. But are people prepared to either
wait that long, or to help with a sustained community effort to do
unglamorous spec work to get it done in a shorter time?</p>
<p>(I also agree that tracking issues in GitHub is vastly preferable
to tracking them across email archives)<br>
</p>
<div class="moz-cite-prefix">On 2020-09-18 15:40, Adam Twardoch
(Lists) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAG32G7OzM6nFG-d383ThwnS+fFuEiW49yqNVdVCqD1sPvzmbSg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
the spec is just an incredibly convoluted mess. It fails on basic
things like a clean structure, some conceptual modularization,
terminology etc. etc. In one place "CFF" means "CFF1" but in other
places it means "CFF1 or CFF2". That's just a basic example.
<div dir="auto"><br>
</div>
<div dir="auto">So the spec needs a major reworking **before**
this gets into the phase of proposals. Simple amendments won't
do, because what we got from simple amendments is more chaos.</div>
<div dir="auto"><br>
</div>
<div dir="auto">It's not at all clear which parts of the format
are pertaining to line layout and shaping, which are about glyph
rendering, which are about font selection, and which intersect. </div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">OFF
sometimes gives high exposure to things that are irrelevant
today (e.g. legacy Mac language IDs), sometimes does not give
exposure to things that are of high relevance (the actual
inter-relations of various entries). </div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">The existing text of the OFF would be helpful as a
**reference**, and it would be helpful as a resource from which
people can copy-paste and rework, or even gradually mark which
things are refactored and which are not. </div>
<div dir="auto"><br>
</div>
<div dir="auto">I think if we ever think about moving towards OFF
2.0, we should first create a new clean structure of the current
OFF.So it's an editorial rewrite (refactoring) without any
substantial functional changes. Adding clarifications and
inter-relations, splitting factual data from "frivolous
commentary" (like those ad-hoc comments about some "WWS" is the
name table, which are inserted into what is a list of fields. <br>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAG32G7OzM6nFG-d383ThwnS+fFuEiW49yqNVdVCqD1sPvzmbSg@mail.gmail.com"></blockquote>
<pre class="moz-signature" cols="72">--
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media</pre>
</body>
</html>