Created attachment 136727 [details]
comparison between MSO and LibreOffice

comparison screenshot

Issue confirmed on:

OS: Windows 7 Home Premium SP1 (x86)

Versione: 5.3.6.1
Build ID: 686f202eff87ef707079aeb7f485847613344eb7
Thread CPU: 4; Versione SO: Windows 6.1; Resa interfaccia: predefinito; Motore layout: nuovo; 
Versione locale: it-IT (it_IT); Calc: group

see the screenshot attached.
the text is the same (a lorem autotext) tested both on LibreOffice and MSO.

Khaled: since it concerns fonts rendering, thought you might be interested in this one.

Tested MSO 2013 vs LibreOffice 6.0 and they look the same.

Version: 6.0.0.0.alpha0+
Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0
CPU threads: 4; OS: Windows 6.29; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-09-17_05:38:00
Locale: en-US (en_US); Calc: group

@Marc Balmer: Please attach your version and system information found in Help > About, like what i've provided above.

Created attachment 136737 [details]
Word 2013 vs Writer 6.0

My OS is Windows 8.1. Also the cooperhewitt.org website states you should use the TTF on Windows and OTF on OS X.

The ttf font is limited to four cuts.  OTF has all the cuts, and it says nowhere they should not work on windows.  And indeed, they do work on windows, just not with LibreOffice on Windows.  So something is weird here.

Confirming

On Windows 10 Pro 64-bit en-US with
Version: 5.4.1.2 (x64)
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 8; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: group

With default rendering or OpenGL, LibreOffice uses the OTF builds, but when the entire font family of the OTF set is installed the font preview, Characters property dialog and document canvas would scramble.

Only Cooper Hewitt, and Cooper Std Black will show in the listbox, and even as the installed fonts were added/removed by font name if just one of the family was present they behave.

Bold/BoldItalic
Book/BookItalic
Heavy/HeavyItalic
Light/LightItalic
Medium/MediumItalic
Semibold/SemiboldItalic
Thin/ThinItalic

Add more than one pair, and when selecting some text and using the <Ctrl>+B or "Bold" std toolbar button would garble the text.

(In reply to Yousuf Philips (jay) from comment #4)
> Tested MSO 2013 vs LibreOffice 6.0 and they look the same.
> 
> Version: 6.0.0.0.alpha0+
> Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0
> CPU threads: 4; OS: Windows 6.29; UI render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2017-09-17_05:38:00
> Locale: en-US (en_US); Calc: group
> 
> @Marc Balmer: Please attach your version and system information found in
> Help > About, like what i've provided above.

Here we go:

Version: 5.4.1.2 (x64)
Build-ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU-Threads: 2; Betriebssystem:Windows 6.19; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group

(In reply to Marc Balmer from comment #7)

LibreOffice can only handle the four basic font styles (regular, bold, italics, and bold italics) (bug 35538), so if you want to use this font in LibreOffice, then you'll need to stick with the ttf.

(In reply to V Stuart Foote from comment #8)
> With default rendering or OpenGL, LibreOffice uses the OTF builds, but when
> the entire font family of the OTF set is installed the font preview,
> Characters property dialog and document canvas would scramble.

Yes the characters property dialog does scramble, and only lists Bold and Bold Italics as possible styles, and if i set the text in the document to bold or bold italics, it scrambles.

(In reply to Yousuf Philips (jay) from comment #10)
> (In reply to Marc Balmer from comment #7)
> 
> LibreOffice can only handle the four basic font styles (regular, bold,
> italics, and bold italics) (bug 35538), so if you want to use this font in
> LibreOffice, then you'll need to stick with the ttf.
> 
> (In reply to V Stuart Foote from comment #8)
> > With default rendering or OpenGL, LibreOffice uses the OTF builds, but when
> > the entire font family of the OTF set is installed the font preview,
> > Characters property dialog and document canvas would scramble.
> 
> Yes the characters property dialog does scramble, and only lists Bold and
> Bold Italics as possible styles, and if i set the text in the document to
> bold or bold italics, it scrambles.

Does that mean that this bug will not get fixed?  Or will someone work on a solution?

On linux, the font appears in regular style in the font name toolbar combobox, but applying it will have it in bold style and then i enabled bold, it shows it in the regular style. Same goes for bold italics, which shows like its regular italics.

In the character dialog it lists Book, Bold, Book Italic and Bold Italic and everything renders correctly there.

The problem with the Cooper Hewitt OpenType font is that it comes in many variants, Light, Thin, Medium, Book, SemiBold, Bold, Heavy and each variant also has an Italic font cut.

They all have the same font family name, Cooper Hewitt.  The font weights and style indications in the fonts are not correctly setup as well.  But the real problem is the font family name.  LibreOffice seems only to be able to handle a regular, italic, bold, and, bild italic variant of a font family.

As a workaround I create a font familiy for each of the above mentioned font cuts, giving the italic variant the italic style indication, but the same font family name.  This way LibreOffice sees each of the 7 variants as it's own font family and they work.

I keep the bug open, since it is still a bug that LibreOffice can only handle four variants per family, and especially it should not display the font name in such a garbled form.

For the curious, I used FontForge to do the font work.

@xisco:

do you think we could split this report in 2 different ones?

1) LibreOffice can only handle four variants per family
2) font name displayed in a wrong way

ATB,
Marina

(In reply to Marina Latini from comment #14)
> 1) LibreOffice can only handle four variants per family
Bug 35538 seems to be about this.

*** This bug has been marked as a duplicate of bug 35538 ***