Dispite LibreOffice support Graphite engine natively, there is some difficult to make font rendering by using Graphite features. Two extensions for Graphite feature are invalid: Typography toolbar extension cannot utilize well in LibreOffice 4+, and “Graphite OpenOffice” now is cannot download from ThanLwinSoft.org. Even if input extended font name in Format toolbar (eg. “Linux Libertine G:smcp=1” for small caps) can use Graphite font features tags to be passed to the font, it is still difficult for someone whose typography kownleadge is deficiency. So I require the official GUI to operating some special font rendering by Graphite, and add these interfaces into Font dialog.
This file have bad rendering, dispite I installed Typography toolbar:
UI enhancement request -> handing over to the Guardians of the UX Galaxy
Status -> NEW
Component -> ux-advise
Severity -> enhancement
(In reply to General Kutuzov from comment #1)
> This file have bad rendering, dispite I installed Typography toolbar:
You can compare with this file:
By the way, I hope these interfaces can also be available for OpenType and Apple Advanced Typography.
It would be nice to hear from someone on the dev team who has knowledge of fonts to look into this so that UX can look into how best to implement it in the font dialog.
(In reply to Jay Philips from comment #5)
> It would be nice to hear from someone on the dev team who has knowledge of
> fonts to look into this so that UX can look into how best to implement it in
> the font dialog.
As a user, IMHO, all basic features from graphite (or even OpenType) like, for example small caps or sub and superscripts should work directly from the simple toolbar buttons if the font provides those features.
Duplicate funcions that look different with each other when applied (I mean, small caps from Graphite and the one provided by LibO from Character dialog) create confusion. Furthermore, small caps features from graphite does look much better than the generated by LibO. It would be nice if a user who use to use, e.g., Times New Roman and uses to apply any of these formating options from the toolbar buttons, and start to use Libertine because anything, he could continue to format his documents in the same way he has been doing so far.
Well, I am using LO 18.104.22.168 and I got a ODT file in comment #1, many font features in this file rendering proper, but some of them still looks badly (such as itlc). BTW I hope all the feature IDs can be available for OT and AAT fonts.
Nothing to do with UI or BASIC, component for typography support is the graphics stack...
@László, Khaled, *
Can you comment on where things are now across the project, and what really needs to be addressed for Graphite support--relative to all other Unicode typography and text stack support.
Also, what is the state of our UI for typogrpahy controls for use of Graphite, HarfBuzz/Pango/OpenType Layout, Uniscribe or even Apple Advanced Type. Seems much of this now is "automagic"--and based on user's language selections.
Does the UX gain anything by exposing more typography configuration choices to the UI? At the least, is there a better UI design for entering the formatting of font layout?
(In reply to V Stuart Foote from comment #9)
> @László, Khaled, *
> Can you comment on where things are now across the project, and what really
> needs to be addressed for Graphite support--relative to all other Unicode
> typography and text stack support.
Not sure what is being asked here. But anyway, currently Graphite support is not enabled on Mac OS X, and with the current state of LibreOffice’s low level text layout, it is probably not a simple task.
> Also, what is the state of our UI for typogrpahy controls for use of
> Graphite, HarfBuzz/Pango/OpenType Layout, Uniscribe or even Apple Advanced
> Type. Seems much of this now is "automagic"--and based on user's language
We have no UI whatsoever, nor ODF support, to control smart font features. Graphite features are enabled using a “hack” that appends a feature string to the font name to be parsed internally, but that is a non-standard behaviour not part of the ODF spec and is unlikely to be supported by any ODF implementation, bug 58941 is about better handling of this at the format level.
> Does the UX gain anything by exposing more typography configuration choices
> to the UI? At the least, is there a better UI design for entering the
> formatting of font layout?
Again, I’m not sure what is being asked here.
Migrating Whiteboard tags to Keywords: (needsDevEval)