Bug 145277 - Vertical orientated or right bounded text has wiggling letters
Summary: Vertical orientated or right bounded text has wiggling letters
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: reproducible
Keywords:
Depends on:
Blocks: Kerning
  Show dependency treegraph
 
Reported: 2021-10-22 14:04 UTC by Telesto
Modified: 2022-01-17 11:18 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (8.24 KB, application/vnd.oasis.opendocument.text)
2021-10-22 14:05 UTC, Telesto
Details
Screencast regular speed (163.48 KB, video/mp4)
2021-10-27 12:20 UTC, Telesto
Details
Screencast when looking frame by frame (230.46 KB, video/mp4)
2021-10-27 12:21 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-10-22 14:04:58 UTC
Description:
Vertical orientated text has wiggling letters

Steps to Reproduce:
1. Open the attached file
2. Press and hold d
3. You might use undo/redo.. Notice that the letters spacing on insertion not always the same (shifting occurs)

Highlighting has no function.. except highlighting the existing D

-> The same has been illustrated in plenty of forms and ways.. so not unique.. but I like having various examples. As the behaviour sometimes appears to be a regression (but simply uncovered pre-existing behaviour)

Actual Results:
Spacing sometimes different

Expected Results:
Not so


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 93115d2c54d645bcf2f80fde325e3ede39dee4d5
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

Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

and in
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 1 Telesto 2021-10-22 14:05:10 UTC
Created attachment 175877 [details]
Example file
Comment 2 V Stuart Foote 2021-10-23 13:55:18 UTC
Not seeing any h-spacing or baseline alignment deviations in the run of vertical text.

Windows 10 (21H1) with Intel Iris GPU

Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded


Nor with Skia/Raster nor with default GDI rendering.
Comment 3 Rainer Bielefeld Retired 2021-10-27 12:05:57 UTC
NOT reproducible with Installation of Version:7.2.1.2 (x64); Build ID: 87b77fad49947c1441b67c559c339af8f3517e22; CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: threaded and sample document: everything looks as expected for me.
Comment 4 Telesto 2021-10-27 12:20:28 UTC
Created attachment 175951 [details]
Screencast regular speed
Comment 5 Telesto 2021-10-27 12:21:20 UTC
Created attachment 175952 [details]
Screencast when looking frame by frame
Comment 6 Telesto 2021-10-27 12:25:17 UTC
FWIW: zoom 160% 96 dpi screen 1920x1080
Comment 7 Rainer Bielefeld Retired 2021-10-27 14:47:21 UTC
REPRODUCIBLE (more or less) with Installation of Version:7.2.1.2 (x64); Build ID: 87b77fad49947c1441b67c559c339af8f3517e22; CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: threaded.

Visibility (and may be exitence) of the problem depends on zoom. With my particular configuration, sample document and zoom 271% (optimum width) for example I see that every third "d" I insert at the top left start position the distance between first and second "d" becomes a little less. Similar effects at other positions.

But:
The flaw is not limit to such vertical orientated characters. With sample document:
1. select all
2. 'Format -> character -> Position -> Rotation = 0'
3. Click "Right bound" icon so that text ("d") moves to right margin
4. <End> key so that caret flashes right from "d"
   ยป with a little luck you will see the varying distances between the 
     characters in the "ddd...." line.                                 ๐Ÿ˜ฅ

If not you might be lucky with changing zoom.

I wonder whether there already is another Bug for this ...
Comment 8 Telesto 2021-10-27 15:09:53 UTC
(In reply to Rainer Bielefeld Retired from comment #7)
> I wonder whether there already is another Bug for this ...

Well the problem is certainly not unique. I'm have reported the same thing in multiple tickets (to prevent a mess in a single ticket; however tremendous amount will be duplicates in hindsight). 

I still asking myself what the core problem is, or maybe even multiple causes mixed together

We have floating point glyph positioning hypothesis (bug 103322) another possibility would be influence of text portions (and RSID tags) (bug 140161)

Screen DPI/zoom-level are is mixed into this also [which suggests rounding]. And the situation apparently improves with high resolution monitors

Which makes me think why use some high internal resolution for the calculations for low DPI screens [say 300 dpi], and downsize it for the paint to 96 DPI as a lazy work-around. 

More in-depth research is needed. I'm only scratching at the surface
Comment 9 Telesto 2022-01-17 11:18:26 UTC
Fine with
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 52443996eff721e612ac4afc1eb1a53bb8a3e06f
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