Libre Writer typeface/font rendering in Linux

[PeterSergej]

Scope of my query: to evaluate Libre Office as cross-platform replacement for alternate productivity software.

Query summary: Is there a bug in the Libre Office font rendering engine for Linux? (more contextualized question(s) below the test scenarios that follow.)

Looking at the first screenshot below, taken from Libre Writer running under Linux, the same line of text is shown in New Century Schoolbook Lt Std repeated with bold applied (line two), and then with bold applied and all alternatives selected in character formatting (line three).

You will note that line two offers a rendering that is completely unacceptable in any use case. And line three claims to be New Century Schoolbok (see the typeface selection caret in the toolbar while line three is selected), but is plainly another typeface altogether. (Some other typefaces are similarly garbled, but let’s stick to this one for simplicity’s sake.)

The New Century Schoolbok typeface is installed as OTF in the Roman, italic, bold, and bold italic font variants on the following build:

Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-GB (en_AU.UTF-8); UI: en-GB
Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded

Running the same scenario in Windows 10 offers quite a different result (the only change here is that the third line had bold and underline formatting applied). See second screenshot below.

Again, the typeface is installed as OTF with the same font variations as above.

Version: 7.4.1.2 (x64) / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: CL

Detailed questions: If the typeface cannot be rendered in Writer under Linux in anything other than its Roman iteration, does that mean this version of Writer has a crippled font rendering engine? As such, is this a bug?

Or is this a specific Linux/Libre Linux implementation flaw?

Please do not promote the idea that font substitution is an answer; that would be to suggest that user functionality should be subject to programming errors or limitations. My evaluation of Libre Office must return an unfavourable recommendation to clients if programming or scope limitations are addressed by imposing an aesthetic determinism about typeface interchangeability.

[anon87010807]

Where did you get the fonts? Are you sure that the font files aren’t damaged?

[LeroyG]

The font name in the second screenshot is shown italicized, so, maybe it is not New Century Schlbk LT Std.

Schlbk or Schoolbook?

[PeterSergej]

I tried the same test in Scribus (same Linux machine) and the same font renders perfectly. I believe the fault is in Libre Office/Writer font rendering.

[PeterSergej]

How Libre Office renders selected font names is another issue, but it is the same font.

[anon87010807]

Consider filing a bug report at the proper instance. See How to Report Bugs in LibreOffice - The Document Foundation Wiki. The Ask site is a place where users help users. And while some developers visit it, you can’t count on them noticing your question.

[PeterSergej]

Appreciate your comment. I thought I would try here first to see whether I had missed something experienced users knew how to fix.

[anon87010807]

The experienced users will still have to be able to reproduce the behavior (and the developers too - if they can’t reproduce what you describe, they won’t be able to fix it) - that’s why I asked where you got the fonts. It would have been better to mention that Scribus displays the fonts correctly in your original post.

[PeterSergej]

It is an OTF licensed from Adobe. The same problem occurs with at least one other Adobe OTF (Helvetica Std). However, if it were the font type or vendor that is the problem, would this problem not also occur in the Windows version of Libre Office?

I did the Scribus test to eliminate Linux as the problem rather than to test for file corruption, which I did via checksum. However, I did not consider problems with font files or programs other than Libre Office as germane.

[ajlittoz]

Since this is very unusual, please attach the sample file corresponding to your Ubuntu screenshot. The fact that the pilcrow and spaces are not rendered as expected in the second line suggests that some weird formatting is active. Apparently, you have customised the UI with toolbars and I fear your test is plagued with adverse direct formatting.

[PeterSergej]

A font-embedded Libre Writer document comes in at 42MB, exceeding file sizes for attachments here ten times over. Attaching a document without font embedding relies on you having the licensed Adobe New Century Schoolbok LT Std OTF typeface installed on your own machine. Do you?

The font embedded document will be here for 36 hours: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

Your comments about the customized UI, and direct formatting baffle me. If these features of Libre Office destroy its capacity to render fonts, these would be separate and considerably greater technical problems.

[mikekaganski]

Many issues with the question itself, and with the provided sample.

1. Your first screenshot shows “New Century Schoolbook LT Std” as installed font (its name is not italicized in the toolbar control). However, the screenshot from Windows shows “NewCenturySchlbk LT Std” name, and it is italicized. The fonts themselves have the latter name internally (it’s shown by both Windows font preview, and Ubuntu font preview); it’s unclear how they should be called in reality.
2. The respective fonts that you embedded are TTF fonts, while you wrote about OTF. Is this correct? Maybe you have several copies of same-name fonts installed on your system(s), that create some havoc depending on which gets actually used?
3. These fonts disallow using when embedded; so despite embedding, they will not be used on target systems. Note tdf#145967 that wants to show a warning when that happens.
4. When tried to install those fonts on my Ubuntu system, pressing Install button in the font preview tool, for all but one, the operation worked for a second, and then showed the button active again. For the last file, when the button was pressed, it worked and then got replaced by the non-clickable label “Installed”. It’s interesting, if the other fonts couldn’t be installed - and if that was actually some font issue, or some Linux issue?

