Description: Starting in Version 5.3, Writer doesn't use the kerning information of Times New Roman anymore. So opening old documents results in changed line breaks, changed paragraph breaks and changed page breaks. I'm on Linux and are using the font from the MS Core Fonts for the Web, hence version 2.82 from 2000, so they're quite old. Is this a side effect of the new layout engine? It used to work in versions prior to 5.3, it's also showing this behavior when running the windows version of 5.3 in wine. Furthermore the font is no longer metrically compatible to Liberation Serif and Tinos anymore, but only in Libreoffice. Other programs like Firefox still show all the kerning pairs. Steps to Reproduce: 1. Install LibreOffice 5.3 2. Install MS Core Fonts 3. Type Text in Writer Actual Results: There is no kerning in pairs like Vo, Te, Av, etc. Expected Results: Kerning should be used like in versions prior to 5.3 Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:51.0) Gecko/20100101 Firefox/51.0
Created attachment 131196 [details] difference between 5.2 and 5.3 Screenshot shows difference in rendering of Times New Roman between Libreoffice 5.2 and 5.3.
The fonts you are using are so old that they may not contain proper kerning information. I think the old font rendering engine had its own rules based kerning, whereas the new font rendering engine uses the kerning information (and screen hinting) actually in the font file. I just tested on Windows 7 x64, LibreOffice 5.3.0.3. The kerning on the pairs you listed above (Vo, Te, Av) looks just fine. My version of Times New Roman (v5.22, 2014). So you should try with more current font files. See: Install Microsoft Windows Fonts in Ubuntu 16.04 https://www.ostechnix.com/install-microsoft-windows-fonts-ubuntu-16-04/ That article is dated July 1, 2016 so it should get the most current fonts available for Linux. Note: The kerning is going to change (improve). So you will not get back your exact previous layout.
The fonts described in the article are the fonts I installed. The most current files for Linux users are the ones Microsoft provided in the "Core Fonts for the Web" and are from the year 2000. The Liberation and Croscore fonts, which are metrically compatible, still work like they should. But once the user installs the core fonts (a lot of packages on Linux have them as requirement) the layout in a lot of documents will be broken. This is a huge interoperability issue, since these are the newest fonts the average Linux user gets. Documents with Times and Arial are still very common when sharing with others or when the user needs to edit old documents. As far as I know the new layout engine is based on the one the Linux builds have since 4.1, so there shouldn't be a change in behavior.
It still sounds like these old fonts are the problem. Even if metric-compatible, if the kerning tables in the font file are different then the page layout will not be the same. Please package (ZIP) the font files and attach here so I can take a look at them.
I think the Microsoft EULA doesn't allow redistributing in altered form, but you can download the fonts here: http://downloads.sourceforge.net/corefonts/times32.exe and extract them with 7zip. The problem that I see is that documents that get exchanged with Windows and MacOS users will show different line and page breaks on the different platforms and that's something that counteracts the purpose of new layout engine, right? So a solution would be to either restore the font handling to the one prior 5.3 (which I guess is unlikely) or to blacklist the MS core fonts on Linux and always replace them with the croscore or liberation fonts. People who use times and arial don't give much about typography anyway but want a word processor that works like a typewriter. That means lines stay, page breaks stay and images stay where they were.
Created attachment 131289 [details] Times New Roman vs. Times New Roman OLD
I spent hours trying to find any difference in these font files. I found nothing that would explain the visual differences you describe. The kerning tables are identical. The new font file has 3450 glyphs vs. 1320 glyphs in the old file because they added more languages and characters. The font summary maximum and minimum character widths changed which I assume changed because of all the new characters added not from changing any old characters. In my font tests (multiple) I did not find any visual differences. See the attachment I added above: Times New Roman vs. Times New Roman OLD Metrics look the same. Kerning looks good (well acceptable). So I cannot see the issue. Need to get Ubuntu installed in a VM to test some other stuff. So when I do I will look at this again. Regarding your file sharing situation: You can use the Fonts Replacement Table. If you check both boxes it will not replace the font in the file, but you will see and use Liberation Serif locally. The font selector in the toolbar will still say Times New Roman, but you will actually be looking at and working with Liberation Serif So the visual you see should be the same metrics and kerning they see. Then when you send the document back they will still see Times New Roman.
Attached is another screenshot showing the font replacement. Look closely at the text in the left column - it is really Liberation Sans. The cursor is in the left column and the font box on the toolbar still says Time New Roman. See: Font-Replacement-Demo.png
Created attachment 131290 [details] Font Replacement Demo
Should be ... - it is really Liberation Serif.
Created attachment 131300 [details] Times New Roman from Windows 7 under KDE Neon Here I installed the Times New Roman from Windows 7 in KDE Neon, it shows the kerning pairs and is metrically compatible to Liberation Serif and Tinos.
Created attachment 131301 [details] Times New Roman from MS core fonts under KDE Neon This shows the Times New Roman from the MS core fonts (the one from the year 2000). Comparing the core fonts times with the windows 7 times, you can see the core fonts times is missing the kerning pairs. Libreoffice pre 5.3 (and Openoffice) and other applications like firefox correctly show the kerning pairs.
There is something else going on here. I actually printed the kerning tables and compared them. They are identical. I just spot-checked the following pairs: Aa Ae Ac At Ay Ta Te Ti To Tr Ts Tu Tw Va Vc Ve Vi Vr Vu Vy All have the same kerning values. I will attach PDFs of the kerning tables for you to take a look. See attached ZIP: Times-New-Roman-Kerning-Tables-v2.82-and-v5.22.PDFs.zip
Created attachment 131305 [details] Times-New-Roman-Kerning-Tables-v2.82-and-v5.22.PDFs
Your sample images above seem to show an issue with the "We" pair. Just checked the kerning tables and the values are identical.
@Khaled, any insight into the Times New Roman "Core fonts" metrics as described used with the common HarfBuzz layout at 5.3? More differing table goodness?
The new layout engine does not currently support old style “kern” table, only kerning information in the “GPOS” table are currently supported. Long story short, old HarfBuzz integration code on Linux used FreeType to load the fonts and also give old style kerning information to HatfBuzz, but the new code uses HarfBuzz’s internal font functions to load the fonts (avoids bugs in FreeType, and differences between it and font loading libraries in other fonts), but HarfBuzz internal font functions does not currently support “kern” table (see https://github.com/behdad/harfbuzz/issues/250). The simplest solution here (code wise) is for someone to get “kern” table support in HarfBuzz. Alternatively we can try to load it ourselves and feed it to HarfBuzz but doing this in cross-platform way can be a challenge.
A few comments ... 1. It sounds like you are saying there is no kerning table support in HarfBuzz at all. That it is done by some algorithm. Is that the case? I took a closer look at both font files. FontForge shows both files have a GPOS table. That may or may not be correct. Fontlab Studio was what I used to print the kerning tables. It too makes no distinction showing how the kerning is structured internally. FontCreator does show a clue in its OpenType Designer dialog. For the older font, it shows: - KerningFromKernTable (kern) > KerningFromKernTable For the newer font, it shows: - Kerning (kern) > PairAdustment1 (which is also a lookup table) But since it automatically reads everything into the newer script format, the details look the same. What font tool(s) can be used which will show clearly the structure and tables? 2. Everything I have read at Microsoft Typography still talks about using the GPOS table. There was no deprecation that I can find. It appears this alternative format is just that, an alternative not a promulgated required standard. So why is the GPOS table an issue with HarfBuzz. 3. None of this explains why some character combinations are properly kerned and others are not. I would think all of it would be bad. Or does the HarfBuzz kerning algorithm just have inconsistent results? 4. And if HarfBuzz is not actually reading *any* kerning information that would be a BIG issue in my opinion. Is that the case?
There are two ways to store kerning in TrueType fonts. * The old way using a separate “kern” table (https://www.microsoft.com/typography/otspec/kern.htm), which predates OpenType and has many limitations and (for all practical purposes) is deprecated. This is the one not supported by HarfBuzz internal font functions and what old versions of the font has. * The new way of using PairPos lookups inside GPOS table (https://www.microsoft.com/typography/otspec/gpos.htm#PP), which is the OpenType way, fully supported by HarfBuzz and used by the newer versions of the font.
(In reply to Khaled Hosny from comment #17) > The simplest solution here (code wise) is for someone to get “kern” table > support in HarfBuzz. This can be done by submitting a pull request into their repo, but I think in this solution kern table should be loaded only if a font does not have GPOS kerning.
(In reply to Khaled Hosny from comment #17) > The simplest solution here (code wise) is for someone to get “kern” table > support in HarfBuzz. This can be done by submitting a pull request into their repo, but I think in this solution kern table should be loaded only if a font does not have GPOS kerning. Since we started using HarfBuzz everywhere, this would be better choice.
(In reply to Volga from comment #21) > (In reply to Khaled Hosny from comment #17) > > The simplest solution here (code wise) is for someone to get “kern” table > > support in HarfBuzz. > This can be done by submitting a pull request into their repo, but I think > in this solution kern table should be loaded only if a font does not have > GPOS kerning. Since we started using HarfBuzz everywhere, this would be > better choice. HarfBuzz already does that, the kern table will not be used if GPOS table is present.
*** Bug 108664 has been marked as a duplicate of this bug. ***
HarfBuzz started implementing 'kern' table 4 days ago, and the developer is looking for the way to run this table if the font doesn't have GPOS kerning.
HarfBuzz got support in 1.7.0.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e56dce9efa7184e522c83130dcf79d894488657 tdf#105992: Upload HarfBuzz 1.7.0 It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This should be fixed in 6.0.0 for people using TDF builds or distributions building with the bundled HarfBuzz. For distributions building with system HarfBuzz, this won’t be fixed unless they upgrade to HarfBuzz 1.7.0 or newer.
Thanks everyone. It is fixed with version 6.0!