Font Features UI & Parser

Currently, in Bloom if you want a particular alternate glyph, you have to come up with CSS to select it. e.g.

[lang="kdj"]
{
    font-feature-settings: "dig4" 1;
}

I’m thinking about how we can improve that, and have two questions:

Question 1) Are there any good examples of a program with a user interface that lets you see all your options and select which ones you want? I know about this one from Word:

image

But that does not seem particularly helpful if I want, for example, to get a particular glyph alternate.

I also see this interface in Figma:

image

Which seems like the right idea. We could build a javascript component that takes a font, shows a UI like that, and gives you back the CSS rule needed to activate whatever font-features the user selects.

Are there other UI’s anyone can point me to that I could use for inspiration?

Question 2) I don’t know much about fonts… should I expect opentype.js, which can parse fonts, to tell me all I need to know (for this purpose) about any SIL font?

Thanks for help.

1 Like

Hi John. Yes please! WSTech has been trying to encourage developers to include GUI interfaces to font features.

Be aware that fonts that contain both Graphite and OpenType logic (as do most of SIL’s fonts), contain two sets of feature information: that for Graphite and that for OpenType, and the two sets of feature information are not always identical.

As for extracting feature information from a font, Graphite has an API for this, but I don’t know about OpenType libraries. I can tell you how the information is stored in Opentype, but that is as far as my understanding goes.

Regarding examples of GUIs, I noticed a recent post from Kim Blewett that LibreOffice 6.4 introduced such an interface… I’m just installing to try for myself.

Bob thanks for the tip on LO 6.4. I had only looked in LO 6.1 and didn’t see anything.

Graphite has an API for this

Are you referring to the Python/locally installable server? That’s probably going to be quite problematic for embedding in applications. Maybe we could collaborate with WSTech… y’all provide a Javascript library that can deliver the information for a font of either format, and we make the web UI component that uses it.

Just took a brief look at the code. It does look like OpenType featureParams information – at least the pointer – is returned in the feature structure, so that is a start (for OpenType features, not Graphite). If it is just the pointer, you’ll need to decode the structure. Contact me offline if you want more details.

I did a paper at a Unicode conference on this topic. I can send it to you if you want. It’s dated because at that point LO didn’t have a UI. It has screenshots from Word, InDesign, FleX, etc.
One that I though was particularly nice is from Nisus Writer Pro:

Most of the apps only support Stylistic Sets (ssxx) and not Character Variants (cvxx)

Also, I believe Paul N was working on specking out a UI, but I’m not sure where he got with that.

Thanks Lorna.

I did a paper at a Unicode conference on this topic. I can send it to you if you want.

Yes, please!

I should be clear, this is just a very preliminary inquiry I’m making, to measure how costly the feature would be. If I had a library in hand that could give us all the info, then sure we’d put up a UI soon. But the more of a research project this turns out to be, the more expensive, and so the feature will probably still end up far in the future.

Hi John,
Just curious if this is still considered to be something “far in the future,” as we have recently seen new beta versions of the Andika, Charis, Doulos and Gentium fonts come out for testing with quite a lot of updates to font features like these.
Thanks for all your hard work on this great software!

@JohnHatton Could this be a project for a summer intern? I expect it would be better if the specification came from the software development side, but someone in WSTech could likely help with that.

Could this be a project for a summer intern?

Yes, that sounds doable.

Is going into the css as shown in your original post still the only way to deal with font features in Bloom at the moment?
Thanks

Is going into the css as shown in your original post still the only way to deal with font features in Bloom at the moment?

Yes. That’s not because this is particularly hard, but rather just a perceived lack of a call for it. I just checked the Bloom Feature Requests and did not find a request, let alone one with lots of votes. It’s kind of surprising.

Oh, okay! I would vote for it, since TypeTuner is not yet ready for the font feature we want to use.
But we’ll try to use this method for now.
Thanks!

I wonder if you missed the announcement that Andika now has TypeTuner support again?
https://scripts.sil.org/ttw/fonts2go.cgi
I don’t know what feature you want…but I suspect it is the “Double-story a” or “Double-story g” that is near the bottom of the list.

Thanks for your reply, Lorna.
I did get the announcement. Unfortunately, the feature we want is an obscure one that is not supported yet. cv79
I was told it will be in the next update, whenever that will be.

I’m surprised too that this feature request is not in the Bloom Feature Requests category. I’ve been assuming that this and other posts were an indication that work is happening in Bloom. I have created a Feature Request at
UI for Font Features.

Please add your vote if you feel a need for a UI method for enabling Font Features (alternate forms for specific characters) in Bloom.

1 Like

Paratext has had an easy-to-use UI for Graphite font features for a while. I can’t enable the OpenType features in Paratext 9.2 with Andika 6.01 (OpenType; Graphite removed). Perhaps Paratext hasn’t gotten around to adding OpenType features? Or am I missing something?

Here is the PT dialog for Andika v 5.0 (Graphite features):

PTXPrint offers the same gui for fonts with OpenType or Graphite.
Andika 6:

Andika Compact 5:

There might be some underlying magic going on in PTX Print… I don’t claim to understand it. But I do appreciate being able to select OpenType features by their descriptive names rather than the obscure “cv43=2” and “ss01=1”.

Yes, I find descriptive names more helpful than code numbers.
If there was a sample of the character or feature, that would be an even more helpful bonus. I realize for some features/characters that would be complicated to achieve, but just throwing it out there.

I wonder if you missed the announcement that Andika now has TypeTuner support again?

Tuned fonts are costly in an environment like Bloom where we have to embed any custom font with each copy of the book, and worse, get a copy of your tuned font to host on BloomLibrary.org. So we, too, have an incentive to make it easy to tweak font features in the stylesheet :slight_smile:

2 Likes