Bug 58941 - Support enabling optional smart font features
Summary: Support enabling optional smart font features
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0
Keywords:
: 59603 63076 105710 (view as bug list)
Depends on: HarfBuzz
Blocks: 68573 Font-Rendering 104281 108562 105087 105516 127127 127423
  Show dependency treegraph
 
Reported: 2013-01-02 10:39 UTC by Georg Duffner
Modified: 2023-08-07 09:43 UTC (History)
30 users (show)

See Also:
Crash report or crash signature:


Attachments
Microsoft Word 2010's interface for OpenType features (4.66 KB, image/png)
2013-01-23 20:36 UTC, Linus Drumbler
Details
PNG illustrating "Th" ligature controle for Graphite and OpenType (33.93 KB, image/png)
2015-04-24 15:40 UTC, David
Details
Office 2016 screenshot (82.62 KB, image/png)
2015-10-05 11:13 UTC, Iandol
Details
screenshot from OS X general (31.12 KB, image/png)
2015-10-05 11:15 UTC, Iandol
Details
QuarkXpress OpenType interface examples (230.14 KB, image/jpeg)
2018-04-01 00:15 UTC, LibreTraining
Details
graphite features panel (117.89 KB, image/png)
2018-08-10 06:15 UTC, martin_hosken
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Duffner 2013-01-02 10:39:09 UTC
LO should provide an interface to enable optional smartfont features like liga, sups etc. and also to disable optional features that are enabled by default like calt etc.
Ideally this interface covers all three smartfont technologies (Opentype, Graphite and AAT).
Comment 1 Linus Drumbler 2013-01-05 23:52:08 UTC
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.
Comment 2 Joel Madero 2013-01-10 17:09:00 UTC
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 :)
Comment 3 Georg Duffner 2013-01-11 08:07:52 UTC
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?
Comment 4 Linus Drumbler 2013-01-23 20:36:14 UTC
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.
Comment 5 Linus Drumbler 2013-01-25 18:47:45 UTC
*** Bug 59603 has been marked as a duplicate of this bug. ***
Comment 6 Linus Drumbler 2013-02-02 22:32:04 UTC
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?
Comment 7 Linus Drumbler 2013-02-03 21:14:28 UTC
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.
Comment 8 Gerry 2013-02-23 12:39:18 UTC
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)
Comment 9 Florian Reisinger 2013-02-24 20:15:07 UTC
Hi,