I didn’t look deeper than that cursory test.

[PeterSergej]

The abbreviations are Libre’s. See my screenshot of the Linux font viewer later on this thread.

Not sure what you mean by ‘shown italicized’, but the screenshot may have captured the last used direct formatting. You can see the actual italicized font renders fine.

[PeterSergej]

Focusing too much on the last used direct formatting option should not distract you from how the fonts are rendered in the screenshot. There are further screenshots in this morning’s answer to ajilttoz. That answer also contains a screenshot of the installed fonts as seen in the Linux font viewer.

The embedded fonts are not Truetypes, unless Libre Office converts them as such. I don’t have any Truteypes with any variation of the name New Century Schoolbook. All the typeface fonts are OTF (checked, double checked, and triple checked in the font viewer and its info section).

The issue of font file or Linux issue seems resolved in the negative by the successful font rendering in GIMP and Scribus (on the same system as the Libre Writer tests). Scribus, in fact, lists all font variants as separate type formatting options, as any decent DTP package should.

[mikekaganski]

@PeterSergej

Not sure what you mean by ‘shown italicized’

[ajlittoz]

First, an answer to your remark in your last comment:

@PeterSergej

Your comments about the customized UI, and direct formatting baffle me. If these features of Libre Office destroy its capacity to render fonts, these would be separate and considerably greater technical problems.

The many toolbars provided with the GUI (as an inheritance from M$ Word) encourage to direct format documents instead of styling because the “actions” are readily available. And I feared some unexpected effect of direct formatting.

== Analysis of your sample file ==

Initially the embedded fonts were not taken into account on my machine (Fedora Linux 36 under KDE Plasma desktop). Once installed, your sample file displayed as intended, except the fifth (last) line, showing a substituted sans serif font.

Looking at the underlying ODF XML, I didn’t see any unusual formatting. It is standard direct formatting.

However, looking in details at the font characteristics, I discovered that the bold variant was named Fractions Bold. This added to the fact that the icon for the font on the desktop shows only “12” instead of “Aa”.

If I remove the :aalt feature tag from the formatting, the last line displays the same as the second one with the underline added.

IMHO, the New Century Schoolbook LT Std family is made of many font files, each covering only a part of Unicode. You should try to find the one corresponding to Bold, not only Fractions Bold.

Since I see apparently correctly the second line (bold) despite the missing Bold variant means that my font renderer has substituted some other font (or perhaps has synthesised a bold variant from the Roman one. But it was unable to do the same on the last line because of the :aalt request.

EDIT

After looking at the font with FontForge, I confirm that file *Font_New_Century_Schoolbook_LT_Std_2.ttf (the one for the Fractions Bold variant) contains only 118 glyphs over the Basic Multilingual Plane: digits, space, percent and solidus (slash), fractions, special symbols like per-thousands and 86 combined/offset digits for arbitrary fractions.

Consequently, it is absolutely normal that font substitution occurs when requesting missing glyphs.

To fix your problem, find the bold font file. You can keep the specialised Fractions Bold but the Bold variant is necessary.

[PeterSergej]

Thank you for being quite so thorough in examing the file. Nevertheless, your analysis adds complexity rather than eliminating it (FontForge).

It was always obvious to me that the typeface is comprised of multiple files, as most professionally designed typefaces are. This is to provide for designed rather than simulated typeface font variants; instead of faux bold and italic applied on the fly, these variations become their own glyph sets. (see screenshot below).

Above: Linux font viewer showing the New Century Schoolbook LT Std OTF font family.

Above: Linux font viewer showing the specifications for the New Century Schoolbook LT Std bold font variant. The glyph count is exactly the same as for the ‘Roman’ (normal) font.

It is also quite normal for Open Type Fonts to be handled this way by common software: multiple files are taken as a single typeface with font variants not shown in the sofware typeface selection options. The problem is not me or some user user ‘locating’ the bold font of New Century Schoolbook LT Std, it is working out why Libre Office/Writer cannot do that in Linux, while GIMP and Scribus can, and Libre Office/Writer running under Windows can too.

Above: GIMP renders the typeface font variants just fine.

Above: Scribus also has no problem rendering the bold font.

As for the ‘all alternatives’ variant, there is no New Century Schoolbook truetype (ttf) font on any of my systems, but further feedback in other forums convinces me that selecting the font property of ‘all variants’ does in fact invite typeface substitution. Looking again at the typeface name itself, suffixed with Std, means it has only standard variants, not an extended set (as in Noto, for example), and looking at the first screenshot above, it becomes clear what those variants are.

Given all these factors, I have opened a bug report in Libre’s Bugzilla tracker.

I thank you again for your analysis, but on this occasion it does not offer a viable resolution.

[ajlittoz]

I see in the first screenshot that you indeed have the bold variant while your sample file only embeds the Fraction Bold one. The lack of the bold variant explains the behaviour on my machine (except for :aalt). And I’d bet that some substitution or synthesis-on-the-fly occurred because I was surprised to see that the bold and non-bold lines (first and second lines) has exactly the same width! The bold line looked condensed as if some “compensating” kerning had been applied.