Re: [Gimp-gui] opentype feature support

[Jehan <jehan girinstud io>]

Hi Liam!

On 6/22/21 1:36 AM, Liam R E Quin wrote:
> Inkscape and LibreOffice both have some openType font feature support.
> It's a major part of OpenType, and it's big in graphic design. Examples
> include
> * alternate glyphs, that might be accessed with a "gyph palette"
> * enabling small caps, different styles of numerals
> * control over ligatures (fi, ffi, ct, st) and historical forms (these
> vary by language, but tall-s is an example, e.g. used in Fraktur as
> well as older Roman types, and moderately widely supported by fonts
> today)
> * swash forms, very popular in graphic design - e.g. a long
> calligraphic tail on a Q or R
Probably nobody is again adding support for OpenType. 😉
> LibreOffice has a font name scheme that looks a bit like URI/URL
> parameters, and it'd be good if those names also worked in Inksape,
> Krita, GIMP etc., which suggests maybe fontconfig support and an XDG
> spec.
>
> The GIMP text tool should support a glyphs palette, in which users can
> pick characters & alternate characters. This could also be an external
> service shared with other programs butright now  i'mthinking there'd be
> a glyph doc.
>
> GIMP could also support setting/unsetting font features over ranges
> (span) of text, just as it supports bold & italics today. The hard part
> here is the user interface.
Yeah. I think as a general rule, our current support of text's current 
weak point is the user interface (OpenType or not!). 🤪
> I'm right now thinking it'd be like other things in gimp -
> * create new "Font" based on existing one
> * a dialogue (dock) to edit opentype  font features, e.g.  kerning
> on/off, and to give the "font" a  name
> * then you'd be able to use this "font" in the existing text tools.
>
> Users should also be able to find fonts with specific opentype
> features, and specific language support. We could use the existing
> tagging mechanism for this, and add some default tags. I've tried this
> and suspect there may be some performance issues, but they are
> resolvable.
>
> The gtk4-demo program emphasizes internationalization rather than
> graphic design in the way it shows font features; libreoffice has a
> moderately compact widget for enabling/disabling font features. But, as
> with Inkscape, it's hidden under a button to make it "advanced".
>
> I think this is because it's hard to see how to make a generic UI for
> it. There's some 30 or so (i forget) different font features.
>
> But they are not all equal. For example, turning kerning on or off is
> one of them. This is much more basic than controlling historical
> ligatures & a UI could treat them separately.
>
> We also have a split text UI today, with on-canvas editing and also
> tool options editing e.g. for choosing a default font. And a text
> editing box.
>
> An alternate design would be to present font feature settings as
> properties of the text (like bold and underline) rather than of the
> font, so you'd select a span of text and click "discretionary ligatures
> n, please" or "small caps here"
>
> A compromise might be if the drop-down list of fonts on-canvase for the
> text tool kept the most recently used few fonts copied at the top of
> the list, so if you'd defined your own variants you could switch to
> them easily.
>
> What  do you think?

I think you are one of the most knowledgeable we got around about 
OpenType or text in general. What about proposing some design spec, 
maybe even with some mockups of how you see this support?

While you do this, do not hesitate to also propose redesign of current 
text layer interface which is clearly very lacking.

I believe that from a first concrete proposition, it will be easier to 
start discussing, agreeing or disagreeing and tweaking than staying on 
too much of a higher level (where we all agree: would be nice to have 
support! 😛).

> (i can't promise i'll  ever actually get to much of this but if we
> have a discussion maybe it can happen bit by bit)

It can always be done little by little, but I still think we need to 
start with concrete propositions. You don't have to propose directly a 
full spec for the whole support, but it can be done by steps, yet still 
with concrete propositions.

Also to be fair, a more global redesign of the text tool has been in 
order for years. I think a good start would be to see how a good text 
interface should look like nowadays, with new technologies (such as 
OpenType fonts) in mind. Review the bases.

Of course, we would still need to find the developers willing to 
implement this future interface, but if we already had a well-specified 
design, it could trigger someone to try and implement it. It could even 
become a "newcomer" feature ("newcomer" is the flag for reports which we 
consider suitable for new contributors not used to our userbase yet).

Jehan

> Liam / slave ankh / demiboy / whatever
--
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot