Bug 135126 - Paragraph or Character attributes applied to the U+0020 "Space" NPC change text layout
Summary: Paragraph or Character attributes applied to the U+0020 "Space" NPC change te...
Status: RESOLVED DUPLICATE of bug 61444
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2020-07-25 09:04 UTC by Telesto
Modified: 2022-10-02 09:39 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example file (9.02 KB, application/vnd.oasis.opendocument.text)
2020-07-25 09:04 UTC, Telesto
Details
Screencast (331.65 KB, video/mp4)
2020-07-25 09:05 UTC, Telesto
Details
Example file (8.83 KB, application/vnd.oasis.opendocument.text)
2020-07-25 09:29 UTC, Telesto
Details
Example file (9.03 KB, application/vnd.oasis.opendocument.text)
2020-07-25 11:15 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-25 09:04:19 UTC
Description:
Changing font color changes text layout (Harfbuzz)

Steps to Reproduce:
1. open the attached file
2. Select the second paragraph
3. Press Font color.. 'to' drops to second line

Actual Results:
to drops to second line

Expected Results:
Same line


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-07-25 09:04:35 UTC
Created attachment 163507 [details]
Example file
Comment 2 Telesto 2020-07-25 09:05:30 UTC
Created attachment 163508 [details]
Screencast
Comment 3 Telesto 2020-07-25 09:11:09 UTC
Bisected to:
author	Khaled Hosny <khaledhosny@eglug.org>	2016-09-22 19:29:04 +0200
committer	Khaled Hosny <khaledhosny@eglug.org>	2016-10-18 20:41:31 +0200
commit 610eceb035280ed5714b314051913d2412cde604 (patch)
tree 73012fe1f8fa23d61381034002ac315972837bc2
parent 5e65efcaa38ea5fbe655a18082a3ba7c8cf7d5fe (diff)
Always build HarfBuzz everywhere
It is no longer an optional feature on any platform.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=610eceb035280ed5714b314051913d2412cde604

Of course not to helpful
Comment 4 Telesto 2020-07-25 09:17:26 UTC
This tend to go to bug 103322.. however it confused.. it happens if direct formatting is applied.. 

Clear direct formatting solves the issue.. anything else not. So I don't get the floating point stuff here. 

Difference is between DF <-> No formatting
Comment 5 Telesto 2020-07-25 09:19:20 UTC
@V Stuart
More you're kind of issue
Comment 6 Telesto 2020-07-25 09:29:50 UTC
Created attachment 163512 [details]
Example file

1> Toggle formatting marks on
2. Select the spacing between" lost. After" 
3. Apply Italic or Underline or font color or highlight color (for bold you can see the spacing grow.. but for the rest?)
Comment 7 Telesto 2020-07-25 09:33:25 UTC
It even happens when setting the Character spacing for the 'space' to -2 or something like that
Comment 8 Telesto 2020-07-25 09:34:20 UTC
(In reply to Telesto from comment #6)
> Created attachment 163512 [details]
> Example file
> 
> 1> Toggle formatting marks on
> 2. Select the spacing between" lost. After" 
> 3. Apply Italic or Underline or font color or highlight color (for bold you
> can see the spacing grow.. but for the rest?)

Or cut the space & apply it again
Comment 9 Telesto 2020-07-25 11:15:38 UTC
Created attachment 163515 [details]
Example file

Slightly better example. Select the spacing between "lost. After" Press Italic (enable) Press Italic again (disable) -> No effect on the text. Save & reload.. still the same

Remove formatting and everything is back to normal
Comment 10 V Stuart Foote 2020-07-25 14:35:52 UTC
Confirmed. Applying a paragraph attribute to a single space glyph (U+0020) results in a change in its width on document canvas relative to the paragraph style.  But so will applying a character style to the glyph.

That is, open the 'Formatting Styles' toolbar, and apply the 'Emphasis' or 'Strong' character style against the selected space.

So, it is not an issue of Direct Formatting over riding Paragraph style.

I am not certain, but believe it is an issue in the HarfBuzz handling of unattributed space glyphs vs. rendering with an applied attribute.

A space glyph  with VCLs artificial Strike-through or Underline has to be rendered to canvas, likewise our artificial Bold or Italic--that size/width has to be calculated against the font metrics. That's obvious, less so are attributes like the color of a space glyph or applying a background color for the space.

Look closely and you'll see both colors get the same calculated width as the Strike-through or the Underline attribute applied to the glyph.

So, behavior is actually pretty consistent--DF of the space glyph can be removed with an Undo or <Ctrl>+M, while applied Character style (E, S, Q) can be removed by applying the default Character style (A).

Applying Paragraph/Character attributes to other NPC in string would probably behave same.

But, I suspect that this can only be improved with a solution to bug 103322 to provide greater precision in composing the document canvas. And that this ultimately is a duplicate of that issue.

@Khaled?
Comment 11 QA Administrators 2022-07-26 03:29:04 UTC Comment hidden (obsolete)
Comment 12 ⁨خالد حسني⁩ 2022-08-17 01:15:18 UTC
There is no HarfBuzz-related regression here, this is not even something happening in VCL. It is not a regression either, nothing changed in this area. It might have not been visible before because LO was relegating more to the system text layout engines on Windows and macOS.
Comment 13 ⁨خالد حسني⁩ 2022-10-02 09:39:23 UTC
The space glyph is kerned to the next glyph, applying different formatting to it breaks text layout.

*** This bug has been marked as a duplicate of bug 61444 ***