Bug 129219 - Further refinement of OpenType/Graphite Font features in the “Character” dialogue
Summary: Further refinement of OpenType/Graphite Font features in the “Character” dial...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2019-12-05 23:45 UTC by Tobias Hemm
Modified: 2022-08-24 06:40 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration of Possible Implementation in Character Dialogue (858.12 KB, image/png)
2019-12-05 23:50 UTC, Tobias Hemm
Details
Table with OpenType Features to be Implemented (138.05 KB, application/pdf)
2019-12-05 23:52 UTC, Tobias Hemm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Hemm 2019-12-05 23:45:51 UTC
Description:
I prepared to file an enhancement for LO Writer regarding a graphical implementation of OpenType features. When I was ready to file the enhancement, I found that, from Version 6.2, something like that is already available. So I updated from 6.1 to 6.2 in order to test it.

And I think It’s not badly done. But in my opinion it could be improved a lot.
My idea was to create a new tab called "OpenType" or "OpenType Features" in the character dialogue. I would make it the second tab. I think this would be better than "hiding" it below the font size column. These features become more an more important, which is why I think that they deserve a more prominent position in a separate tab and more space.

Furthermore, my suggestion would have been to not only group the features in a sensible way in order to provide a clear and comprehensible overview, but also to always show all features and "grey out" the ones not-available in a font.

The attached table shows a possible way of implementing and grouping the features. (If multiple active features are possible, you could use checkboxes (see attached image). If the features of one group are mutually exclusive and therefore only one choice is allowed, use a bullet. For long lists with one option, like with character variants, I would use a dropdown menu.)

Please consider that I am not sure about which of these features are mutually exclusive and which are not, since I am not familiar with all of them from practice. I am also not sure about how to group and order them. There are many features. You can also give me a list with all features you implement, if you want me to do more grouping work.

The list under the following link also provides orientation on grouping etc.:
https://en.wikipedia.org/wiki/List_of_typographic_features
A lot of information about OpenType features can be found under this link.

I attached an image that shows how it could look like, and the above mentioned table shows the features that I would consider needed. For example, the features "Swash" and "Contextual Swash" are missing as graphical options, at the moment. The image is, however, just a demonstration; not all of the features are considered here.

It would be great if you also implemented a description that appears on mouse hover, e.g. if you hover over “Small Caps”, there arises the text “Substitutes lower-case letters with small caps versions” and the abbreviation of the feature, here "smcp" (also see image). You find these descriptions on the Wikipedia page (see link above).

By the way, the current German translation of the implemented features is pretty poor.
Can you please tell me how I can contribute to improving it?
You could also just pass on the attached table to your translation guys. It contains a column with German translations.

If you need help or support for this implementation, you can ask me.
I am not a programmer, but I can help you find out information about the OpenType features, and maybe I can test.


Actual Results:
no bug, therefore unnecessary

Expected Results:
no bug, therefore unnecessary


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Tobias Hemm 2019-12-05 23:50:41 UTC
Created attachment 156340 [details]
Demonstration of Possible Implementation in Character Dialogue
Comment 2 Tobias Hemm 2019-12-05 23:52:07 UTC
Created attachment 156341 [details]
Table with OpenType Features to be Implemented
Comment 3 V Stuart Foote 2019-12-06 05:08:08 UTC
The work referred to was done for bug 58941

Example panels from other applications for handling OpenType features, and some relevant discussion of technical limitations of current Graphite modeled solution implemented with HarfBuzz libs. 

But sure, probably room for additional refinement of the GUI.

@Hieko, should this go through additional UX/Design work-up? Or, just leave it to our sage devs...
Comment 4 Heiko Tietze 2019-12-06 08:23:23 UTC
Wouldn't use a tab for it. At least some of the attributes duplicate what we have on the font effects tab. The best solution is to have all options together, as an ordinary user I don't care about open font, and to disable what doesn't apply.

The four column layout is against the HIG and you may run into trouble with long terms when translated. As this is quite a lot of options we may hide some under expander and use a scrollwindow to show everything in limited space.

Alternatively I could imagine a layout similar to the area fill dialog with buttons that switch between independent options. But "hidden" to pick just one option from the standard font wouldn't be available under open font then (or we have to duplicate the checkbox there).

Last but not least I like the mockup and to improve the usability I suggest to show icons of the effect next to the option.
Comment 5 Tobias Hemm 2019-12-06 11:06:52 UTC
Thanks for your quick replies!

