Bug 142560 - Fallback glyphs are missing and the result text layout mess up
Summary: Fallback glyphs are missing and the result text layout mess up
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.2.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Mark Hung
URL:
Whiteboard: target:7.3.0 target:7.2.0.0.beta2
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-30 02:08 UTC by Mark Hung
Modified: 2022-05-04 11:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample document (9.98 KB, application/vnd.oasis.opendocument.text)
2021-05-30 02:08 UTC, Mark Hung
Details
screenshot (7.30 KB, image/png)
2021-05-30 02:09 UTC, Mark Hung
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hung 2021-05-30 02:08:01 UTC
Description:
If the text contains glyphs that use level 2 fallback layout, the glyphs will be missing and the text layout will mess up. The attached document contains two lines. Two lines are identical except their formatting. The lines contain rare used Chinese characters can be completely displayed with two different fonts, MingLiU and MingLiU-Extb, as in the second line. The first line is formatted with DFKAI-SB, so it uses up to two level fallback layout.

The first line can be displayed properly with Impress, which does not use DrawTextArray of outdev, and can be fixed with [1], which disabled precomputed cache items for fallback layout.

[1] https://gerrit.libreoffice.org/c/core/+/116134

Steps to Reproduce:
1.Open the attached file on Windows.


Actual Results:
The first line of the document can not be displayed properly.

Expected Results:
The first line of the document can be displayed properly.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 14e52313e4d350d9960cdd972e87b7f206ee4e2d
CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: zh-TW (zh_TW); UI: en-US
Calc: CL
Comment 1 Mark Hung 2021-05-30 02:08:35 UTC
Created attachment 172447 [details]
sample document
Comment 2 Mark Hung 2021-05-30 02:09:11 UTC
Created attachment 172448 [details]
screenshot
Comment 3 Mark Hung 2021-05-30 02:26:14 UTC
Hi Luboš,

I think this issue is related t0 how pre-coumputed glyph items are handled for fallback layouts, which was introduced in 7439cabc643d. 

OutputDevice::ImplGlyphFallbackLayout does not generate level>1 fallback because those fallback glyph items have been removed. But even if I try to force it to use pre-computed glyph items, the layout still messes up. I guess it's because the glyph item cache are not valid, after adjustment.

Do you have insight about how can this fixed?
Comment 4 Luboš Luňák 2021-05-31 16:01:53 UTC
I cannot reproduce this locally. My Windows has no 'MingLiU', only 'MingLiU-ExtB', 'MingLiU-HKSCS_ExtB' and 'PMingLiU-ExtB'. Also no DFKAI-SB. I've tried downloading those and installing, but then that doesn't show the same result as you have.

But the general idea is that the result should be the same whether something is cached or not. It's possible there's a bug, but I do not see it just from looking at the code. Presumably the way to test this is to debug how the code executes with the caching enabled and disabled and find the difference.
Comment 5 Mark Hung 2021-06-07 12:51:44 UTC
(In reply to Luboš Luňák from comment #4)
> I cannot reproduce this locally. My Windows has no 'MingLiU', only
> 'MingLiU-ExtB', 'MingLiU-HKSCS_ExtB' and 'PMingLiU-ExtB'. Also no DFKAI-SB.
> I've tried downloading those and installing, but then that doesn't show the
> same result as you have.
> 

OK. Maybe the fallbacks depend on system locale.

> But the general idea is that the result should be the same whether something
> is cached or not. It's possible there's a bug, but I do not see it just from
> looking at the code. Presumably the way to test this is to debug how the
> code executes with the caching enabled and disabled and find the difference.

Thanks. I'll check if I can identify the cause.
Comment 6 Commit Notification 2021-06-21 11:22:45 UTC
Mark Hung committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/10ea27faec115d4cffd6f66cee8f688399e1e0b2

tdf#142560 handle cached glpyh items in ImplGlyphFallbackLayout

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2021-06-24 15:26:37 UTC
Mark Hung committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/f5e565eb0dcee2d7e42180b1fd0ad12555de2a22

tdf#142560 handle cached glpyh items in ImplGlyphFallbackLayout

It will be available in 7.2.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Xisco Faulí 2022-05-03 12:22:29 UTC
A polite ping to Mark Hung:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ?
Otherwise, Could you please explain what's missing?
Thanks