Bug 103590 - With experimental Harfbuzz common layout, <alt>+X Unicode toggle having script and font fall back issues
Summary: With experimental Harfbuzz common layout, <alt>+X Unicode toggle having scrip...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: HarfBuzz
  Show dependency tree / graph
 
Reported: 2016-10-30 20:34 UTC by V Stuart Foote
Modified: 2016-10-31 15:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-10-30 20:34:57 UTC 
Description:
When HarfBuzz based layout is enabled, the <alt>+X Unicode toggle is changing script and "misinterpreting" glyphs.

Steps to Reproduce:
1. enable HarfBuzz based common layout with SAL_USE_COMMON_LAYOUT
2. Open and new Writer document
3. select a font with some SMP coverage for the Misc Symbols and Pictographs (DejaVu Sans, Symbola, Noto Emoji)
4. enter following Unicode codepoints as text (for airplane, peace, car, rho):
U+2708 U+2628 U+1f697 U+1d68
5. convert with <alt>+X each of the Unicode points to its glyph, position cursor to last character and toggle for each
6. what happens when converting the last entry?


Actual Results:  
The glyphs are recast into another font/language--I can't tell which, but it looks garbled up.

Expected Results:
script/language and font should not change when toggling one symbol that is from a code page--greek here for the "rho", similar happens with other codepoints from the Greek & Coptic page.


Reproducible: Always

User Profile Reset: Yes

Additional Info:
First noticed this in Math formula editor module where being able to directly add additional mathematics symbols had been facilitated by the Unicode codepoint toggle.  This facet of the script & font handling in HarfBuzz has scrambled things.


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 V Stuart Foote 2016-10-30 20:43:33 UTC 
I think another facet of this can be found in the autocorrect tables. Tools -> AutoCorrect -> AutoCorrect Options the font/glyphs for the replacement value seems badly composed.

Missing a lot of glyphs for the emoji entries--placeholder boxes-- and looks like many with an entry simply have an incorrect glyph shown.
Comment 2 V Stuart Foote 2016-10-30 20:46:16 UTC 
On Windows 10 Pro 64-bit (1607) en-US with
Version: 5.3.0.0.alpha1+
Build ID: 0a4e0dfffd2038c5bcaef0bc20884e60dfc2080a
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-10-30_00:16:37
Locale: en-US (en_US); Calc: CL
Comment 3 V Stuart Foote 2016-10-30 20:48:35 UTC 
@Khaled, 

Any chance https://cgit.freedesktop.org/libreoffice/core/commit/?id=641b9cb1d0934b3f8b4a80279cb3f3f81ecc4707 also nips this?
Comment 4 ⁨خالد حسني⁩ 2016-10-30 23:51:45 UTC 
I cannot reproduce, so I assume it is fixed by the mentioned commit. Will leave it open until confirmed.
Comment 5 V Stuart Foote 2016-10-31 15:32:24 UTC 
Yes, it is fixed now.

On Windows 10 Pro 64-bit en-US with
Version: 5.3.0.0.alpha1+
Build ID: 4b4abb73fcd7f2802e73102b3e7c30face8d309c
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-10-31_02:54:50
Locale: en-US (en_US); Calc: CL