@Stuart: You are right, what was said in bug 58941 is basically what I wanted. There are many great suggestions. I didn’t find that report when I was searching. And furthermore it is almost impossible to follow by now, as it was already said. People got lost in incidentals, and the great suggestions from 2013 (!) were "forgotten".

@Heiko: You say:

>> Wouldn't use a tab for it. At least some of the attributes duplicate what we have on the font effects tab. The best solution is to have all options together ... <<

Right, but there are not really duplicates. Consider that the "Small Caps" in the "Font Effects" tab is not the same as the OpenType feature "Small Caps". Through the LO function "Small Caps" in the "Font Effects", LO creates fake small caps. This is not a real OpenType feature. The "All Capitals" is not really an OpenType feature, too, and could be in one or the other tab – I think that’s not that important. So all options would be togehter in one tab.

One reason why I would group them and leave not-available ones there is that it helps to orient. It is confusing if the features are always in a different place, depending on the font. It’s not that many features after all, as you see in my demonstration image, so I think all features can stay there. As you said, maybe we could work with expanders. There were many great solutions in the bug report 58941.


>> ... as an ordinary user I don't care about open font, and to disable what doesn't apply.<<

I respect your opinion, but I think every user uses different functions, and as you have your range of use, others have theirs. In my opinion, if "Hyperlink", "Font Effects" and "Position" have separate tabs, content-wise "Font Features" deserves one as well. And I, as a more advanced user, don’t care about Hyperlinks for example. There is also a separate tab for "Highlighting". I think it’s superfluous. I’ve never used it. But maybe that’s only my opinion.


>> The four column layout is against the HIG ... <<

Ok, that was just a suggestion. You can make two, three, five or seven columns.


>> As this is quite a lot of options we may hide some under expander and use a scrollwindow to show everything in limited space. <<

Maybe, but I think a separate tab that can be scrolled (if necessary) or the use of expanders would be better, since the features would be quicker accessible, or we use the following ...


>> Alternatively I could imagine a layout similar to the area fill dialog with buttons that switch between independent options. <<

I can imagine that this would be a good solution, too.


>> But "hidden" to pick just one option from the standard font wouldn't be available under open font then (or we have to duplicate the checkbox there). <<

