Created attachment 197875 [details] file Please see the file attached. The devanagari font is getting overlapped in LO while it is displayed properly in MS Office.
Created attachment 197876 [details] How it appears on LO
Created attachment 197877 [details] How it appears in MS Office
repro on: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: afc441e65107ed808c399b65f4737d25541cdf77 CPU threads: 20; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Can repro on: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 798b43c4ef433d9f2cbfa431ebdf9ec35c3b8a39 CPU threads: 20; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Can't repro on: Version: 24.2.8.0.0+ (X86_64) / LibreOffice Community Build ID: 2a06848352e0ba2e35bc84f8491d06cece32e707 CPU threads: 20; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I can reproduce this bug with your attached file. Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9b2eaa37ba08b4d2c2f1c54a5fbbdaae19fbeedd tdf#164106 Fix reordered glyph positioning with split grapheme clusters It will be available in 25.8.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.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/80e07ed70c11a5c3ab7c355bb1e75278d8e6bdf3 tdf#164106 Fix reordered glyph positioning with split grapheme clusters It will be available in 24.8.5. 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.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/e9f16c0bf79f464bf58b52025d8ab57f4b8dc30a tdf#164106 Fix reordered glyph positioning with split grapheme clusters It will be available in 25.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.
So, I understand there's a fix, but how come the fonts in LO and in MSO are not the same? One is sans serif, the other one is serif. Reporter, when you file bugs, please double-check your choice of fonts, make sure it's available on both systems, plus attach a font file here if necessary (and if it's allowed).
And another question... Jonathan, in the patch description, you write: > Due to formatting, grapheme clusters can possibly be split across > multiple layouts. > > ... > > This change introduces code to disable grapheme cluster splitting > in these cases that cannot be handled correctly. aren't the splits necessary sometimes because of formatting? Or perhaps I should phrase that to ask: Is it now the case that we cannot change formatting in the middle of a grapheme cluster? If the answer is "Yes", * Can you describe the restriction on splitting in lay-person's terms? * Is it a "legitimate" restriction, to your view? For example, with Arabic or Hebrew text, you may want to use different color for the diacritics / tanween than that used for the actual letters; are those the kind of restrictions we're talking about (but for Devangari)?
(In reply to Eyal Rozenberg from comment #9) > So, I understand there's a fix, but how come the fonts in LO and in MSO are > not the same? One is sans serif, the other one is serif. Reporter, when you > file bugs, please double-check your choice of fonts, make sure it's > available on both systems, plus attach a font file here if necessary (and if > it's allowed). I'm sorry. Will do it the next time. But my font on MSO was Times New Roman which seems to have picked up a another serif devanagari font (Kokila), where LO picked up a sans serif devanagari font (Mangala). I'm not sure if this is a bug. But what I do notice is that MSO displays the some characters as bold and some as regular where as LO does not seem to.
The problem now is that the formatting is lost. MSO preserved the formatting and didn't let the characters combine since they had different formatting (one is bold and the other is regular). But LO turns everything to regular now and combines the characters.
(In reply to madhavkiran.sodum from comment #12) > The problem now is that the formatting is lost. Please open a separate bug for that. Also, make sure to explain whether the problem is with opening a DOCX or whether it occurs with an ODF as well. Also, please either use a font bundled with LibreOffice or otherwise attach the font file(s).
I missed these questions when posted: (In reply to Eyal Rozenberg from comment #10) > Is it now the case that we cannot change > formatting in the middle of a grapheme cluster? Nothing has changed from before. The GUI still won't let you do it (bug 71956), but we can read files that contain these format changes, the text should render without shaping problems, grapheme clusters entirely contained by a formatted run should display using that format, and where possible we will display format changes within grapheme clusters. > * Can you describe the restriction on splitting in lay-person's terms? Our approach to intra-cluster format changes still requires formatted runs to be contiguous. We can't apply formatting if glyphs from one formatted run are reordered into another (e.g. we can't render formatted runs that are shuffled together). Glyphs that are reordered into a different run will use the format of that run. When this happens depends on the situation and your font. This fix addressed a layout bug in our handling of such an interleaved case. > * Is it a "legitimate" restriction, to your view? It's legitimate in an economic sense. This is a VCL architecture bug. It's possible to fix perfectly, but it would be very expensive, doesn't seem widely-demanded, and I'm not convinced our compromise is worse than what others are doing. We're probably doing things better than office programs that only let you select a diacritic color on a cluster level, but we're definitely not as flexible as DTP software that lets you individually edit glyphs. (In reply to madhavkiran.sodum from comment #12) > The problem now is that the formatting is lost. > > MSO preserved the formatting and didn't let the characters combine since > they had different formatting (one is bold and the other is regular). But LO > turns everything to regular now and combines the characters. LO was already ignoring the bold in this document, as shown in attachment 197876 [details]. We are currently permissive about what formatting changes we allow without breaking shaping. I think it's reasonable to think about ways to limit this more, but in this specific example, LO thinks all of this text has the same format anyway. As Eyal said, please file new bugs for these two issues, if you haven't already. As a temporary workaround, you can insert a zero-width non-joiner (U+200C) where you would expect shaping to break. That character was created specifically for this use case, and should work in any program regardless of their implementation details.
I have filed a new Bug 165887.