Bug 58941

Absolutely and completely agree. I want stylistic sets, or stylistic alternates. Graphite isn't the only advanced font technology out there, and while support for it is great, a ton of fonts out there still use OpenType features.

Seems like a reasonable enhancement request, marking as such.

Leaving as medium priority as I don't know how difficult this would be to implement or how many people would benefit from it. 

Thanks for the request/suggestion :)

Not exactly the same, but tightly related: 
Enhance existing UI elements to check for corresponding OT-features in the fonts and apply them if selected. For example smallcaps, superscripts and subscripts switches should check for smcp/sups/subs (or sinf) features and apply these features instead of artificially creating fake smallcaps etc.

Should I open a new report for this?

Created attachment 73540 [details]
Microsoft Word 2010's interface for OpenType features

The menu in the attachment is accessed with Font > "Advanced" tab. For example, the drop down menu for "Number Forms" offers "Old-style" and "Default", and "Stylistic Sets" shows the numbers 1-20. I'd say this would be a reasonable interface for the features.

*** Bug 59603 has been marked as a duplicate of this bug. ***

Apple has released the source code of its simple TextEdit word processor, which has reasonable OpenType support, under a license similar to the BSD licenses. XeTeX has the best OpenType feature support on the market today, and it's released under the MIT License. Could LibreOffice make use of either of these?

See the diagram on the top right on page 25 of http://xml.web.cern.ch/XML/lgc2/xetexmain.pdf (or page 13 with the document's numbering). It's similar to LibreOffice's existing Insert Special Character interface (see bug 56301 for my complaints about that one), but when a user clicks and holds (hovers, perhaps?) all the alternate OpenType glyphs appear. I'd say that this would be an even better interface, or it could be supplemental to one in the style of Microsoft Word 2010.

It would be indeed helpful if LibreOffice supported the optional smartfont features of OpenType and integrated them into the user interface (for OpenType and Graphite)

Hi,

I think this would be interesting due to compatibility with MS Word...

I don't know if that's a goal for which LO aims.

Although stylistic sets are designed to be mutually exclusive, it would be good if it were possible to activate more than one at a time.

