Created attachment 127361 [details] Crosextra and MS C fonts kerning example (LO 5.2.1 on Windows Vista, 32-bit) The attached screenshot shows the kerning difference with Google crosextra fonts (Carlito, Caladea) and the MS C fonts (Calibri, Cambria) they are supposed to be metrically compatible with. The issue is that the Google crosextra fonts miss the kerning. It can be observed with "Te" in "Test" and "Ve" in "Version" in the attached screenshot. That results in different word and so text line length, leading to line breaks at different positions and thus different document display. If the kerning is disabled in the character properties (context menu -> Character... -> Position tab), the MS C and the crosextra font text lines become metrically compatible. The issue seems to be Windows-only. The affected crosextra fonts were automatically installed on LO installation. I could reproduce it with 32-bit LO on following: - 32-bit Windows Vista: Version: 5.2.1.2 Build-ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU-Threads: 2; BS-Version: Windows 6.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group - 64-bit Windows 10: Version: 5.1.5.2 Build-ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 CPU-Threads: 4; BS-Version: Windows 6.2; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: CL I could not reproduce it with 64-bit Lunux Mint 17.1 (based on Ubuntu 14.04.1 LTS), where the affected fonts were installed by installing Ubuntu's fonts-crosextra-carlito and fonts-crosextra-caladea packages (manual installation triggering). LO as provided by its Ubuntu PPA: Version: 5.1.5.2 Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1 CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; Locale: de-DE (en_GB.UTF-8); Calc: group In the above Linux case, the crosextra fonts do obviously apply kerning. (A visual comparison to MS C fonts was not made, due to their lack on the affected machine.) ==> As a result, a document created on Linux using the crosextra fonts (where their kerning works) will be shown differently on Windows (where their kerning doesn't work). The issue was confirmed in Writer, Impress, Draw and Calc. Although in the latter the kerning is disabled by default and needs to be enabled in character properties for the issue to appear. The issue first appears in LO 5.1.x. In LO 5.0.5 (tested as portable release on Vista machine with LO 5.2.1 installed) the crosextra fonts do use kerning metrically compatibly to the MS C fonts. (But: Always - trying to disable the kerning in character properties has no effect there.) Therefore, setting as "regression".
Created attachment 127362 [details] Writer file used for the test
Note: The issue does not occur with MS's "Times New Roman" and "Arial" compared to their metric compatible "Libreration Serif" and "Liberation Sans" (tested with LO 5.2.1 on Vista). So that the issue seems to be specifically related to the crosextra fonts. (Their misconfiguration of some sort?)
Confirming the issue on Windows 8.1 Ent 64-bit en-US with Version: 5.2.2.1 (x64) Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Locale: en-US (en_US); Calc: group However, I believe the issue is with with font hinting and kerning--or lack there of--for Carlito and Caladea on Windows as handled by the SimpleWinLayout source in LibreOffice. IIUC Google provided font mapping for fontconfig use with ChromeOS, which I assume is packaged for use on Linux. But is there similar font detail for use of the fonts on Windows? There does not appear to be looking at the font with cr8software.net's Type light 3.2--both Carlito and Caladea do not provide hinting or kerning in the LibreOffice Windows packaging. I checked the Microsoft deployed Calibri and Cambria fonts the same way with Type light 3.2 and they both provide hinting and kerning--so not unexpected that they are rendered differently than Carlito and Caladea. Also, the Liberation Serif and Liberation Sans fonts packaged with LibreOffice Windows builds are both provided with hinting and kerning for the fonts. Not sure if this is a LibreOffice packaging issue, or is an issue with Google's delivery of the Chromium OS Extra fonts.
Thank you very much for Thank you very much for your feedback! I'm removing the "regression" keyword as I'm no longer sure that it is one. It looks more like being due to a change from an always-on automatic kerning in LO 5.0 (like in bug 102226 on Linux) to the manual font-provided kerning in LO 5.1 (which is considered better). And the crosextra fonts seem to lack the necessary kerning information, which seems to be the issue here. That's just a guess based on information available so far.
(In reply to Johnny_M from comment #4) > [...] And the crosextra fonts seem to lack > the necessary kerning information, which seems to be the issue here. [...] But then, maybe there is a second, additional issue: That no automatic kerning is applied for a font which lacks the manual kerning information? While kerning is requested via character configuration. (That is, if it's possible to detect for a font if it includes the kerning information/tables. But then, what if a font provides that information only for a subset - e.g. western, Cyrillic, but not Greek or other. I guess it would be the responsibility of the font designer to use an "all or nothing" approach - i.e., if including kerning information, then for all desired subsets, otherwise not include anything at all, in which case the kerning could be done automatically. I don't know much on the topic though.)
Sorry for indecisiveness, but from the user point of view it does look like a regression: kerning works for Crosextra fonts in LO 5.0 (although always-on for all fonts), but doesn't since LO 5.1. Or otherwise an "implementationError". Anyway, a bibisect would be useful. By the way, I've checked a longer Writer document using Carlito font and justified alignment with hyphenation (for better line space usage) and the difference between its line break occurrence on Linux and Windows is significant. It accumulates, leading to headings being moved, resulting in incorrect page numbering in the table of contents (although its links still work). With LO 5.0, the difference in line break occurrence between Linux and Windows is much smaller (by factor 20, I guess).
Note: The Windows-to-Linux difference might be explained by the platform differences described in bug 89870 and other issues enumerated by its implementer in https://somefoobar.wordpress.com/2016/08/24/gsoc-project-comes-to-an-end/
Created attachment 129402 [details] Crosextra and MS C fonts kerning example (LO 5.3.0.beta1 on Windows Vista, 32-bit) Version: 5.3.0.0.beta1 Build-ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU-Threads: 2; BS-Version: Windows 6.0; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group Status after introduction of HarfBuzz on Windows (bug 89870): The behavior on Windows is now equal to the one on Linux - see bug 102226 (kerning is always on). Therefore, I'm closing this in favor or the latter.