Description: The following bug is related to Hebrew text on LibreOffice 6.1.1.2. it was reproduced on Windows and Linux. I could not reproduce the problem on MS-Office or with LO-Impress with the same font. The text is not justified. Steps to Reproduce: 1. start new document 2. write some Hebrew sentence using the David CLM font (which is the default font on Windows) 3. bold some random word 4. notice that some intra-word spacing on some surrounding words have changed 5. try to bold some other word, other spaces would change... David CLM font. It can’t be reproduced with English font or with MS-Office with the same font. Actual Results: some intra-word spacing on some surrounding words have changed Expected Results: no change of intra-word spacing of any other words Reproducible: Always User Profile Reset: No Additional Info: I'm attaching to pictures, before with a random word bold/not bold
Created attachment 144962 [details] test odt
Created attachment 144963 [details] before bolding
Created attachment 144964 [details] after bolding
What happens with other Culmus fonts? Other non-Culmus fonts? At different zoom levels?
Different zoom levels - on some zoom levels the bug persists, on others the bold word expands and all the following words move, which I guess is acceptable. Other fonts: Checking on Windows: I didn't install any specific fonts, just the ones that come with the default installation. I'm not sure how can I tell which font is from Culmus as I can't find most of them (http://culmus.sourceforge.net/culmus.pdf) I can't find. For instance, There is a font named Miriam, which doesn't reproduce the problem, and a font named מרים (Hebrew for Miriam) which does reproduce.
The bold word במסמך is 3% narrower than the regular one. It looks like the change in width due to emboldening moves the successive glyphs by a fraction of a pixel, thus making some glyphs move a pixel and others just stay in place. This is probably a limitation of the renderer which would take some effort to resolve. Some higher-end TrueType fonts employ subpixel instructing technique to overcome this issue at small font sizes (i.e. where glyph height doesn't exceed 12-15 pixels). This technique requires a huge amount of work on the affected font, and you would probably buy a retina display long before I get to do it.
So, this problem started to happen after David CLM was embedded into LibreOffice in https://cgit.freedesktop.org/libreoffice/core/commit/?id=4099b7628405e0ad16844eb59a916aa56ffa76ad. Before that, the spacing didn't change. @Heiko, is it a problem in the font or in LibreOffice ?
Reproduced with * David CLM * David Libre * Frank Ruehl CLM * Frank Ruhl Hofshi but not with * Alef * Miriam CLM * Miriam Libre * Miriam Mono CLM * Nachlieli CLM * Rubik
Pretty sure that's an issue of harfbuzz. Khaled, you are the expert here.
No idea what would be going here, but might be rounding errors duo to lack of subpixel glyph positioning.
Dear Idan Miara, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still manifests with David CLM font and: Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US but note that it depends on the zoom factor! When I zoom in a lot, the intra-word spacing does not seem to change. (I'm not sure whether that's a new phenomenon or not).
I wonder if someone sees this with Arabic fonts as well.
Created attachment 195775 [details] Image difference from original screenshots
Created attachment 195776 [details] Image difference from current build
There have been many improvements to text rendering in the past few years. In order to determine whether this issue still exists, I created these two images: https://bugs.documentfoundation.org/attachment.cgi?id=195775 was based on the original attached screenshots. This image shows that most of the text is rendered at exactly the same position in both cases (solid black), except for a few glyphs which are shifted by a large amount (bright white). Based on the bug description, this is the expected observation. https://bugs.documentfoundation.org/attachment.cgi?id=195776 was based on screenshots I took from my local development build. Note that the outlines are dimmer, and more uniform across the text span. This shows that all of the glyphs have been shifted by a relatively similar sub-pixel amount, rather than concentrating that shift in a handful of characters. This is the desired behavior. These results suggest the bug has already been fixed at some point since it was last confirmed. I am therefore marking it WORKSFORME.
(In reply to Jonathan Clark from comment #16) While I agree with your conclusion for David CLM, I still see this phenomenon with David Libre and with Frank Ruehl CLM, even if perhaps with somewhat smaller space changes. To make the bug manifestation clearer: 1. Set the RTL-CTL group font (to David Libre or Frank Ruehl CLM) 2. Select the word במסמך 3. Press, and hold down, Ctrl+B - so that the word becomes emboldened and de-boldened (is that a word?), back and forth, repeatedly, quickly. 4. Stare closely at the different words after במסמך. You'll notice some of them jitter - and some of them _not_ jitter. Seen with: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 01e6e4303e5a9966f102e0357fe0354a2f74a1c4 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded
Created attachment 195777 [details] Image difference from current build with more fonts
(In reply to Eyal Rozenberg from comment #17) > While I agree with your conclusion for David CLM, I still see this > phenomenon with David Libre and with Frank Ruehl CLM, even if perhaps with > somewhat smaller space changes. I repeated the experiment for David Libre and Frank Ruehl CLM. The results were the same, and reflect my expectations for an implementation that's behaving correctly. For a number of technical reasons, there will always be some judder when rendering text in situations like this. For example, the Skia glyph cache has a hard-coded limit on horizontal subpixel offset (4, I believe). This kind of optimization is necessary to maintain a hardware-feasible glyph cache size, but as a side effect it will cause a subtle but observable pattern in subpixel movement if you do a test like the one you described. Humans are very good at noticing patterns. What matters is what measurement shows. The position difference is being applied more-or-less uniformly to all of the glyphs in the run, rather than applying it to specific characters per the original bug report. In my opinion, this bug has been fixed.
(In reply to Jonathan Clark from comment #19) > For a number of technical reasons, there will always be some judder when > rendering text in situations like this. I (and I assume Idan) would not consider that, in itself, a bug. But if you have some words judder or jitter, then a word that's almost stable, then again a word with significant judder - that is problematic. The noticeable non-monotonous behavior of judder as you look away from the original word. > but as a side effect it will cause a subtle but observable > pattern in subpixel movement if you do a test like the one you described. > Humans are very good at noticing patterns. > > What matters is what measurement shows. I'd say what matters is what humans notice. Also... I wonder what it's like in MS-Word. I'll go check. Hmm! Interesting! I (subjectively) notice less judder on Windows, with MS Word 2402 - but also with LibreOffice (24.02). Using Frank Ruehl CLM. Which platform did you use to diff the renderings?
(In reply to Eyal Rozenberg from comment #20) > Which platform did you use to diff the renderings? I used Ubuntu 24.04 with Skia (Vulkan). Font antialiasing and hinting settings are set to the defaults (subpixel and slight, respectively). The hinting setting is the first thing I'd check. Aggressive hinting by itself can cause this, but with that setting change it's not a bug, it's a feature: TrueType is trying to make glyphs more legible by forcing them onto the pixel grid, at the expense of accuracy.
Well... seeing how it's not that bad, and it may be the result of OS/DE-related libraries, and nobody else has opined on this... let's close it. Idan, if you're reading this and are not satisfied by the current behavior - feel free to reopen.