Bug 58941 - Support enabling optional smart font features
Summary: Support enabling optional smart font features
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
QA Contact: Florian Reisinger
URL:
Whiteboard:
Keywords:
: 59603 63076 (view as bug list)
Depends on:
Blocks: 71732
  Show dependency treegraph
 
Reported: 2013-01-02 10:39 UTC by Georg Duffner
Modified: 2016-04-10 19:26 UTC (History)
21 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

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 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 Khaled Hosny 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 General Kutuzov 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 General Kutuzov 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 General Kutuzov 2015-04-22 04:53:40 UTC
(In reply to Joel Madero from comment #42)
> @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

Oh~sorry for my fault. I found all the feature ID as U inputed only available for Graphite fonts, but OT and AAT fonts cannot access their features in this way. There are some opdn-source and powerful typesetting engines can handle these features, why not make use of them?
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 General Kutuzov 2015-10-27 14:34:18 UTC
I think you can try to get this support via Pango.

https://bugzilla.gnome.org/show_bug.cgi?id=738505
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 General Kutuzov 2015-10-27 17:30:37 UTC
So what if using HarfBuzz on all platforms?
Comment 51 General Kutuzov 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 Khaled Hosny 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 General Kutuzov 2015-11-07 09:14:15 UTC
(In reply to Khaled Hosny from comment #52)
> (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.

I know this extension is designed for Graphite initially, but it seems to that this extension is just adding or modifing feature tag and value after font name, some of feature tags in this extension is also available in OT specification.
Comment 54 General Kutuzov 2015-11-08 03:02:24 UTC
I think the OpenType feature 'locl' can be used through changing the language of text in “Character” dialog, this is very useful for Serbian and Macedonian speaking people.
Comment 55 General Kutuzov 2015-11-08 08:20:55 UTC
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.
Comment 56 Khaled Hosny 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 General Kutuzov 2015-11-08 08:37:15 UTC
(In reply to Khaled Hosny from comment #56)
> (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.

Oh, I hope someone can submitting a draft to improve the ODF specification.
Comment 58 General Kutuzov 2015-11-08 08:48:35 UTC
Additionaly, to avoid unexpected situations, I think the option that can be let OT superscript/subscript enabled shouldn’t be enabled by default.
Comment 59 General Kutuzov 2015-11-08 09:39:57 UTC
(In reply to General Kutuzov from comment #54)
> I think the OpenType feature 'locl' can be used through changing the
> language of text in “Character” dialog, this is very useful for Serbian and
> Macedonian speaking people.

This way of controling 'locl' feature can be independent of saved file.
Comment 60 General Kutuzov 2015-11-09 17:50:56 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.

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.
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 General Kutuzov 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.