Bug 100972 - Wrong rendering of distance of hatch
Summary: Wrong rendering of distance of hatch
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) All
: medium minor
Assignee: Not Assigned
Keywords: implementationError
Depends on:
Blocks: Page
  Show dependency treegraph
Reported: 2016-07-17 19:41 UTC by Regina Henschel
Modified: 2020-11-26 18:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2016-07-17 19:41:14 UTC
A example document does not help to reproduce, because you need your own standard.soh file.

With a version 5.0 or newer do this:
Rename you user profile to get a new one.
Start Draw.
Goto Format > Area > Hatching
Make the settings: Spacing: 1cm, Angle: 0°, Line type:Single, Line color: Gray 5
Click Add and enter the name Line10mm.
Close Draw, close LibreOffice.
Goto your user folder and therein subfolder config. You should have got a file standard.soh. Open it in an editor and make sure, that it has an item Line10mm with attribute draw:distance="10mm".

Now start Writer and enable vertical ruler.
Goto Format > Page > Background. Set Fill to Hatching. Select item Line10mm from the list. Ok.
Notice, that the lines have wrong distance.
Enter a shape, select Area from its context menu. Goto tab Hatching and click on item Line10mm. Notice that the distance reads 1.76cm.

Rename your user profile back.

Build ID: e9fbe1f7cd28de2a9da8089d89e903406165eb56
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-04-25_00:22:55
Locale: de_DE
The feature hatching for text document pages does not exist in older versions. I don't know the exact version, when it has been introduced.

The error persists in newer version. Under some circumstances (I cannot reproduce) I had seen 1cm in the view, but then the value in file format was not 10mm, but 5.67mm.
Comment 1 Buovjaga 2016-07-26 17:08:56 UTC

Arch Linux 64-bit, KDE Plasma 5
Build ID: c1b665fcdacd4141137f1e369527e2c0d94513ae
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on July 26th 2016
Comment 2 QA Administrators 2018-06-01 02:16:40 UTC Comment hidden (obsolete)
Comment 3 Regina Henschel 2018-06-01 11:16:48 UTC
The error still exists in Version: (x64)
Build ID: f7f2d03bd6f5aa5dcd0f7976b4a7f2db278c2f03
CPU threads: 8; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-25_05:00:28
Locale: de-DE (de_DE); Calc: CL
Comment 4 QA Administrators 2019-06-02 03:01:04 UTC Comment hidden (obsolete)
Comment 5 Regina Henschel 2019-06-09 11:54:58 UTC
The error still exists in Version: (x64)
Build ID: c30ea50dd2b1c557dfbefc1a4c660fbf2402a604
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-05_00:23:26
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded
Comment 6 Regina Henschel 2020-07-12 12:12:13 UTC
It seems the error with hatch distance in Writer is from the beginning. I see it already in swx-format used be OOo1.1.5.

If you define the hatch in Writer with 7mm in the UI, you get 0.397cm in file format. It seems to be a unit conversion problem with Twips in Writer. 7mm = 397 Twips.

Writers use of hatch distance is clearly wrong. But how can we handle this? The error exists so long that there might be a lot of files out there having the wrong value.

Make a cut for ODF 1.4? So that documents from ODF 1.3 and earlier are converted to the correct value on import, and saving an ODF 1.4 document to an earlier version converts the values on export?