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.
please note this bug only exists with the windows/uniscribe backend
I don't see anything strange in your document. Please attach a (cropped) screenshot.
Created attachment 111102 [details] scsreenshot
(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.
anything happening?
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.
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 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Created attachment 125032 [details] differently rendered chars I could only reproduce a small subset of the original report (could reproduce it in full in 4.1.0.4). This can be seen in 5.1.3.2 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.
OK, I am now using Version: 5.2.2.2 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!
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. Steps: 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.
Re: comment 10: the string in step 4 should be pasted as plain text (i.e. ctrl+shift+v).
@yossi, Could you please retest with a 5.3.0.3 and current master. The HarfBuzz based common layout and additional font handling work done at 5.3 should have corrected this. My testing with 5.3.0.3 of attachment 110949 [details] and of the string from comment 10 shows correct fallback font handling. =-testing-= Version: 5.3.0.3 (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 and Version: 5.4.0.0.alpha0+ 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
I checked with: Version: 5.3.0.3 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!
OK, lets close resolved WFM.