Created attachment 202020 [details] Font features dialog for Gentium Plus, LO 26.2 nightly Writer, GTK3 The font features dialog has (potentially) a large number of options regarding font features. The screenshot will give an example (with the Gentium Plus font). Many, if not most, of these options are presented with a drop-down list box, while only having two options, often differing by a single word. Examples: +-------------------+ Capital-H stroke alternate: [Horizontal Stroke v] +-------------------+ |Vertical Stroke || +-------------------+ +------------+ Small p-hook alternative: [Left hook v] +------------+ |Right hook || +------------+ And for some fonts, and some options, the options are "None" and "1" or "0" and "1". But I'll open a separate bug about those. I find drop-down list-boxes to be "heavier" UI elements than a radio button pair, and in a dialog which is already rather cluttered, we should probably avoid them; especially when they require repeating some text. I would suggest we replace these controls with pairs of radio buttons. Examples: Capital-H stroke: (*) Horizontal ( ) Vertical Small p-hook direction: (*) Left ( ) Right
Inflation of tickets, IMO. => DUP
(In reply to Heiko Tietze from comment #1) > Inflation of tickets, IMO. => DUP But the implementation requires something different: For 167687, the challenge is to better classify features as toggles, better than how we classify them now. For this bug, the challenge is to change the code generating the UI so as to generate radio buttons instead of a drop-down menu. (and in both bugs there need to be label rephrasing) So, it is conceivable that this bug will be resolved without touching the other one and vice versa.
Real issue is how to extract each font's full set of Smart Font (SF) features, and then how to represent those features in a UI to make feature selections. Followed by applying the feature, and being able to identifying a font feature that is assigned to text runs in document view, and ultimately when recorded into the ODF (issues of see also bug 166079). Problem already is that most Graphite based SF, and a growing set of OTF fonts, have extensive SF stylistic and alternative forms embedded internal to the font. Some are so numerous they already overwhelm the font 'Features...' dialog. For example look at the 'Features...' dialog for the Graphite SF enhanced "Linux Biolinum G" or "Linux Libertine G/Linux Libertine Display G" that László had published. Or any of the "Libertinus" OTF SF family Khaled had worked on. But that is the nature of the SF features, there can be a lot and there is no good way to "lighten" the representation of them in UI for selection or review. More so if we were to start labeling those with "binary" selections by radio button/checkbox. While those with multiple choices per element *ARE* best represented via listbox (the font designer is responsible for annotating each SF as appropriate). And then once selected and applied, currently each SF is DF applied to a text run and exposed to UI only in the Font Name widget resident on the Formatting tb (again bug 166079). Personally, I think the current dialog and Graphite/OTF Smart Font handling that László, Martin, Tomaž, and Khaled cobbled together handles things pretty well. The current 'Features...' dialog was mainly Tomaž effort, so I'd like his and Khaled's input here for sure. Trying to identify font features that are binary as opposed to those with only two alternatives (i.e. have None, Aaa in a listbox) to support addition of a few checkbox/rb in the dialog is not going to improve things very much. More extensive refactoring of the UI is going to be needed, should work on bug 166079 ever happen. Absent that the 'Features...' dialog UI is suitable to task of handling SF features. IMHO => WF
(In reply to V Stuart Foote from comment #3) > The current 'Features...' dialog was mainly Tomaž effort for bug 58941
(In reply to V Stuart Foote from comment #3) > Real issue is how to extract each font's full set of Smart Font (SF) > features, and then how to represent those features in a UI to make feature > selections. If you're saying, that we are currently not extracting the full set of features, then - please file that as a separate bug. That is not the "real issue" here. This bug is about what we do with non-toggle, non-numeric features we already extract. Currently we use drop-down listboxes for them, but we should prefer radio buttons, in many more, and perhaps nearly all, cases (which are not in fact boolean yes/no or on/off toggles). > Problem already is that most Graphite based SF, and a growing set of OTF > fonts, have extensive SF stylistic and alternative forms embedded internal > to the font. Some are so numerous they already overwhelm the font > 'Features...' dialog. > That would be another bug, related but separate from this one. > More extensive refactoring of the UI is going to be needed, should work on > bug 166079 ever happen. Absent that the 'Features...' dialog UI is suitable > to task of handling SF features. This is marked as an _enhancement_, not a bug. Naturally, a drop-down list box works as does a radio button group. Also, if the UI is completely revamped - this bug may become irrelevant. But for now, we may effect a concrete improvement which should not be difficult. In fact, I wonder if it might not be an easy hack.