(In reply to comment #11)
> Although stylistic sets are designed to be mutually exclusive, it would be
> good if it were possible to activate more than one at a time.

Why should they be mutually exclusive?

Suppose the default glyph for "a" in a font has a long tail, similar to Helvetica or Arimo/Liberation Sans. Suppose that the author has created two stylistic sets: "ss01" removes that tail from the a, and "ss02" makes it a one-story a. This would create a conflict if the user activated both at once, so this problem would have to be addressed. Perhaps, if the user tries to activate two conflicting features at once, there should be an error message.

(In reply to comment #13)
> Suppose the default glyph for "a" in a font has a long tail, similar to
> Helvetica or Arimo/Liberation Sans. Suppose that the author has created two
> stylistic sets: "ss01" removes that tail from the a, and "ss02" makes it a
> one-story a. This would create a conflict if the user activated both at
> once, so this problem would have to be addressed. Perhaps, if the user tries
> to activate two conflicting features at once, there should be an error
> message.

This is not an issue for the rendering engine. It only has to cycle through the lookups and apply one active GSUB rule after the other. It’s the font designer’s task to make sure to prevent inconsistencies. 

In your case, there would be a feature ss01: substitute a by a.notail and ss02: substitute a by a.onestory. In this case, the program will find an “a” in a text, cycle through the lookups and find a match in ss01, so a gets replaced with a.notail. Then it continues but won’t find a match in ss02 because now there’s no longer an a but an a.notail for which no lookup exists in ss02. If the font designer wished to get a match here too, he would add substitute a.notail by a.onestory to his ss02 lookups. You see, the order in which the lookups appear in the font is important (there’s no fixed order, one is absolutely free to put ss02 before ss01 in their font), LO doesn’t have an influence here and there’s no need for error messages. It’s more a question of the font’s documentation.

That's a relief to know. So it is possible to activate more than one at once.

(In reply to comment #15)
> That's a relief to know. So it is possible to activate more than one at once.

Yes. You may even activate every single feature available in a font at the same time, even such contradictory ones like tabular and proportional numbers or sub- and superscript, and the worst thing that should happen is, that some simply won’t have any effect.

*** Bug 63076 has been marked as a duplicate of this bug. ***

If there'll be any work on this, please-oh-please don't emulate the MS's "we know what's good for you" encapsulation.

Much more better (and logical) to have checkbox-list of font variants on a separate tab in character/paragraph dialogs. I understand the complete list of variants is extractable from font file for each "smart technology" (Graphite, etc.)?

On the other hand, Apple's mod of the 'insert character' dialog seems to be optimal (but is it implementable in LO?)

(In reply to comment #18)
> If there'll be any work on this, please-oh-please don't emulate the MS's "we
> know what's good for you" encapsulation.
> 
> Much more better (and logical) to have checkbox-list of font variants on a
> separate tab in character/paragraph dialogs.

This seems reasonable.

> I understand the complete list
> of variants is extractable from font file for each "smart technology"
> (Graphite, etc.)?

At least for opentype, it is extractable.

(In reply to comment #19)
> On the other hand, Apple's mod of the 'insert character' dialog seems to be
> optimal (but is it implementable in LO?)

What does that look like? At least the title “insert character” doesn’t sound adequate for the desired feature.

I mean the Indesign dialog on page 25 of PDF which Linus linked to in comment #7.

(In reply to comment #21)
> I mean the Indesign dialog on page 25 of PDF which Linus linked to in
> comment #7.

Ok, might be useful, but only in addition to a general feature selecting interface. This character table hack would make use of the aalt feature which needs to be implemented in the font (which isn’t the case for EB Garamond yet).

Of course, I didn't mean such 'Insert character' would preclude implementing a comprehensive font variant selector. 'Apples and oranges' :).

The question of feasibility remains -- while variants may already be set (and saved) via the ":feat=1" mechanism in font face field, albeit not handily and not universally (#63076), is it at all possible to insert (and save) a glyph with variants? Wouldn't it require changes in OD file format, even?

(In reply to comment #23)
> Of course, I didn't mean such 'Insert character' would preclude implementing
> a comprehensive font variant selector. 'Apples and oranges' :).
> 
> The question of feasibility remains -- while variants may already be set
> (and saved) via the ":feat=1" mechanism in font face field, albeit not
> handily and not universally (#63076), is it at all possible to insert (and
> save) a glyph with variants? Wouldn't it require changes in OD file format,
> even?

A quick search found me this document: https://lists.oasis-open.org/archives/office-comment/201008/pdf00000.pdf
It proposes two solutions to this problem of which one doesn’t need changes to the format and which seems to be used for Graphite already (else Graphite wouldn’t work either). So it is feasible.

Well, I didn't think of that (not that I know much of ODF). Anyway, personally I'm even more interested in #56076 getting fixed.

As you can see at http://blogs.linux.ie/caolan/2013/03/12/opentype-locl-localized-forms/, Caolán McNamara has implemented the OpenType 'locl' feature, but that's only one out of a wealth of typographic resources.

Note: there is currently no OpenType implementation that supports slashed zero. Can LibO be the first?

Here's a complete Web implementation of OpenType: http://www.impallari.com/testing/ And its source code: https://github.com/impallari/font-testing-page

Will get (have got?) into the 4.1.0? Splendid. Thanks for the tip.

Does someone know of any progress pertaining to the #56076 ?
Actually, it's closed, and on quite a presumption, I think, but still?

Seems to be one of those quite obvious things (and elementary in implementation, too, all needed things are already there) that nobody knowledgeable wants to dirty their hands with.

(In reply to comment #28)
> Does someone know of any progress pertaining to the #56076 ?
> Actually, it's closed, and on quite a presumption, I think, but still?

This probably isn't the right bug to be asking that.

(In reply to comment #26)
> As you can see at
> http://blogs.linux.ie/caolan/2013/03/12/opentype-locl-localized-forms/,
> Caolán McNamara has implemented the OpenType 'locl' feature, but that's only
> one out of a wealth of typographic resources.
> 
> Note: there is currently no OpenType implementation that supports slashed
> zero. Can LibO be the first?

What do you mean by that? Lots of applications support the 'zero' feature, among others Xe- and LuaTeX and Harfbuzz. I suppose, that ICU supports it too (it’s usually implemented as simple substitution, so nothing special to do there for the engine), LibO is only lacking an interface to activate it.

Oops. I was relying on an old chart about OpenType feature support, but it seems that several applications have implemented it since then. http://ilovetypography.com/OpenType/opentype-features.html

I've just found a free and open source implementation of OpenType (even if it is called "TrueType Viewer"). It's available at http://home.kabelfoon.nl/~slam/fonts/truetypeviewer.html.

Hello everybody,
Supporting the locl substitution table is fundamental for Serbian because Serbian needs some special glyphs to be properly typeset. Have you set a roadmap for the implementation of these features?
Regards,

(In reply to comment #33)
> Hello everybody,
> Supporting the locl substitution table is fundamental for Serbian because
> Serbian needs some special glyphs to be properly typeset.

That’s already implemented - on Linux at least. See bug 62154.

(In reply to comment #30)
> (In reply to comment #26) 
> What do you mean by that? Lots of applications support the 'zero' feature,
> among others Xe- and LuaTeX and Harfbuzz. I suppose, that ICU supports it
> too (it’s usually implemented as simple substitution, so nothing special to
> do there for the engine), LibO is only lacking an interface to activate it.

@Georg Duffner: Since LibreOffice 4.1 Linux (and other X11 platforms) were ported to Harfbuzz. See here: https://wiki.documentfoundation.org/ReleaseNotes/4.1#Core
So hopefully, this makes the implementation of smartfont features more feasible.

There are two issues to tackle here (aside from the actual coding): 1) Desiging a proper interface for activating the features (SIL had some document comparing different UIs for this, plus there own recommendation) 2) Figuring out how to save the feature setting in ODF cleanly (I assume ODF do not have a way to do this right now, so one will need to research other standards like CSS or OOXML and figure out what ODF extension we need).

So, perhaps people interested on this can work on those two items (which should help improving Graphite support in LibreOffice as well, and I think there were some research on this when Graphite support was first introduced).

Once we have a clear idea what needs to be done, I hope to be able to work on implementing it.

(In reply to comment #36)
> There are two issues to tackle here (aside from the actual coding): 1)
> Desiging a proper interface for activating the features (SIL had some
> document comparing different UIs for this, plus there own recommendation) 2)
> Figuring out how to save the feature setting in ODF cleanly (I assume ODF do
> not have a way to do this right now, so one will need to research other
> standards like CSS or OOXML and figure out what ODF extension we need).
> 

Microsoft Word 2010's interface for OpenType features is an excellent starting point, except for the stylistic sets, which could be provided on check boxes.

The ODF 1.2 spec cites the CSS3 Text Module as a non-normative reference. The CSS3 Text namespace is typically included in ODT documents produced by LibreOffice Writer. Because of this, it seems logical and justified to use the [CSS Fonts Module Level 3](http://www.w3.org/TR/css3-fonts/) for all advanced typographic features. This CSS module takes into account the three major smart font technologies: OpenType, Graphite and AAT. It now has “Candidate Recommendation” status and it is set to become a Recommendation relatively soon.

Using this module’s vocabulary in attributes on the `style:text-properties` element seems straightforward. An added benefit is that the `style:font-name` and other such attributes would not be overloaded with font feature names.

Consider the following example:

    <style:style
	 style:name='cited-author'
	 style:family='text'>
	
      <style:text-properties
       style:font-name='Linux Libertine O'
	   css3f:font-synthesis='none'
	   css3f:font-variant-caps='small-caps'
      />
	
    </style:style>

This would be roughly equivalent to the following CSS:

    .cited-author {
	  font-family: 'Linux Libertine O', serif;
	  font-synthesis: none;
	  font-variant-caps: small-caps;
	}

Note that I use `css3f` to refer to the CSS3 Fonts namespace, which is coherent with the namespace prefix already used for the CSS3 Text Module (`css3t`) in ODF.

[Appendix A](http://www.w3.org/TR/css3-fonts/#platform-props-to-css) (non-normative) begins thus: “Font properties in CSS are designed to be independent of the underlying font formats used”. Indeed, the new syntax for feature selection is different from the terse OpenType tags and is more in line with the rest of CSS’s vocabulary. This generality is very desirable for ODF as well. In addition to new @-rules and new `font-variant` properties, low-level control of OpenType features is also available through the `font-feature-settings` property, but this is less general and should only be used for complex and unusual combinations of OpenType features which cannot be expressed in another way.

I cannot think of a better way to correctly model advanced typography in ODF. It is clean, standard and takes us away from the limitations of the Formatting Objects vocabulary. It would also give LibreOffice *quite an edge* over MS Office. It’s the way forward! ;-)

Here some UI mockups by type designers, just for reference:

https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/

Generally, just recently, after the last ATypI conference a petition was started by type designers towards Adobe to have them include a better UI. Expect in the next weeks and months an intensive dialogue to surface.

I also found some of open-source fonts such as Linux Libertine, EB Garamond, have some special rendering, such as alternative glyphs and swashes, optional / historic ligatures, need OpenType feature tags to be passed to the font. MS Office 2013's component such as Word 2013 have a GUI operations to choose OpenType variants in the "Font" dialog, but it is a proprietary software of Microsoft. Some TeX-based free softwares, such as XeTeX or XeLaTeX, can use some OpenType feature, but you muse use lot of codes to implement. so I wish you to support OpenType feature handling and add some operations to the Font dialog.

Here are some samples using OpenType feature:
http://www.linuxlibertine.org/index.php?id=87&L=1
http://www.numbertext.org/linux/fontfeatures.pdf
https://github.com/georgd/EB-Garamond/blob/master/specimen/Specimen.pdf?raw=true