I don’t understand what you mean.
Comment 6 Heiko Tietze 2019-12-06 13:54:10 UTC
(In reply to Tobias Hemm from comment #5)
>> But "hidden", to pick just one option from the standard font, wouldn't be available
> I don’t understand what you mean.

If the two sets are made exclusive available you have access to only one of them and that makes hidden or any other non-openfont specific feature disappear. I prefer an integration and merged functionality with small caps taken from the font or computed if not available.
Comment 7 Tobias Hemm 2019-12-06 17:48:31 UTC
> ... to improve the usability I suggest to show icons of the effect next to the option.
That’s a nice idea, Heiko. I would nevertheless add tooltips on mouse hover, since icons are not always self-explanatory. If you need inspiration for the icons, see for example the following link under the tab "OpenType":
https://www.linotype.com/de/413872/arno-schriftfamilie.html
Comment 8 Tobias Hemm 2019-12-06 17:54:07 UTC
I think I understood you now, Heiko. Is the following what you meant?

> Alternatively I could imagine a layout similar to the "area fill" dialog, with buttons that switch between independent options. But "hidden" – to pick just one option from the standard font [effects] – wouldn't be available under open font [OpenType] then (or we have to duplicate the checkbox there).
I guess, when you say "open font", you mean "OpenType".
It’s partly hard for me to understand you, Heiko. Can you make yourself a little clearer, please?

If you mean the feature "Hidden" from the tab "Font Effects": I don’t care what happens to it. I can’t imagine what one would need it for. And it’s definitely not needed in the OpenType tab. So I think there will be no "two sets", if that’s what you mean, because – as I said – the feature "Small capitals" under "Font Effects" is a fake feature anyway. You can keep it implemented, but I, personally, wouldn’t use it at all. Typographers don’t use it, because it looks ugly. And the feature "All Capitals" can be in either tab. It doesn’t matter, where.

Does that clarify for you, what I mean?


> I prefer an integration and merged functionality with small caps taken from the font or computed if not available.
I wouldn’t do that. At first, this idea sounds practical. But I would clearly segregate these two features and call the feature "Small capitals" in "Font Effects" something like "False Small Caps" or "Scaled Small Caps", because that’s what LibreOffice does – scale the Capitals down.
Comment 9 V Stuart Foote 2019-12-07 01:42:25 UTC
(In reply to Tobias Hemm from comment #8)
>...
> If you mean the feature "Hidden" from the tab "Font Effects": I don’t care
> what happens to it. I can’t imagine what one would need it for. And it’s
> definitely not needed in the OpenType tab. So I think there will be no "two
> sets", if that’s what you mean, because – as I said – the feature "Small
> capitals" under "Font Effects" is a fake feature anyway. You can keep it
> implemented, but I, personally, wouldn’t use it at all. Typographers don’t
> use it, because it looks ugly. And the feature "All Capitals" can be in
> either tab. It doesn’t matter, where.
>...

Reality is that the vast majority of fonts have limited support for OpenType (even fewer with Graphite) smart font features.  Meaning the VCL font 'effects' must remain relevant and viable in LibreOffice ODF document preparation.

And, as implemented we include Graphite/OpenType features into ODF by annotation of font names recorded to style with the feature to be rendered--so one might call that a 'fake feature'. But myself, I am happy to now have the ability to utilize the smart font features with fonts that support them.
Comment 10 Tobias Hemm 2019-12-07 13:28:01 UTC
(In reply to V Stuart Foote from comment #9)

> Reality is that the vast majority of fonts have limited support for OpenType
> (even fewer with Graphite) smart font features.  Meaning the VCL font
> 'effects' must remain relevant and viable in LibreOffice ODF document
> preparation.
They can remain relevant. I just wanted to say that there are no real duplicates, since "hidden" is no OpenType feature and "Small capitals" in fact also isn’t. A re-name of the latter to e.g. "Scaled Small Capitals" would clarify that.


> And, as implemented we include Graphite/OpenType features into ODF by
> annotation of font names recorded to style with the feature to be
> rendered--so one might call that a 'fake feature'. But myself, I am happy to
> now have the ability to utilize the smart font features with fonts that
> support them.
I think there is a misunderstanding, Stuart. What I’ve called a “fake feature” is the feature “Small capitals” from the “Font Effects” tab, whereby LibreOffice scales down capitals to small capitals. This creates fake Small Caps. It would have been clearer if I had called it “Fake Small Caps” instead of a “fake feature”. The feature itself is, of course, real.
As opposed to this, there is an OpenType feature called “Small Caps” (smcp) which accesses forms that were originally drawn by the creator of the typeface. These two features have a clearly different effect, since these two kinds of small caps look absolutely different.
I don’t know how you implement these technically. I just wanted to point out that they are not the same, and therefore they should in any case be segregated. But you can, of course, keep the one that creates fake small caps.
Comment 11 Heiko Tietze 2019-12-08 11:31:42 UTC
(In reply to Tobias Hemm from comment #10)
> These two features have a clearly different effect, since these
> two kinds of small caps look absolutely different.

But whether it's simulated or not wont matter to the Benjamin users [1] who don't care about the advanced options. I'm afraid of confusions between OpenType "font effects" and "simulated" font effects. Your proposed renaming might be a solution if we go with separation, meaning two tabs. If we integrate the features it doesn't matter as non-OpenType fonts would have the same options but simulated (or disabled if not possible). However, I understand the additional effort and could follow the argument that mixed features leads to confusion in the other way for experts.

[1] https://wiki.documentfoundation.org/Design/Guidelines/HIG_foundations#Persona
Comment 12 Tobias Hemm 2019-12-18 13:23:24 UTC
(In reply to Heiko Tietze from comment #11)

We are running in circles, Heiko. What you are afraid of is already reality, because both kinds of Small Caps are already implemented at the moment – in separate tabs. So, if no one complained about confusion yet, just let it be that way if you want... or rename it if you want; it doesn’t matter to me. That’s not my real concern. And, as I’ve already said, these two Small Caps features are the only similar features. So, no need to be afraid of any confusion.

I would suggest now: Leave the "Font Effects" tab as it is at the moment, and implement another tab called "OpenType". Some Benjamins won’t be interested in that, since they don’t know what it means, and they don’t need it. Nothing changes for them. I also don’t come to you and say, “Heiko, I’m so confused by the 'transparency' option, because I don’t know what it’s there for. Please, remove it!” No. I don’t know what it is; I don’t need it; so I ignore it.

So let me summarize what what needs to be done:
– move the already existing dialogue to a separate tab called "OpenType"
– group and order the features in a sensible way
– change some features’ activation mode to drop-downs and bullets (see list)
– keep not available features visible, and grey them out

That’s it. No problems, no duplicates, no confusion.
Comment 13 V Stuart Foote 2019-12-18 15:03:07 UTC
The Character dialog 'Font effects' vs font OT/Graphite smart font attributes exposed in the 'Features...' dialog are completely different implementations.

The font effects are available to essentially any font regardless of the font designers intent. In GUI they are presented in a dialog tab panel positioned in a consistent fashion for all instances.  

There is no linkage to font provided metrics and variants (eg. underline/strikethrough/overline placement, italic/bold variants, sub script/super script position, etc.) all facets of the typography is handled by VCL processing of font metrics while it is rendered to canvas.

And because they are not linked to smart font features or hinting provided by the font the GUI and behavior of 'Font Effects' tab is consistent, for better or worse.

Implementation of Graphite font feature support, and with HarfBuzz its reuse for OpenType, supplements the fixed set of VCL font effects per font. There is no linkage of the smart font features, so they can not interact with the fixed set of effects without major refactoring.

As implemented, the smart font 'Features...' dialog is appropriate in the GUI. Each font exposes its own set of smart font features--Graphite, or OpenType--and that set of features is exposed per font in the dialog via the 'Font' tab. Where the multiple dialogs are available for the three text categories (Western, Asian, and Complex). And, OpenType support actually remains lacking--requiring additional HarfBuzz support.

Any case integrating the two, incorporating smart font features into the Font effects, is not a trivial task--and because so few fonts support more than a couple of smart font features (Graphite or OpenType) a dedicated tab for each is not warranted. Even as additional changes to HarfBuzz expose more of the smart font features, absent major refactoring of font effects, the best handling will remain a separate dialog populated per font with the smart font features it supports available to select. 

On reconsideration, IMHO Tomaž, got this exactly right [1][2] and changes to GUI should be a => WF 

[1] https://gerrit.libreoffice.org/#/c/55892/
[2] https://gerrit.libreoffice.org/#/c/55894/
Comment 14 Heiko Tietze 2019-12-19 07:20:25 UTC
(In reply to Tobias Hemm from comment #12)
> I would suggest now: Leave the "Font Effects" tab as it is at the moment,
> and implement another tab called "OpenType". Some Benjamins won’t be
> interested in that, since they don’t know what it means, and they don’t need
> it.

Unfortunately it's not so simple ;-)

> So let me summarize what what needs to be done:
> – move the already existing dialogue to a separate tab called "OpenType"
> – group and order the features in a sensible way
> – change some features’ activation mode to drop-downs and bullets (see list)
> – keep not available features visible, and grey them out
> 
> That’s it. No problems, no duplicates, no confusion.

By no means the UX input should be discouraging or block your work. We pondered over the various aspects and you made a final decision with the input from UX. Go ahead and let's talk about those details plus sensible defaults later.
Comment 15 Tobias Hemm 2019-12-19 12:33:32 UTC
(In reply to V Stuart Foote from comment #13)
> The Character dialog 'Font effects' vs font OT/Graphite smart font attributes exposed
> in the 'Features...' dialog are completely different implementations.
Exactly!


> The font effects are available to essentially any font regardless of the font designers 
> intent. In GUI they are presented in a dialog tab panel positioned in a consistent fashion
> for all instances.
Right, and you could leave it that way.


> There is no linkage to font provided metrics and variants (eg. underline/strikethrough
> /overline placement, italic/bold variants, sub script/super script position, etc.) all 
> facets of the typography is handled by VCL processing of font metrics while it is
> rendered to canvas.
Yes, there is no linkage. But some metrics you named are not font-provided. LibreOffice creates underline/strikethrough/overline – just as the "Scaled Small Capitals". Bold and italic can be font-provided, but LibreOffice also has the capacity to "fake" it. The same holds true for Subscript and superscript. But leave these things as they are. It’s all OK. My aim was never to link them, but to graphically implement the OpenType features in a sensible and well-accessible way.


> And because they are not linked to smart font features or hinting provided by the font,
> the GUI and behavior of 'Font Effects' tab is consistent, for better or worse.
Yes, just leave this tab as it is.


> Implementation of Graphite font feature support, and with HarfBuzz its reuse for OpenType,
> supplements the fixed set of VCL font effects per font. There is no linkage of the smart
> font features, so they can not interact with the fixed set of effects without major
> refactoring.
Exactly, Stuart! They are not linked; and nobody wants them to be linked. Just leave the font effects as they are. No refactoring needed!


> Any case integrating the two, incorporating smart font features into the Font effects,
> is not a trivial task ...
I guess this sentence is an answer to what Heiko keeps saying. Because, to repeat again, incorporating smart font features into the Font effects is and was never my concern.


> ... and because so few fonts support more than a couple of smart font features (Graphite
> or OpenType) a dedicated tab for each is not warranted. Even as additional changes to
> HarfBuzz expose more of the smart font features, absent major refactoring of font effects,
> the best handling will remain a separate dialog populated per font with the smart font
> features it supports available to select.
I don’t understand your constant relating this enhancement suggestion to the font effects. If Heiko wants to have a linking of these two things, he can file another report, because it has nothing to do with what I want. What I want – and what is definitely sensible and justified – can be seen in the four points of my summary. But, if I understand you correctly, you don’t see it the way I do. So, as these four points were my reasons to file this report, and since you virtually decline making changes in this regard, after endless beating about the bush we can consider my enhancement attempt cancelled, right?
Comment 16 V Stuart Foote 2019-12-19 15:50:39 UTC
(In reply to Tobias Hemm from comment #15)
> ...
> I don’t understand your constant relating this enhancement suggestion to the
> font effects. If Heiko wants to have a linking of these two things, he can
> file another report, because it has nothing to do with what I want. What I
> want – and what is definitely sensible and justified – can be seen in the
> four points of my summary. But, if I understand you correctly, you don’t see
> it the way I do. So, as these four points were my reasons to file this
> report, and since you virtually decline making changes in this regard, after
> endless beating about the bush we can consider my enhancement attempt
> cancelled, right?

No, only Heiko's thoughts on integrating 'smart font' features into the font effects tabs is WONTFIX, while your suggestion of a dedicated tab of OpenType features shows an incomplete grasp of how LO handles 'smart font' features--currently just Graphite and OpenType.

Tomaž's implementation of the 'FontFeaturesDialog.cxx' correctly handles the set of Graphite or OpenType features as extracted from each font, and would handle Apple Advanced Type (AAT) should that be restored. Its GUI placement on the 'Character...' dialog's 'Font' tab, colocated with each font choice (Western, Asian (CJK), or Complex) is the most efficient and frankly appropriate choice.

Yes, the dialog's GUI could be tweaked, but not at all clear that a table listing all Graphite/OpenType (or even AAT) features, or individual tables by fonttype, would make the UX any better.

As is, the dialog is populated with just the smart font features applicable to (extracted from) the selected font--and is exposed where that font selection is being made.  When populated in the dialog those features are being exposed as checkboxes (boolean), or as droplist selections (enum).

The core of your request of moving the smart font "Features..." dialog onto a Tab of its own makes no sense in context where multiple font selections are made from the 'Font' tab. The button action launching the features dialog belongs with the font selection, as it is now.

At some point, a more complete re-implementation of 'smart font' features might occur--along with mechanism(s) to record those features into ODF containers.  And that refactoring would likely include rework of the Font Effects tab. Not the scope here.

Here, issue should be with the dialog itself. E.g. impose consistent ordering of the boolean/enum features, provide icon representation (beyond current feature preview provided), etc.

In other words, polish the current dialog as applicable to each font by its supported smart font technology. The dialog could include placeholders for unsupported smart font features--but kind of feel that would be a lot of visual noise.  The concise dialog now is suited to task for our non-Benjamin users that would use the font features.
Comment 17 Tobias Hemm 2019-12-19 18:17:56 UTC
(In reply to V Stuart Foote from comment #16)

I understand. It doesn’t make sense to implement this with another tab, if there is more than one possible 'font' choice. Than this is off the table.

But anyway, I’m out here. I am not willing to endlessly discuss this and try to convince you of something you don’t care about anyway. I’ve done what I could: I’ve created images and tables, I’ve explained and clarified. If you are still not of the opinion that my mockup is better that the current stew, I don’t know how to help you. At some point it’s enough. I’m not willing to repeat this for decades. Do what I suggested ... or let it be. It’s not important enough for me to continue from here. If you need further information, just see my former comments.

Thanks for your time. Have a nice of the latter.
Comment 18 ⁨خالد حسني⁩ 2022-08-24 06:40:25 UTC
I appreciate the effort, but I don’t think the proposed design is implementable given the current architecture of the font features dialog and LibreOffice fonts in general.

I made a few enhancements to the dialogue on top of other enchantment since this issue was open, and I think it is in a usable state now. The UX can be improved, but I think this is a larger effort that needs UX and dev coordination.

Closing as WONTFIX, but anyone feel free to re-open if there is new work/proposal.