<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style></head><body><div data-externalstyle="false" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:16px;"><div>
<p>Forwarding on behalf of Andrew Glass...</p><p data-focusfrompointer="true"> </p><p data-focusfrompointer="true">-----Original Message-----</p><p>From: Andrew Glass (WINDOWS)</p><p>Sent: 16 January 2013 18:11</p><p>To: Michelle Perham; Simon Daniels; Peter Constable</p><p>Subject: RE: [OpenType] Re: [mpeg-OTspec] MS Proposal:
new feature tag</p><p> </p><p>Here are my responses to comments from Niels and John.</p><p> </p><p>Peter, if you think these are appropriate responses,
could you please forward?</p><p> </p><p>Thanks,</p><p> </p><p>Andrew</p><p> </p><p>>> Am I correct in assuming that the newly proposed
'stch' feature is </p><p>>> applicable to a limited set of Unicode
characters with specific </p><p>>> properties?</p><p> </p><p>> I think, if so, that would be an unnecessary
limitation.</p><p> </p><p>It might be a necessary one. Consider: in order to know
what an enclosing form encloses there needs to be a reliable algorithm to
determine the beginning and end of the enclosure. Unicode provides this for
enclosing characters. In order for a modular glyph stretching mechanism to be
freely applicable based only on glyph processing rules, one would need to add a
standard mechanism to mark the beginning and end of enclosures in text. That's
not an impossible goal, but it might well require something new in Unicode,
given how overloaded existing Unicode control characters already are.</p><p> </p><p>[Andrew Glass] Yes, Niels is correct. It is a necessary
limitation. The stch feature needs to know the extent of a stretch and that is
determined by the text being enclosed. So one of the first tasks of the
rendering engine is to determine which text is being enclosed. The characters
that are known to enclose spans of text have different rules for determining
the extent text they enclose. If new control characters were introduced to mark
a span to text to be enclosed, and the enclosing character, such a feature
could be generalized. Until then, the expectation is that this will apply to
specific characters only.</p><p> </p><p>>> i.e. the layout engine will only look for the
'stch' feature when it </p><p>>> encounters these enclosing characters in text,
and only apply lookup </p><p>>> decompositions and reordering relate to these
characters.</p><p> </p><p>> How layout engines actually are to implement
features is not part of the specification, I believe.</p><p> </p><p>Well, that's a grey area. The Microsoft script-specific
specifications are pretty strict in terms of what they expect of fonts and
layout engines. What may be classed as script and language shaping standard
layout tends to be fairly tightly defined, and as currently spec'd the 'stch'
feature looks like it is intended to fall into this category. At least, that is
what I am seeking to clarify with my question.</p><p> </p><p>[Andrew Glass] This feature is primarily intended as a
means to render the Syriac Abbreviation Mark (U+070F) for text in any language
using the Syriac script. Provided there is agreement on how to determine the
extent of a stretch for other characters, it could be used more generally. </p><p> </p><p>> That means one implementation could rely on input
unicode codepoints as you assume, yet another engine could simply implement the
given lookups and don’t care about unicode.</p><p> </p><p>Implement them how? I don't think OpenType Layout, even
involving contextual lookups, is adequate to determining where an enclosure
begins and ends, which is the information that a layout engine needs to
determine in order to apply the 'stch' feature as spec'd. Note also that the
feature presumes the layout engine will be responsible for duplicating
decomposed sections as necessary to complete the form over extended runs.</p><p> </p><p>[Andrew Glass] Correct, the layout engine is responsible
for duplicating the sections that stretch and for positioning all components of
the stretch.</p><p> </p><p>> It is unsafe to make assumptions here.</p><p> </p><p>Indeed, which is why I am asking for clarification from
the feature proposers.</p><p> </p><p>[Andrew Glass] My apologies for the delay.</p><p> </p><p>I gave some thought today to mechanisms that might make
this feature more flexible, because I can imagine some funky display font uses
for e.g. enclosing ornaments or swashes. But there needs to be something in the
text string that provides this information: what enclosing form is to be used,
where does it begin, and where does it end?</p><p> </p><p>[Andrew Glass] For Syriac Abbreviation Mark, the beginning
and end points of the stretch are defined in the Unicode Standard's chapter on
Syriac. For generalized behaviour to be possible, there would need to be
agreement on where the beginning and end points are. If the kind of horizontal
stretching that this feature is intended to provide is considered useful and
interesting to font developers, then it would be good to have a discussion on
how to determine those end points.</p><p> </p><p>> One field I can think of where this feature may be
of use is in typesetting sheet music.</p><p> </p><p>I don't think so. The 'stch' mechanism pretty strongly
assumes lateral layout and mostly straight connections (at least for all medial
sections), whereas music ties need to cover varying vertical as well as
horizontal distance and involve curved strokes. These are best dynamically
drawn by software than handled via font lookups.</p><p> </p><p>[Andrew Glass] It might be possible to stretch the lines
of the staves this way, but it is likely that a dedicated layout engine for
music would be more suitable.</p>
</div><div data-signatureblock="true"><div> </div><div>Sent from Windows Mail</div><div> </div></div></div></body></html>