Bug 72944 - Enhance handling of font varieties within families (weight, width, slope)
Summary: Enhance handling of font varieties within families (weight, width, slope)
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
: 72938 (view as bug list)
Depends on:
Blocks: Font-List
  Show dependency treegraph
 
Reported: 2013-12-21 04:47 UTC by dhpublic
Modified: 2023-08-03 16:44 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dhpublic 2013-12-21 04:47:57 UTC
Greetings,

We're trying to provide helpful feedback about LibreOffice Writer 4.1.3.2 under MS Windows. This bug reporting system is NOT making that easy. We're not trying to report a "bug". We're trying to draw your attention to a deficiency in Writer that hurts the program and prevents us from recommending it to our clients.

We arrived at this bug report webpage by clicking on the "Send Feedback..." command in the Help menu of Writer. Why does it take us to a "Bug" report form? It doesn't make sense. We should have arrived at a "Feedback" page on your website---not a "Bug" reporting page. If all you accept are bug reports, then the command in the Writer's Help menu should have been worded: "Report a Bug...".

Enough of that! Here's the purpose we are trying to communicate with you:

We're running into problems because of the antiquated font support in LibreOffice Writer 4.1.3.2 for MS Windows. (We're running Windows 7 Ultra 64-bit on our computers.)

The problems are pretty basic: Writer does not recognize the family name and key parameters of a font. As such, Writer cannot support a full range of fonts within a family but is stuck in the stone age of only two weights and two slopes: regular, regular italic, bold and bold italic. We expect more from word processing software today.

For example, a staple sans serif font in our work is Helvetica. This is a famously common typeface that was designed by Linotype and which Microsoft ape'd with its Arial version. We use four weights (light, medium, bold, black) and two widths (normal, condensed), all with both plain and italic (oblique) slopes. This should give us 16 choices under the "Helvetica" family:

Helvetica
---------------------------
· Condensed Light
· Condensed Light Oblique
· Light
· Light Oblique
· Condensed Medium
· Condensed Medium Oblique
· Medium
· Medium Oblique
· Condensed Bold
· Condensed Bold Oblique
· Bold
· Bold Oblique
· Condensed Black
· Condensed Black Oblique
· Black
· Black Oblique

Yet this is frankensteined under Writer into fractured Helvetica, Helvetica Black, Helvetica Black Cond, Helvetica Cond, Helvetica Light and Helvetica Light Cond pseudo families. Why? Because Writer does not appear to read or use the font family name to see that all of these fonts are members of the same Helvetica family. Nor does it gather the correct weight, width and slope parameters from each font so they can be properly organized in Writer's font list.

Consider another example: the VAG Rounded typeface. There are four weights commonly provided: thin, light, bold and black. To select the bold weight under Writer, you have to select the thin weight and turn on the program's "bold" attribute. But to select the black weight you must select the light weight and, again, turn on the program's "bold" attribute. What a muddled mess! How would someone unfamiliar with this font family know how to choose "bold" in order to select the black weight?

Again, what Writer fails to do is look inside the font to see that all of these fonts are members of the same family (VAG Rounded) and have four different weights (thin, light, bold, black) with no sloped members (no italics). It should be presented like this:

VAG Rounded
-----------
· Thin
· Light
· Bold
· Black

But instead it is presented like this:

