|
|
Created:
7 years, 9 months ago by trueroad Modified:
7 years, 9 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionIssue 5164: Doc: Add usage of OpenType font feature
This commit adds the usage of OpenType font feature
added in Issue 1388 to the document.
Patch Set 1 #
Total comments: 5
Patch Set 2 : Add full feature list and indexed feature #Patch Set 3 : Add notes and identification way #
MessagesTotal messages: 21
https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... File Documentation/notation/text.itely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... Documentation/notation/text.itely:1464: Would it be appropriate to add something after this @lilypond example like: For the full OpenType font feature list please see: @uref{https://www.microsoft.com/typography/otspec/featurelist.htm} Otherwise LGTM
Sign in to reply to this message.
https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... File Documentation/notation/text.itely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... Documentation/notation/text.itely:1464: On 2017/07/26 15:38:12, pkx166h wrote: > Would it be appropriate to add something after this @lilypond example like: > > For the full OpenType font feature list please see: > > @uref{https://www.microsoft.com/typography/otspec/featurelist.htm} > > Otherwise LGTM I like this idea. Most fonts that support at least one OpenType feature will have it specifically mentioned in its specimen sheet. However, since not all fonts have a specimen sheet, I think it's good to reference the full list so the user knows what options are even available.
Sign in to reply to this message.
LGTM https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#ne... Documentation/changes.tely:1037: It would be nice to have an example of a feature that needs an index (e.g., the `salt' or `swsh' features).
Sign in to reply to this message.
Add full feature list and indexed feature
Sign in to reply to this message.
Thank you for your reviewing. https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#ne... Documentation/changes.tely:1037: On 2017/07/26 20:09:33, lemzwerg wrote: > It would be nice to have an example of a feature that needs an index (e.g., the > `salt' or `swsh' features). Done. https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... File Documentation/notation/text.itely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... Documentation/notation/text.itely:1464: On 2017/07/26 15:38:12, pkx166h wrote: > Would it be appropriate to add something after this @lilypond example like: > > For the full OpenType font feature list please see: > > @uref{https://www.microsoft.com/typography/otspec/featurelist.htm} > > Otherwise LGTM Done.
Sign in to reply to this message.
Thanks for the additions. LGTM.
Sign in to reply to this message.
On 2017/07/27 13:47:01, trueroad wrote: > Thank you for your reviewing. > > https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely > File Documentation/changes.tely (right): > > https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#ne... > Documentation/changes.tely:1037: > On 2017/07/26 20:09:33, lemzwerg wrote: > > It would be nice to have an example of a feature that needs an index (e.g., > the > > `salt' or `swsh' features). > > Done. > > https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... > File Documentation/notation/text.itely (right): > > https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.i... > Documentation/notation/text.itely:1464: > On 2017/07/26 15:38:12, pkx166h wrote: > > Would it be appropriate to add something after this @lilypond example like: > > > > For the full OpenType font feature list please see: > > > > @uref{https://www.microsoft.com/typography/otspec/featurelist.htm} > > > > Otherwise LGTM > > Done. This is really great! Do you happen know what the current limitations are? Or rather, having the full feature list is great, but if only a few features are actually recognized by the underlying typography engine (it's still Pango, right?), that would probably be a better list to show, unless they're all recognized, of course.
Sign in to reply to this message.
> This is really great! Do you happen know what the current limitations are? Or > rather, having the full feature list is great, but if only a few features are > actually recognized by the underlying typography engine (it's still Pango, > right?), that would probably be a better list to show, unless they're all > recognized, of course. In general, Pango is agnostic of the features themselves, AFAIK. It simply forwards the selected stuff to the font in question. However, the user has first to look up what the font he or she wants to use actually supports, but this is not lilypond's job. What could be added, though, is a link to such a font inspection tool that reports the font's OpenType capabilities (i.e., supported scripts, languages, features).
Sign in to reply to this message.
On 2017/07/31 16:58:40, lemzwerg wrote: > In general, Pango is agnostic of the features themselves, AFAIK. It simply > forwards the selected stuff to the font in question. If Pango really is agnostic of the features, that is really exciting and a bit mysterious ;-). > However, the user has first to look up what the font he or she wants to use > actually supports, but this is not lilypond's job. Oh, I get that. Perhaps a note should be added, though, to mention that if the user requests a feature that doesn't exist in the chosen font, then the feature is simply ignored. > What could be added, though, is a link to such a font inspection tool that > reports the font's OpenType capabilities (i.e., supported scripts, languages, > features). Sounds good to me! Is there a web-based tool that can do this? That'd eliminate the need to install another app just to inspect a font's features. I use FontForge all the time, so I understand how to do it, but a "normal" user probably won't have a font editor.
Sign in to reply to this message.
> If Pango really is agnostic of the features, that is really exciting and a bit > mysterious ;-). Why? It's not Pango but HarfBuzz that processes (i.e., applies) the OpenType features to a run of glyphs. > Perhaps a note should be added, though, to mention that if the > user requests a feature that doesn't exist in the chosen font, then the feature > is simply ignored. Yep. > Is there a web-based tool that can do this? That'd eliminate > the need to install another app just to inspect a font's features. I use > FontForge all the time, so I understand how to do it, but a "normal" user > probably won't have a font editor. I'm not aware of such an online tool. I've posted a question on Typedrawers. http://typedrawers.com/discussion/2292/list-of-opentype-font-feature-inspecti...
Sign in to reply to this message.
On 2017/07/31 17:48:10, lemzwerg wrote: > > If Pango really is agnostic of the features, that is really exciting and a bit > > mysterious ;-). > > Why? It's not Pango but HarfBuzz that processes (i.e., applies) the OpenType > features to a run of glyphs. Ah, I see! Thanks for clarifying that. I didn't realize Harfbuzz was part of the picture. Guess I haven't looked deep enough into the code.
Sign in to reply to this message.
> I'm not aware of such an online tool. I've posted a question on Typedrawers. > > http://typedrawers.com/discussion/2292/list-of-opentype-font-feature-inspecti... At least for the command line I got the right information! Given that many people already have TeXLive installed, the `otfinfo' program is already available and does the right thing. It can also be downloaded separately from https://www.lcdf.org/type/ However, I haven't yet got a point for something that does the same with a GUI or online.
Sign in to reply to this message.
Add notes and identification way
Sign in to reply to this message.
On 2017/08/01 15:05:46, trueroad wrote: > Add notes and identification way If I understand correctly, I've found a current limitation. I could not find a way to specify OpenType font scripts and languages. So I've added it to the document. Also I've added feature identification way etc.
Sign in to reply to this message.
On 2017/08/01 15:08:11, trueroad wrote: > On 2017/08/01 15:05:46, trueroad wrote: > > Add notes and identification way > > If I understand correctly, I've found a current limitation. > I could not find a way to specify OpenType font scripts and languages. > > So I've added it to the document. > Also I've added feature identification way etc. If I'm not mistaken, you don't need to specify the script/language. That's part of the OpenType feature itself. In other words, if the feature is requested for a glyph outside the scripts/languages that the feature was specified for, the feature is not applied. Is that correct, Werner? Otherwise, LGTM.
Sign in to reply to this message.
On 2017/07/31 17:55:29, tisimst wrote: > On 2017/07/31 17:48:10, lemzwerg wrote: > > It's not Pango but HarfBuzz that processes (i.e., applies) the OpenType > > features to a run of glyphs. > > Ah, I see! Thanks for clarifying that. I didn't realize Harfbuzz was part of the > picture. Guess I haven't looked deep enough into the code. I looked into the latest Harfbuzz internals, and it looks like the list of supported OpenType features is manually maintained. Not all the features listed on the Microsoft feature registry are supported, but many are. The full list can be found here: https://github.com/behdad/harfbuzz/blob/9813be3d1212eef5a525d64978e0bb2032cd4... This list covers pretty much all likely candidates a user is going to encounter or want to use in modern fonts, so it probably isn't worth listing each of the supported features.
Sign in to reply to this message.
> If I'm not mistaken, you don't need to specify the script/language. > That's part of the OpenType feature itself. In other words, if the > feature is requested for a glyph outside the scripts/languages that > the feature was specified for, the feature is not applied. Is that > correct, Werner? No, it's not. As an example, consider the `small caps' feature. If you have a word like `kodalli' and you select, say, `English', you get `KODALLI' in small caps. However, if you select `Turkish', you get `KODALLİ' (in small caps, of course) – provided the font in question has support for Turkish. Similarly, there are many, many CJK glyphs that have the same code points but different glyph representation forms depending on the selected language (or sometimes depending even on the selected region, cf. Taiwan vs. Mainland China). Another example is the behaviour of punctuation; Unicode has separate blocks for them not assigned to a specific script. Depending on the script, different glyph shapes might be used – as a fictional example, a full stop in Devanagari might not be positioned on the baseline but in the middle of the line. In other words, it is sometimes very important to be able to select script and language.
Sign in to reply to this message.
> I looked into the latest Harfbuzz internals, and it looks like > the list of supported OpenType features is manually maintained. Nope. > Not all the features listed on the Microsoft feature registry > are supported, but many are. HarfBuzz is agnostic to most features; if you select a feature, and the feature is available, and the other feature constraints are met, it simply gets applied. > This list [in HarfBuzz] covers pretty much all likely candidates > a user is going to encounter or want to use in modern fonts, so it > probably isn't worth listing each of the supported features. You are mistaken. What you are referring to is a special interface to OS X's `coretext' implementation of OpenType. There exist far more features than you will ever use. Additionally, a large deal of features is not to be set (or unset) by the end user – for example, most of the Indic font features have to be always applied. Similarly, Arabic features (`isol', `fina', `medi', `init', etc., etc.) must be always applied in a specific order to get correct rendering results.
Sign in to reply to this message.
On 2017/08/01 17:49:47, lemzwerg wrote: > > I looked into the latest Harfbuzz internals, and it looks like > > the list of supported OpenType features is manually maintained. > > Nope. > > > Not all the features listed on the Microsoft feature registry > > are supported, but many are. > > HarfBuzz is agnostic to most features; if you select a feature, and the feature > is available, and the other feature constraints are met, it simply gets applied. > > > This list [in HarfBuzz] covers pretty much all likely candidates > > a user is going to encounter or want to use in modern fonts, so it > > probably isn't worth listing each of the supported features. > > You are mistaken. What you are referring to is a special interface to OS X's > `coretext' implementation of OpenType. I very much appreciate your insight and correction. So, there's no reason to provide or point to a separate list other than the Microsoft registry?
Sign in to reply to this message.
> I very much appreciate your insight and correction. So, there's no > reason to provide or point to a separate list other than the > Microsoft registry? Well, there is. As told before, the registry contains many, many features not relevant for Joe User. It would be beneficial if the most important (i.e., the typographically interesting) ones should be listed somewhere – actually, the list in HarfBuzz for coretext looks like a good starting point.
Sign in to reply to this message.
I've pushed to staging. commit 07125596018d32e3235e80627915cfac77323272 Date: Wed Jul 26 21:04:33 2017 +0900 Issue 5164: Doc: Add usage of OpenType font feature
Sign in to reply to this message.
|