Created attachment 195023 [details] A document containing a table of numbers with the lining number feature enabled Steps to reproduce: 1. Install the free and open-source font "Zilla Slab", available at https://fonts.google.com/specimen/Zilla+Slab (or any other font that includes a lining numerals OpenType feature) 2. Create a table in which some of the entries are only a number or comma-separated numbers 3. Activate Zilla Slab's lining numerals (lnum) feature through Format → Character → Features or set the document's font to "Zilla Slab:lnum" Expected behaviour: in the table entries that contain only a number or a number followed by a comma, the number displays in the lining number form, as it does for the table entries that contain letters. Actual behaviour: in the table entries that contain only a number or a comma-separated number followed by a comma, the numbers display as their default non-lining forms. Even stranger, if any alphabetic character is typed in the cell, all digits in the cell switch to their lining form. Attached is a file that reproduces the bug.
The document uses Linux Libertine G instead of Zilla Slab. Is this intentional? Can you give exact cells where we will see the unexpected behaviour? I used Find & Replace with regex and could not find any piece of text ending in a comma, which seems to be in conflict with what you said: "in the table entries that contain only a number or a number followed by a comma" Maybe you attached the wrong document? To explain what lining numbers mean, I found this: https://typenetwork.com/articles/opentype-at-work-figure-styles Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Created attachment 196918 [details] Document with the font corrected to Zilla Slab:lnum Here is the same document with the font corrected to Zilla Slab:lnum. That was my mistake. You can clearly see the problem on the centre diagonal with entries like 10,10 and 3,3. The figures there are the old-style variants, with 1234579 going below the baseline and 6/8 going above it. Whereas if you type an alphabetical character in the cell, the numbers realize that they should be their lining variants and snap back to full height. If you type just a number in a cell, it's the oldstyle variant. But I've specified via the OpenType font features that it should use the lining variant.
Created attachment 196919 [details] Screenshot of the problem Here is a further screenshot of the problem. In the top cell consisting of only numbers and commas, the 10 is much shorter than the full-height lining numerals in the bottom cell. I want the 10s in both cells to be the same.
Thanks, now I see it. Checking with bibisect repositories, looks like the implementation happened in 5.3 with the move to HarfBuzz: https://wiki.documentfoundation.org/ReleaseNotes/5.3#Text_Layout Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3370e122d7f9edf40895f90706047ceb8ee7229d CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 4 October 2024
IIRC, Calc has some kind of a fast text path that has limited functionality and it has some heuristics to decide when to use this fast path and when to use full-featured text layout. This might be a case of this where the numbers-only string goes through the fast path which probably does not apply font features, while the other string goes through the full-featured text layout.
Never mind, this is a Writer not Calc document.
I think it is partly a font problem, and partly a LibreOffice problem. When the string is composed entirely from Common characters (i.e. characters that do not belong to a specific script, numbers here), LibreOffice can not detect what script these characters belong to and what OpenType script to enable, so uses “DFLT” script. However, the font registers the lnum feature only for “latn” script, so the feature does not get applied. When there is a Latin letter, LibreOffice will correctly use “latn” script for the whole string. This can be reproduced with hb-shape command line tool. If I don’t specifically set a script (it will guess “DFLT”), the feature has no effect: $ hb-shape ZillaSlab-Regular.ttf 10 --features=+lnum [uni0031=0+385|uni0030=1+576] When I explicitly set “latn” script, the feature gets applied: $ hb-shape ZillaSlab-Regular.ttf 10 --features=+lnum --script=latn [uni0031.pnum_lnum=0+374|uni0030.pnum_lnum=1+573] I’d consider this a font bug, and it probably affects other applications. LibreOffice can possibly be improved here, by consulting the language if no script can be detected.