<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 29072020 8:56 pm, suzuki toshiya
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c4fafab9-0639-bcca-4fab-bbb9881c0874@hiroshima-u.ac.jp">
<blockquote type="cite" style="color: #000000;">1. Technology
Documentation
<br>
Describes the underlying technologies script implementations
rely on. For example, OpenType, shaping engines.
<br>
</blockquote>
Indeed! Detailed information about the existing implementations of
OpenType is really really important for the font-related software
engineers. I remember, in the past, there was a rumor of a
discussion whether the documents of the script-dependent shaping
mechanism of OpenType (currently provided by Microsoft) should be
a part of ISO specs (or ISO TR), or not, but I cannot remember the
conclusion. If the Text Shaping WG is created under the current
JTC1/SC29/WG11 font AHG, the WG will make such ISO document? If it
is created under Unicode, the WG will make such document as a part
of Unicode standard (or UTR)? Either way, I'm sure that it would
be an admirable decision.
</blockquote>
<p>Documenting script shaping engine behaviour is important, but I
think we need to start at a lower level, and provide the missing
OTL implementation specification and a reference implementation.
Where different shaping environments (i.e. a shaping engine in
combination with the software within which it is operating)
produce different results, this tends to be because of differing
interpretation of the OTL table data and understanding of what to
do with that data.</p>
<p>Script shaping produces the real world test cases for OTL
implementation, so helps us determine what needs to be tested and
what kinds of behaviour need to be specified—beginning with how to
do script itemisation and run segmentation correctly, and
proceeding to things like tracking ordering of glyphs in which the
glyph count is being altered multiple times by GSUB—but we need to
be able to generalise the rules to apply at an abstract glyph
processing level independent of specific scripts and languages.</p>
<p>The early years of OTL script specification and development were
characterised by a focus on script-specific shaping, instead of
generalisation. This is how we ended up with multiple registered
OTL features that perform the same function, e.g. ccmp and akhn:
the feature sets were specified as something particular to a class
of scripts, instead of generalised at the level of glyph
processing behaviour.<br>
</p>
<p>JH<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
John Hudson
Tiro Typeworks Ltd <a class="moz-txt-link-abbreviated" href="http://www.tiro.com">www.tiro.com</a>
Salish Sea, BC <a class="moz-txt-link-abbreviated" href="mailto:tiro@tiro.com">tiro@tiro.com</a>
NOTE: In the interests of productivity, I am currently
dealing with email on only two days per week, usually
Monday and Thursday unless this schedule is disrupted
by travel. If you need to contact me urgently, please
use some other method of communication. Thank you.</pre>
</body>
</html>