LWN: Comments on "OpenType 1.8 and style attributes"

OpenType 1.8 and style attributes

n8willis — Sun, 02 Oct 2016 11:09:46 +0000

But "Bold buttons" in document editing applications are already vague as far as what their expected outcome will be. Users can select a snippet that has multiple fonts (of different formats and that may or may not have a Bold variant currently installed on the system), has some text that's already bold, and even includes some non-text content like images. Some of the text might be in a font that has multiple weight levels available. What happens when the button is then pressed will vary, basically depending on the programmer's whim. So OpenType 1.8 changes nothing there.

By and large, standard document editors are not likely to want or to need to know whether all the various font instances available to the text renderer come from separate files or a single file. Certain graphic-design apps or GUI engines might. But for everything else, that's something probably best mediated by a lower-level system library, like Fontconfig, that can keep track of what options are associated with a particular font/family/superfamily "human readable" name.

Nate

OpenType 1.8 and style attributes

bokr — Sun, 02 Oct 2016 08:07:42 +0000

I'm wondering if anyone classifies the OCR-ability of other-than-OCR fonts,
given the common practice of governemnts and businesses of scanning documents
for archiving, or programmatically producing compatible files even from simple text.

It might be good to be able to choose fonts based on expected error rates in
OCR say in a Richter scale style of errors per 10^n where n could be two significant
figures, like 10^6.3 would be about one error in two million (UIAM) for OCR attribute 6.3.

Without OCR, character-based searches are not going to happen except maybe
of images' textual metadata. Of course legislators et al realize this?

OpenType 1.8 and style attributes

JanC_ — Fri, 30 Sep 2016 00:22:09 +0000

Considering that the meaning of “axis values” is also font-specific AFAICT, the only reasonable answer is to do what each font defines as “Bold”.

I'm pretty sure that's also what users expect to happen (you don't want to explain why the same font looks different in bold depending on what font the neighbour text uses).

OpenType 1.8 and style attributes

nim-nim — Thu, 29 Sep 2016 09:15:33 +0000

And, of course, even assuming all the axis are properly documented in font metadata, the fun part is the UI exposed to users to select along those axis.

For that matter since the new specification lets two fonts use the same human label for different axis values, what happens when the user selects a run of text composed of different fonts and press the bold button? Is the software supposed to apply the same axis value to all fonts (favouring consistency), or select for each font the value associated to the "Bold" label, even though those values are different?