RE: [OpenType] Re: [mpeg-OTspec] MS Proposal: new feature tag

[Simon Daniels MSFT]

Forwarding on behalf of Andrew Glass...

 

-----Original Message-----

From: Andrew Glass (WINDOWS)

Sent: 16 January 2013 18:11

To: Michelle Perham; Simon Daniels; Peter Constable

Subject: RE: [OpenType] Re: [mpeg-OTspec] MS Proposal: new feature tag

 

Here are my responses to comments from Niels and John.

 

Peter, if you think these are appropriate responses, could you please forward?

 

Thanks,

 

Andrew

 

>> Am I correct in assuming that the newly proposed 'stch' feature is 

>> applicable to a limited set of Unicode characters with specific 

>> properties?

 

> I think, if so, that would be an unnecessary limitation.

 

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.

 

[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.

 

>> i.e. the layout engine will only look for the 'stch' feature when it 

>> encounters these enclosing characters in text, and only apply lookup 

>> decompositions and reordering relate to these characters.

 

> How layout engines actually are to implement features is not part of the specification, I believe.

 

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.

 

[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. 

 

> 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.

 

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.

 

[Andrew Glass] Correct, the layout engine is responsible for duplicating the sections that stretch and for positioning all components of the stretch.

 

> It is unsafe to make assumptions here.

 

Indeed, which is why I am asking for clarification from the feature proposers.

 

[Andrew Glass] My apologies for the delay.

 

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?

 

[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.

 

> One field I can think of where this feature may be of use is in typesetting sheet music.

 

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.

 

[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.



Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20130117/17170c98/attachment.html>