I think this would be interesting due to compatibility with MS Word...
Comment 10 Linus Drumbler 2013-02-24 21:18:39 UTC
I don't know if that's a goal for which LO aims.
Comment 11 Linus Drumbler 2013-03-03 18:28:22 UTC
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.
Comment 12 Georg Duffner 2013-03-06 23:04:32 UTC
(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?
Comment 13 Linus Drumbler 2013-03-10 19:56:01 UTC
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.
Comment 14 Georg Duffner 2013-03-10 22:43:42 UTC
(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.
Comment 15 Linus Drumbler 2013-03-11 15:14:14 UTC
That's a relief to know. So it is possible to activate more than one at once.
Comment 16 Georg Duffner 2013-03-15 13:29:34 UTC
(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.
Comment 17 Georg Duffner 2013-04-10 07:11:31 UTC
*** Bug 63076 has been marked as a duplicate of this bug. ***
Comment 18 Yury 2013-04-10 07:32:18 UTC
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.)?
Comment 19 Yury 2013-04-10 07:38:02 UTC
On the other hand, Apple's mod of the 'insert character' dialog seems to be optimal (but is it implementable in LO?)
Comment 20 Georg Duffner 2013-04-10 08:05:43 UTC
(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.
Comment 21 Yury 2013-04-10 08:41:45 UTC
I mean the Indesign dialog on page 25 of PDF which Linus linked to in comment #7.
Comment 22 Georg Duffner 2013-04-10 08:53:41 UTC
(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).
Comment 23 Yury 2013-04-10 09:26:59 UTC
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?
Comment 24 Georg Duffner 2013-04-10 09:39:02 UTC
(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.
Comment 25 Yury 2013-04-10 10:37:31 UTC
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.
Comment 26 Linus Drumbler 2013-05-22 19:27:21 UTC
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?
Comment 27 Linus Drumbler 2013-05-22 19:30:05 UTC
Here's a complete Web implementation of OpenType: http://www.impallari.com/testing/ And its source code: https://github.com/impallari/font-testing-page
Comment 28 Yury 2013-05-22 19:50:23 UTC
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.
Comment 29 Linus Drumbler 2013-05-25 05:02:09 UTC
(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.
Comment 30 Georg Duffner 2013-05-28 09:08:52 UTC
(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.
Comment 31 Linus Drumbler 2013-05-28 16:07:47 UTC
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
Comment 32 Linus Drumbler 2013-06-19 18:00:17 UTC
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.
Comment 33 Alessandro Ceschini 2013-07-14 18:54:49 UTC
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,
Comment 34 Adolfo Jayme Barrientos 2013-07-31 09:01:02 UTC
(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.
Comment 35 Gerry 2013-11-25 21:42:20 UTC
(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.
Comment 36 ⁨خالد حسني⁩ 2013-11-26 06:27:53 UTC
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.
Comment 37 João Paulo 2014-05-08 03:34:02 UTC
(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.
Comment 38 Christian Gagné 2014-05-12 15:26:00 UTC
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! ;-)
Comment 39 szabi 2014-11-11 21:05:14 UTC
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.
Comment 40 Volga 2015-01-23 11:20:41 UTC
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
Comment 41 Volga 2015-03-30 10:45:21 UTC
I think despite you do not developed the interface, you should provide a full function and cross-platform API to make use of them.
Comment 42 Joel Madero 2015-03-30 14:04:17 UTC
@General Kutuzov

no need to keep commenting on this enhancement as it doesn't add or move it forward. We know that it's an enhancement - as such, it will depend on volunteers to accept it and implement it. We do not give ETA's but just be prepared to wait a long time for this to be implemented. TDF (the non profit behind LibreOffice) has absolutely no power over what issues/enhancements get implemented, we're a team of volunteers and as such, your options are:

1. Fix it yourself;
2. Find someone to fix it (family, friend, etc...);
3. Pay for a fix;
4. Wait
Comment 43 Volga 2015-04-22 04:53:40 UTC Comment hidden (obsolete)
Comment 44 David 2015-04-24 15:40:33 UTC
Created attachment 115067 [details]
PNG illustrating "Th" ligature controle for Graphite and OpenType

I'm aware that additional comments from simple users rather than coders does nothing to move this enhancement request forward (I see comment #42! ;)

Still, it's worth noting that OpenType support is the most upvoted Q&A on AskLibreoffice, a community which seems fairly congenitally predisposed against voting on anything:

http://ask.libreoffice.org/en/questions/scope:all/sort:votes-desc/page:1/

That's worth noting, especially in light of an early comment (#2): 

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

The latter question is fairly easy to answer, in fact: it would benefit every single user of LibreOffice Writer. I make good use of the Graphite enabled version of Linux Libertine, but it would be so, so good to be able to have similar control over the much wider range of Open Type fonts available. I attach a PNG illustrating one specific use case.

Will continue to hope that this enhancement comes through sooner rather than later (is the GSoC territory?)!
Comment 45 Stefano Costa 2015-05-13 19:49:14 UTC
Some food for thought on this topic from LGM 2015: http://www.freesoftwhere.org/2015/05/07/opentype-workshop-lgm-2015/
Comment 46 Iandol 2015-10-05 11:13:13 UTC
Created attachment 119303 [details]
Office 2016 screenshot

Here is the Advanced Typography UI from Word 2016, not much has changed.
Comment 47 Iandol 2015-10-05 11:15:47 UTC
Created attachment 119304 [details]
screenshot from OS X general

For completeness here is the UI from Apple Pages, though this uses the core OS X opentype support.
Comment 48 Volga 2015-10-27 14:34:18 UTC Comment hidden (obsolete)
Comment 49 Iandol 2015-10-27 15:13:33 UTC
Pango is cross-platform, but does LO use Pango? Having a modern cross-platform text layout engine sure seems like an important upgrade for LO, and there are suggestions it will be easy to implement (comments from Caolan on a disappeared web page).
Comment 50 Volga 2015-10-27 17:30:37 UTC
So what if using HarfBuzz on all platforms?
Comment 51 Volga 2015-11-07 05:37:12 UTC
I found LO 5.0.3 for Windows supporting several OT features such as standard ligature and kerning, but they seems not optional, they can’t be controled via Typographic Toolbar extension (http://extensions.libreoffice.org/extension-center/typography-toolbar).
Comment 52 ⁨خالد حسني⁩ 2015-11-07 05:41:46 UTC
(In reply to General Kutuzov from comment #51)
> I found LO 5.0.3 for Windows supporting several OT features such as standard
> ligature and kerning, but they seems not optional, they can’t be controled
> via Typographic Toolbar extension
> (http://extensions.libreoffice.org/extension-center/typography-toolbar).

This extension is for Graphite, not OpenType fonts.
Comment 53 Volga 2015-11-07 09:14:15 UTC Comment hidden (obsolete)
Comment 54 Volga 2015-11-08 03:02:24 UTC Comment hidden (obsolete)
Comment 55 Volga 2015-11-08 08:20:55 UTC Comment hidden (obsolete)
Comment 56 ⁨خالد حسني⁩ 2015-11-08 08:27:03 UTC
(In reply to General Kutuzov from comment #55)
> I have more ideas for enabing optional OpenType feature, you can improving
> the “Character” dialog to providing oprations. First, the “Small capitals”
> effect (in Font Effects table) can be used for enabing true small capitals
> if a typeface inluding OT feature 'smcp', otherwise displaying scaled small
> captials instead (in this case the Effect option can adding “Pepite
> capitals” to handle pepite caps). Next, the “Superscript” and “Subscript”
> option in Position tab can be used for enabling corresponding OT feature, in
> this case you should adding a check box to let these options uses OT
> superscript and subscript if a typeface support. Third, the right of “Pair
> kerning” option can adding another option to enabing or disabing OT kerning.

You cannot just redefine existing functionality as the OpenType replacement might not work all the time, for example most typefaces that support super and subscript features has very incomplete coverage, so just applying the features instead of scaling will result in some characters as superscript and some are not. This can be said for other features as well, so you will still need a way for the user to manually control the use of OpenType feature here, and this will eventually need to be saved to the file, so we are back to square 0; ODF does not support this AFAIK.
Comment 57 Volga 2015-11-08 08:37:15 UTC Comment hidden (obsolete)
Comment 58 Volga 2015-11-08 08:48:35 UTC Comment hidden (obsolete)
Comment 59 Volga 2015-11-08 09:39:57 UTC Comment hidden (obsolete)
Comment 60 Volga 2015-11-09 17:50:56 UTC Comment hidden (obsolete)
Comment 61 Joel Madero 2015-11-09 17:55:57 UTC
> I have rethought for this idea, only small caps feature can independent of
> saved file; other operations is required to be saved in a file, which need
> ODF specification support, I think someone can submit a draft to let user
> defines typographic feature.

"Someone" - why not you? https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

Also, just a tip, spamming your own bug with 50ish clarifications makes the bug incredibly hard for any developer to look at. I would suggest going to the ODF site, maybe send them an email, close this bug as INVALID (because it's impossible to follow at this point), get clarification from ODF people, then report a new bug over here. I won't close it, but I can guarantee that almost every developer will look at this bug for 5 seconds and then move on because of how many comments (many of which don't enlighten the solution) there are.
Comment 62 Volga 2015-11-10 02:56:42 UTC
> "Someone" - why not you?
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

I heard ODF 1.3 is under formulating, but I don’t know how to send a draft to improve it.
Comment 63 Volga 2016-08-25 07:33:13 UTC
SoftMaker has already decided to support optional font features for OOXML format.

http://forum.softmaker.com/viewtopic.php?f=266&t=16021
Comment 64 ⁨خالد حسني⁩ 2016-11-04 12:52:27 UTC
Features can now be controlled for OpenType fonts in the same syntax as Graphite features. Proper ODF support and UI are still missing.
Comment 65 Volga 2016-11-27 12:24:57 UTC
(In reply to Khaled Hosny from comment #64)
> Proper ODF support and UI are still missing.

1. For ODF support, this can done via making small improves on LO if we discovered an error really affect file loading or saving, if we can get solution based on ODF spec would be better.
2. This seems not enough important to be considering, since an extension can do it.
Comment 66 Iandol 2016-11-27 12:54:46 UTC
(In reply to Volga from comment #65)
> 2. This seems not enough important to be considering, since an extension can
> do it.

I disagree. LO could also remove Bold, small-caps and other settings from the UI too as an extension could do it. The goal should be to empower the user to create the best documents they can, and OT features really make a substantial difference to quality typography.

I know that LO is constrained by the number of developers capable of working on these features, but I still think this remains important. If there is no UI, and even if there is only a hard-to-discover extension, the feature may as well not exist for the majority of users.
Comment 67 Gerry 2016-11-29 15:43:56 UTC
@Khaled Hosny: This is great news that optional smart font features are now supported by LO. I have two of questions related to this:

(1) Where is a good list of supported smart font features and related commands for the font dialog. I know this one, but I am not sure whether there is any better documentation: http://www.numbertext.org/linux/fontfeatures.pdf

(2) Wouldn't it make sense to close this bug as fixed and open four new bugs: (a) a proper UI, 
(b) support in ODF save/load, 
(c) support in OOXML import/export and 
(d) write proper help documentation for the LibreOffice Help.
Comment 68 ⁨خالد حسني⁩ 2016-11-29 17:27:50 UTC
(In reply to Gerry from comment #67)
> @Khaled Hosny: This is great news that optional smart font features are now
> supported by LO. I have two of questions related to this:
> 
> (1) Where is a good list of supported smart font features and related
> commands for the font dialog. I know this one, but I am not sure whether
> there is any better documentation:
> http://www.numbertext.org/linux/fontfeatures.pdf

The official OpenType feature registry is:
https://www.microsoft.com/typography/otspec/featuretags.htm

Basically any feature listed there is supported.

> (2) Wouldn't it make sense to close this bug as fixed and open four new
> bugs: (a) a proper UI, 
> (b) support in ODF save/load, 
> (c) support in OOXML import/export and 
> (d) write proper help documentation for the LibreOffice Help.

I have no strong feeling either way, if someone can file these bugs then I’m fine closing this one, except it has some good ideas, like using CSS Text-3 syntax for ODF, but probably we can copy/link them in the relevant new bugs.
Comment 69 Volga 2016-11-30 14:05:36 UTC
(In reply to Volga from comment #65)
> 2. This seems not enough important to be considering, since an extension can
> do it.

This entension I refered is “Typography Toolbar”, but I think creating an another entension to add an interface is welcome.
Comment 70 Volga 2017-01-28 11:27:58 UTC Comment hidden (obsolete)
Comment 71 ⁨خالد حسني⁩ 2017-02-03 17:27:13 UTC
*** Bug 105710 has been marked as a duplicate of this bug. ***
Comment 72 Volga 2017-03-29 08:59:32 UTC
OASIS Technical Committees Issue Tracker have a proposal OFFICE-3414 releated to this bug.
Comment 73 Volga 2017-03-29 11:45:59 UTC
(In reply to Khaled Hosny from comment #68)
> (In reply to Gerry from comment #67)
> > (2) Wouldn't it make sense to close this bug as fixed and open four new
> > bugs: (a) a proper UI, 
> > (b) support in ODF save/load, 
> > (c) support in OOXML import/export and 
> > (d) write proper help documentation for the LibreOffice Help.
> 
> I have no strong feeling either way, if someone can file these bugs then I’m
> fine closing this one, except it has some good ideas, like using CSS Text-3
> syntax for ODF, but probably we can copy/link them in the relevant new bugs.
Since OASIS planned to add it into ODF 1.3, I think we can get support in ODF save/load when this specification is released. For OOXML I have already created bug 104281, but we need a document created by MS Office for test.
Comment 74 Volga 2017-07-20 15:26:05 UTC
(In reply to Volga from comment #73)
> For OOXML I have already
> created bug 104281, but we need a document created by MS Office for test.
I have already uploaded a sample document.
Comment 75 Volga 2017-11-29 10:36:19 UTC
GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can try to add new APIs to allow others write a new extension, to show what OpenType/Graphite feature tags are available in which fonts.
Comment 76 LibreTraining 2018-04-01 00:15:51 UTC
Created attachment 141006 [details]
QuarkXpress OpenType interface examples

The best interface I have seen for OpenType support is in QuarkXpress.
The OpenType features are usually hidden and are accessed from a spinner.
The application actually reads the font file and only activates the available features.
Unavailable features are grayed-out.
So the user knows what is available. 

This image shows examples for Liberation Sans and Minion Pro.
Comment 77 Dave Crossland 2018-05-07 16:09:11 UTC
> GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can ...

Is that https://github.com/harfbuzz/harfbuzz/issues/561 ?
Comment 78 ⁨خالد حسني⁩ 2018-05-07 23:40:48 UTC
(In reply to Dave Crossland from comment #77)
> > GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can ...
> 
> Is that https://github.com/harfbuzz/harfbuzz/issues/561 ?

HarfBuzz has enough API to get anyone started in this, that is not the blocker the real blocker are (in descending order) 1) finding a way to store font features in ODF documents 2) implementing it in LibreOffice 3) Designing and writing a GUI to control the features 4) pushing this through ODF standardization process. Any help is welcomed, I personally have no experience with any of these 4 points.
Comment 79 hmijail 2018-06-12 11:31:29 UTC Comment hidden (off-topic)
Comment 80 ⁨خالد حسني⁩ 2018-06-14 02:50:32 UTC
(In reply to hmijail from comment #79)
> I'd like to report a case in which the apparent lack of a way to disable
> ligatures very nearly made LibreOffice dangerously useless for me.
> 
> I'm keeping my CV in LibreOffice, and generating PDFs from it. Turns out
> that for the last few years CVs seemingly tend to be parsed automatically by
> various softwares that extract the information from them and pre-filter them
> accordingly. And my CV contains a number of keywords that, once turned into
> a PDF and extracted as text, are broken: for example, "firmware" ->
> "frmware". This might make my CV useless! 

That is was fixed in bug 115117.
Comment 81 Commit Notification 2018-06-16 12:29:57 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bda33ba2ce4d53214e1bd9ee62b05ced0525e8db

tdf#58941 implement retrieving font features and structures

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 82 Commit Notification 2018-06-16 18:17:42 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3aa8a048776bdf0d4868847baac2a72aa55cd6a3

tdf#58941 Manipulate with font features using FontFeatureDialog

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 83 Phil Krylov 2018-06-21 10:34:21 UTC
Could this changeset be the cause of bug 118301?
Comment 84 martin_hosken 2018-08-10 06:14:54 UTC
Here is a screenshot of the features panel for a Graphite font (with lots of features). The corresponding panel for an OpenType font lacks support for cvxx and ssxx features beyond their simple name. This is due to lack of cvxx and ssxx access API in harfbuzz and even then the ability to then lookup a nameid to get an appropriate string.

We hope to address these subissues in due course
Comment 85 martin_hosken 2018-08-10 06:15:46 UTC
Created attachment 144081 [details]
graphite features panel
Comment 86 LibreTraining 2018-08-10 20:53:59 UTC
(In reply to Commit Notification from comment #82)
> Tomaž Vajngerl committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=3aa8a048776bdf0d4868847baac2a72aa55cd6a3
> 
> tdf#58941 Manipulate with font features using FontFeatureDialog
> 
> It will be available in 6.2.0.
...> 
> Affected users are encouraged to test the fix and report feedback.

I tested this with libo-master64_2018-06-27.
It appeared to be a work-in-progress with multiple issues.

I just tested with libo-master64_2018-08-08.
Appears to be the same.

Is this going to be the version of this dialog released?
If so, this is may cause more problems than it solves.

For example:
- Users should not be able to enable features which are mutually exclusive.
- There is no option for Default which is appropriate for certain features.

This is nothing more than the fake bold & italic confusion times 10.

The OpenType features dialogs in QuarkXPress 2018 have substantial improvements over 2017 which shows that they have been making improvements based on user feedback.
It is much better. 
And still better than the InDesign OpenType interface.

The grouping and logic work has already been done.
I can even summarize it if it would actually be used to fix this interface.

I would be happy to post multiple screenshots from QuarkXPress 2018 
 - if anyone would actually look at them, and 
 - actually incorporate the better features.

Not going to waste the time if no one is going to even bother to look at them again.
Comment 87 Heiko Tietze 2018-08-16 11:11:22 UTC
@Xisco: Should we reopen this ticket? Or better create a new one.
Comment 88 Xisco Faulí 2018-08-16 13:27:50 UTC
(In reply to Heiko Tietze from comment #87)
> @Xisco: Should we reopen this ticket? Or better create a new one.

Personally, I would prefer to create a new one. This one has 87 comments and is becoming hard to follow...
Comment 89 Heiko Tietze 2018-08-21 08:32:08 UTC
(In reply to LibreTraining from comment #86)
> ...
> I tested this with libo-master64_2018-06-27.
> It appeared to be a work-in-progress with multiple issues.

How about a more polite "Great work, but there are some glitches left"

> - Users should not be able to enable features which are mutually exclusive.

Sounds reasonable to me. Though the dialog just presents the feature that Harfbuzz/Graphite has and there is no such thing as dependency to Tomaz' knowledge (and I'm completely off). If you know more details please share with us.

> - There is no option for Default which is appropriate for certain features.

That option would reset all to off, right? Sounds like a nice to have to me. Anyway, please file new tickets if you think the implementation needs improvements. For what I see there is not much to do.
Comment 90 lisa purnellsw 2023-08-07 02:29:21 UTC Comment hidden (spam)