[Libreoffice-bugs] [Bug 129219] Further refinement of OpenType/Graphite Font features in the “Character” dialogue

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=129219

--- Comment #16 from V Stuart Foote <vstuart.foote at utsa.edu> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191219/324775a8/attachment-0001.htm>