Bug 87410 - RTL font fallback in rtl layout when using uniscribe backend results in a total mess
Summary: RTL font fallback in rtl layout when using uniscribe backend results in a tot...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: RTL-CTL Font-Rendering
  Show dependency treegraph
Reported: 2014-12-17 12:42 UTC by yossi
Modified: 2017-03-01 22:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

top line shows correct rendering in arial, arial black doesn't contain hebrew glyphs and results in the mess shown on second line. Please view this attachment in Windows not Linux. (8.99 KB, application/vnd.oasis.opendocument.text)
2014-12-17 12:42 UTC, yossi
scsreenshot (2.28 KB, image/png)
2014-12-21 07:29 UTC, yossi
screenshot of character dialogue (26.75 KB, image/png)
2015-05-29 12:44 UTC, Gordo
differently rendered chars (64.91 KB, image/png)
2016-05-13 10:21 UTC, Aron Budea

Note You need to log in before you can comment on or make changes to this bug.
Description yossi 2014-12-17 12:42:18 UTC
Created attachment 110949 [details]
top line shows correct rendering in arial, arial black doesn't contain hebrew glyphs and results in the mess shown on second line. Please view this attachment in Windows not Linux.

When Libreoffice determines that font fallback is necessary the layout of RTL texts goes totally  haywire. see attached file. this makes Libreoffice almost entirely unusable for me since most of my Hebrew fonts cause trouble.

I can't work out what the decision of using font fallback based on, perhaps Uniscribe returning E_SCRIPT_NOT_IN_FONT. This might be a bug in itself since Uniscribe will say that even if all the necessary characters are available just the font doesn't have the correct open-type features.

All my proprietry Hebrew fonts - which are from reputable Israeli font vendor and support all Hebrew features, don't work in OpenOffice, though many free and open Hebrew fonts do work.
Comment 1 yossi 2014-12-17 12:50:16 UTC
please note this bug only exists with the windows/uniscribe backend
Comment 2 Urmas 2014-12-19 18:03:16 UTC
I don't see anything strange in your document. Please attach a (cropped) screenshot.
Comment 3 yossi 2014-12-21 07:29:59 UTC
Created attachment 111102 [details]
Comment 4 yossi 2014-12-21 11:32:35 UTC
(In reply to Urmas from comment #2)
> I don't see anything strange in your document. Please attach a (cropped)
> screenshot.

Do you have "Arial Black" installed on your system? Is it missing Hebrew glyphs? If the answer is no to any of those questions, try forcing font fallback by choosing another font that is missing Hebrew glyphs, e.g. "DejaVu Serif" or one of the many others.
Comment 5 yossi 2015-05-12 09:16:37 UTC
anything happening?
Comment 6 yossi 2015-05-12 09:24:28 UTC
I just tried opening attached file and noticed that on first open it displays fine, however after some editing the display goes all wrong again.
Comment 7 Gordo 2015-05-29 12:44:33 UTC
Created attachment 116134 [details]
screenshot of character dialogue

I opened the document, saw that it was at 200% zoom, and changed it to Page Width.  Some of the characters became blocks.  Changing the zoom level up and down resulted in either the text displaying correctly or some or all of the characters appearing as blocks.

It did get to the point that I could not reproduce it reliably.  I tried exiting LO completely and reopening the document but I don't know the exact steps required to get it to display the blocks.

In Tools → Language → For all Text → More, CTL is not checked for the current document.

The attached screenshot shows the blocks in the preview.

Windows Vista 64
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Comment 8 Aron Budea 2016-05-13 10:21:05 UTC
Created attachment 125032 [details]
differently rendered chars

I could only reproduce a small subset of the original report (could reproduce it in full in

This can be seen in and master builds in Windows:
if you break the line before and after the ' and " in the second line, the font those characters are rendered with changes. See attached screenshot, I circled the relevant characters.

Reporter, please check with most recent version to see if you still encounter the original issue, or the one you mentioned in Comment 6 apart from this.
Comment 9 yossi 2016-11-28 06:44:28 UTC
OK, I am now using Version:
Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad

Good news is that at least the fonts that have full Hebrew coverage seem to work correctly so far.
However.... Font fallback is still broken.
Steps to reproduce the bug:
1. Take a default installation of libreoffice.
2. It makes no difference if CTL is enabled or not.
3. Set your keyboard layout to Hebrew.
4. Start typing Hebrew characters.
5. In the default installation the font shown in the font pulldown menu will be "Mangal" which does not contain Hebrew glyphs. The glyphs will be rendered in "Tahoma".
6. Type a space character. All the previous Hebrew characters will show now as boxes.
7. Type another Hebrew character. The display will revert back to Tahoma
8. Type a space. The display will revert to boxes.....

and so on....

definitely broken!
Comment 10 yossi 2016-11-28 12:22:12 UTC
re: Update to comment 9: 

After some testing I can see that typing any char with neutral direction after a RTL char will trigger this bug. 

In addition to the above problem of chars rendering as boxes, I noticed that typing the following string into a RTL paragraph will result in similar artifacts as shown in the second attachment above.

1. open libreoffice
2. enable CTL
3. set paragraph direction RTL
4. paste the following into the document "AB, אבגדהו" (minus the quotation mmarks)
5. enjoy the results

I do not know if this is an additional bug or another manifestation of the same one.

Please note that this only happens on the Windows version and only when the font does not have full Hebrew coverage.
Comment 11 yossi 2016-11-28 12:28:28 UTC
Re: comment 10:

the string in step 4 should be pasted as plain text (i.e. ctrl+shift+v).
Comment 12 V Stuart Foote 2017-03-01 17:36:40 UTC

Could you please retest with a and current master. The HarfBuzz based common layout and additional font handling work done at 5.3 should have corrected this.

My testing with of attachment 110949 [details] and of the string from comment 10 shows correct fallback font handling.

Version: (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group


Build ID: 801422d70133986af45385307a10566af0bc56ee
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-02-20_23:55:07
Locale: en-US (en_US); Calc: CL
Comment 13 yossi zahn 2017-03-01 21:32:17 UTC
I checked with:

Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 

and the rendering is fine.
Thanks to @Khaled and all others involved with the new layout engine!
Comment 14 V Stuart Foote 2017-03-01 22:33:35 UTC
OK, lets close resolved WFM.