<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Angsana New";
panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
{font-family:"Cordia New";
panose-1:2 11 3 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1358774500;
mso-list-type:hybrid;
mso-list-template-ids:1006949338 67698711 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1794009583;
mso-list-type:hybrid;
mso-list-template-ids:321317990 28312184 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:425;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal"><span lang="EN-CA">I’ve seen many different comments that might pertain to scope, though it hasn’t been entirely clear (particularly in the thread about vertical layout) which things are suggested as specification gaps versus implementation
bugs. I’d like to make some high-level comments/suggestions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">There is a broad scope of interest that encompasses everything having to do with layout of text. And there are valid scenario requirements that include (among other things) that it should be possible to one person to
author content using certain fonts and for another to view the content using different fonts but with certain fidelity in presentation to what the author intended—a certain type of _<i>interoperability</i>_. But the scenarios are varied and require different
levels of fidelity to what the original author saw—different kinds of interoperability. And there are multiple layers of content specification and implementation involved that will have bearing on what specifications are needed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">Questions have arisen as to what should be considered “shaping”, “text layout” etc. Dave Crossland suggested that one relevant distinction here is plain text versus rich text. That is certainly a relevant distinction,
but not the only relevant distinction. I think there is another key distinction: presentation of single lines of text versus presentation of blocks (or pages) of text.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">There is a certain correlation between these two X vs Y distinctions: if you are dealing with multiple lines of text, then implicitly you are dealing with something more than plain text — i.e., text that is “rich” to
some degree. If nothing else, there are block metrics that have been specified, and that is more than plain text.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">I think a useful definition of “shaping” involves something that can be fully specified to happen on single lines of text. That’s not to imply that no higher-level “rich” information isn’t relevant. For instance, if a
line of text is to be contained in a block and page layout that has vertical orientation, then that information is a relevant input parameter for how that line needs to be shaped. And the metrics for a block may determine that lines will break at certain points;
but once line breaks are chosen, the layout/shaping of a line can be done without additional consideration of what is happening at the block or higher levels.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">Of course, there are ways in which block-level layout needs to interact with the line layout. For instance, line breaks don’t get determined until after line-break opportunities are identified and the most appropriate
LBO is selected. And that may require iterative operations laying out lines with different LBOs assumed to determine line metrics in each case (since the laid-out glyph metrics can be affected by where LBs do occur). But that is an iterative process in which
single lines of text are shaped/laid out with certain input parameters coming from the higher level processing assumed: where lines get broken, whether the layout is horizontal or vertical, etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">So, I have always understood “shaping” to be a process that happens and can be fully specified for layout of single lines of text.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">There are some distinct factors that are relevant for “shaping”:<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2"><span lang="EN-CA">Unicode Bidi Algorithm<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2"><span lang="EN-CA">Typographic behaviours required for culturally appropriate presentation of Unicode strings<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2"><span lang="EN-CA">Certain styling that occurs on spans of text, independent of blocks—in particular, discretionary typographic features<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2"><span lang="EN-CA">Certain inputs from higher-level layout, as mentioned above—e.g., horizontal vs. vertical block layout<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">Depending on how one might define things, UBA may or may not be encompassed within “shaping”. For instance, one could think of “shaping” as processing that happens on runs of text of a single bidi level. Or you might
define “shaping” as happening on lines of text after bidi levels have been resolved. One way or another, I’m inclined to incorporate UBA in some way since the way in which bidi levels get resolved will determine what glyphs are adjacent to what other glyphs
and that can have bearing on certain interactions that I think should be in scope for “shaping” — e.g., I’m inclined to consider kerning to be part of the shaping process, and also think it should be (ideally) possible to kern glyphs across a bidi level boundary.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">OK, with those things in mind, let me bubble up to the subject line for this thread: “Defining the text shaping working group’s scope”:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">While the OT spec has been around for 20+ years and has provided a _<i>basis</i>_ for shaping specification that can allow for interoperability of text, content and fonts, shaping itself has not been specified, and the
degree of interoperability that we have today, to a significant degree, has been the product of newer implementations trying to reproduce the behaviours observed in earlier implementations. In particular, Microsoft’s “Uniscribe” implementation has been taken
as a de facto reference to be copied. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">But that is not really a robust way to ensure broad interoperability, even when limiting to single lines of plain text (and the more limited expectations that can be placed on fidelity to author expectation for plain
text). And if it’s not a sufficient basis to ensure interop with single lines of plain text, then it certainly isn’t an adequate basis for higher-level layout of rich text.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">So, there certainly may be gaps for specifications pertaining to layout of blocks of rich text that should at some point be addressed. But I’m inclined to think that “shaping” specifications are a more fundamental gap,
and that the scope for that can be limited to processing that happens on single lines of (plain or rich) text. If progress can be made within that scope, without taking on boiling the ocean of _<i>all</i>_ text layout, then I think that would be a very significant
and worthwhile advance.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA">Peter<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>