VAG Rounded Th
--------------
· Normal      (actually, Thin)
· Italic      (doesn't exist)
· Bold        (really is Bold---the only accurate one)
· Bold Italic (doesn't exist)

VAG Rounded Lt
--------------
· Normal      (actually, Light)
· Italic      (doesn't exist)
· Bold        (actually, Black)
· Bold Italic (doesn't exist)

Fixing this will require that Writer obtain the full parameters for each font and correctly display the parameters in its user interface so the user can select the font they truly want without guesswork or trial and error.

One way to display the parameters and facilitate user selection is to provide the user with two lists. The first list contains the font family name. The second list contains the available combinations of width, weight and slope for the selected font family in the first list. 

List 1 - Font Family Name
In my original Helvetica example, you would select "Helvetica" from the first list. This list is ordered alphabetically with one caveat: company or font foundary names are usually ignored. For example, "ITC Century Book" would be listed with the C's because the company initials "ITC" would be ignored. This is helpful because you sometimes have the same font supplied from multiple companies and what the user is looking for is "Century Book" and is frustrated when he/she can't find it because it's got a company name prefaced to it that pushes it into an unexpected location in the font list. Naturally, in order to ignore font company and foundary names, you'll need to create a database of them and include this with Writer. It would be really nice if the company name were displayed in a subdued fashion (perhaps a shade of grey) so the font family name would command the attention of the user.

List 2 - Width, Weight, Slope
Returning to my earlier Helvetica example, you would next select one of the 16 choices I listed above from the second list. Instead of an alphabetical order, the second list is usually ordered as follows: First the fonts are sorted by weight from the thinnest at the top to the heaviest at the bottom. Then the fonts within each weight are sorted by width from the narrowest at the top to the widest at the bottom.

If a font family doesn't include a "bold" weight or an "italic" slope, then these options would not be provided. For this reason, "bold" and "italic" buttons or check boxes are obsolete. However, some savvy programs still provide them anyway and modify the font to create a faux bold and/or faux italic when these versions are not specifically provided within the font family. If you choose to do this and fake a bold weight and/or an italic slope, then it should be clear to the user that this is what is being done.

If you want to see a good example of how fonts are selected, just look at most any Adobe program (InDesign, Illustrator, Photoshop, etc.). If you want to see an excellent example of how font weights and slopes can be faked, see FontLab's excellent tool: TransType 4.0.

Here are the standard values accepted today for the font weight, width and slope parameters:

Weight (from thinnest to thickest):
-----------------------------------
· Thin
· Extra Light
· Light
· Semi Light
· Regular
· News
· Medium
· Semi Bold
· Bold
· Extra Bold
· Heavy
· Black
· Extra Black

Width (from narrowest to widest):
---------------------------------
· Ultra Condensed
· Extra Condensed
· Condensed
· Semi Condensed
· Normal
· Semi Expanded
· Expanded
· Extra Expanded
· Ultra Expanded

Slope:
---------
· Plain
· Italic
· Oblique

We're excited about the efforts that the Open Source community have made with LibreOffice and we would like to be able to use and recommend it to more clients. But, as it stands now, these font problems strike at the heart of what a program like Writer is supposed to do: produce good-looking pages of text. At the center of this is the way the user interface enables users to select fonts. Many of the other excellent features of the program are diminished because of fundamental issues with font support and selection in Writer.

We strongly encourage those contributing to the development of LibreOffice to make it a top priority to bring font support and selection in Writer up to current industry standards. Once this is mastered in Writer, it should be duplicated throughout the rest of the programs in LibreOffice.

If you find the nuances and terminology of this subject unfamiliar, then we recommend that you download and read some of the user manuals from a typface software tool maker like FontLab. They let prospective buyers, download their manuals for free (as pdf files) and you'll find they contain a wealth of information. The manual for the aforementioned TransType 4.0 tool would be a good place for a beginner to start. Then try the manuals to their font creation tools like Fontographer 5.2 or FontLab Studio 5.2.

Kind regards,

dhpublic

Operating System: Windows 7
Version: 4.1.3.2 release
Comment 1 dhpublic 2013-12-21 04:53:30 UTC
*** Bug 72938 has been marked as a duplicate of this bug. ***
Comment 2 Jean-Baptiste Faure 2013-12-21 15:16:25 UTC
Not a bug but an enhancement.

Patches are welcome.

Best regards. JBF
Comment 3 Jean-Baptiste Faure 2013-12-21 15:19:25 UTC
Offensive words in the summary are useless.

Best regards. JBF
Comment 4 Adolfo Jayme Barrientos 2013-12-22 12:36:28 UTC

*** This bug has been marked as a duplicate of bug 69881 ***
Comment 5 Jean-Baptiste Faure 2013-12-22 22:45:31 UTC
(In reply to comment #4)
> 
> *** This bug has been marked as a duplicate of bug 69881 ***

Really ? this enhancement is described for MS-Windows and bug 69881 has been reported against MacOS X.

Best regards. JBF
Comment 6 Yousuf Philips (jay) (retired) 2014-06-29 22:14:03 UTC
This is a feature request like Jean-Baptiste mentioned and not a duplicate.
Comment 7 beimaginativeegroup 2014-12-21 15:57:39 UTC
Should it be set as NEW?
Comment 8 Alex Thurgood 2015-01-03 17:38:27 UTC Comment hidden (no-value)
Comment 9 Robinson Tryon (qubit) 2016-08-25 05:26:47 UTC Comment hidden (obsolete)
Comment 10 Thomas Linard 2018-01-05 09:55:07 UTC Comment hidden (obsolete)
Comment 11 Thomas Linard 2018-01-23 21:44:04 UTC Comment hidden (obsolete)
Comment 12 Aron Budea 2018-01-23 22:54:42 UTC Comment hidden (obsolete)
Comment 13 Thomas Linard 2018-01-30 13:51:02 UTC
With LibreOffice 6.x, the minimum supported Windows version is now Windows 7 SP1. So, LibreOffice could use DirectWrite to access styles: "The DirectWrite font model follows the common typographic practice of supporting any number of weights, styles, and stretches in the same font family. This model, the same model followed by WPF and CSS, specifies that fonts differing only in weight (bold, light, and so on), style (upright, italic, or oblique) or stretch (narrow, condensed, wide, and so on) are considered to be members of a single font family."
https://msdn.microsoft.com/en-us/library/windows/desktop/dd371554
Comment 14 V Stuart Foote 2018-01-30 14:41:25 UTC
So reasonably a subtask of bug 107521 for our DirectWrite implementation, or some future implementation of FreeType, killing GDI.
Comment 15 Volga 2019-08-23 17:16:49 UTC
This bug affects Source Han Serif. Source Han Serif has 7 font weights, including:
- ExtraLight
- Light
- Regular
- Medium
- SemiBold
- Bold
- Heavy

However, in LibreOffice, only Regular and Bold fonts can be treated as font weight, because they are style-linked, others are treated as individual fonts, because they are not style-linked. Reproduced with:
版本: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU 线程: 4; 操作系统: Windows 10.0; UI 渲染: 默认; VCL: win; 
区域语言: zh-CN (zh_CN); UI 语言: zh-CN
Calc: CL

In Inkscape, all of them can be switched as font weight normally while you insert a text into document even if some of them don’t have style-link. Reproduced with:
Inkscape 0.92.4 (5da689c313, 2019-01-14)

So it would be nice if LibreOffice can break out such limitations to handle more weights, styles and stretches.
Comment 16 João Paulo 2020-09-28 21:59:30 UTC
(In reply to Thomas Linard from comment #13)
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd371554

I asked Microsoft through Feedback Hub for some API to handle fonts as organized as Control Panel\Fonts organize them on Windows (just as the bug reporter said) and their response was:

"Thanks for the feedback. EnumFontFamiliesEx does enumerate the variants - have you looked at that?  Empty facename gets the variants, then you can call it again with the facename you want more info about." "feedback-hub:?contextid=950&feedbackid=d5881e15-3575-4c17-84c9-5e0d733fae7a&form=1&src=1"

I searched this API and found it has two versions (EnumFontFamiliesExA and EnumFontFamiliesExW) at "https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-enumfontfamiliesexw" and "https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-enumfontfamiliesexa".

Also, I want to say that the MSDN page moved to "https://docs.microsoft.com/pt-br/windows/win32/directwrite/introducing-directwrite", just in case the redirection stops working one day.
Comment 17 Richard 2022-08-05 14:26:09 UTC
This is marked as a Windows issue, but the identical problem is present in Linux.
Comment 18 Eyal Rozenberg 2022-09-30 10:16:24 UTC
We should really get rid of the silly 2x2 space of variants within a family. I really hope this gets prioritized soon.
Comment 19 ⁨خالد حسني⁩ 2023-08-03 16:44:10 UTC
We only support R/B/I/BI font family model for various legacy and compatibility reasons, and that is why families with styles other than these four get handles as separate font families. This is intentional and not a bug.

Furthermore, on Windows GDI API (which we use to list installed fonts) supports only this model, so we get split families from it and we would need to inspect font files individually, which is would be very slow.