Description: Template heading setup using font sizes - like 18.2 - not available in DOCX (so causing compatibility issues) Steps to Reproduce: 1. Open Writer 2. Apply heading 1 (navigator) 3. Type something 4. Export to DOCX 5. File reload -> Notice font size change from 18.2 to 18 6. Open the attached file 7. Save as DOCX 8. File reload -> Notice page shifts (bullet on start page 3 or empty page 5) Actual Results: Shifts Expected Results: Maybe be bit more compatible out of the box? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 05366b8e6683363688de8708a3d88cf144c7a2bf 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
Created attachment 172244 [details] Example file
Any change here might cause angry mob, I estimate.. but however matching DOCX font sizes by default -OOTB - maybe wise. Dislike ruined layouts on DOCX export
So what is the issue here? do you suggest to export 18.2 to DOCX (impossible, since sz element uses half-points, and so can only contain 18 or 18.5, not 18.2 - see ECMA-376-1:2016 sect. 17.3.2.38)? or to change the defaults in Writer? The issue is absolutely unclear in the description of what exactly the perceived problem is.
(In reply to Mike Kaganski from comment #3) > So what is the issue here? do you suggest to export 18.2 to DOCX > (impossible, since sz element uses half-points, and so can only contain 18 > or 18.5, not 18.2 - see ECMA-376-1:2016 sect. 17.3.2.38)? or to change the > defaults in Writer? The issue is absolutely unclear in the description of > what exactly the perceived problem is. The issue laymen terms Layout shifts on DOCX export because of rounding heading size up/down Desired; preferably no sudden layout changes on DOCX export Technical perspective A) Export 18.2 pt size. However as you made clear: ECMA-376-1:2016 sect. 17.3.2.38 doesn't allow this. So no go. B) Adjust the defaults Heading sizes of LibO so the default setting prevents rounding/up down DOCX export. So ODT -> DOCX conversion being working out of the box with stock settings. C) Different solution I didn't think of, yet.. * Say: Warning that certain setting not being compatible with DOCX
The 18.2pt is what you get from 130% - the size of Heading 1 related to its parent. Guess MSO cannot handle percent, so +1 to b).
Last change was in [1] to make H3 relative by setting it to 101%. Miklos, Laszlo, what do you think about using absolute values instead of the relative? Tentative patch at https://gerrit.libreoffice.org/c/core/+/130475 [1] https://github.com/LibreOffice/core/commit/0597f3bb6b6066255b0ce50ea98d2dd7e2c6708b
I think it's reasonable to go with absolute values, it's the first time I hear about relative values in the context of Writer font sizes.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3c94c670fa3c3a4e00e88de7463c5e35f32b866e Resolves tdf#142423 - Use absolute values for Writer styles It will be available in 7.4.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.
H1: 130% / 18.2 => 18 H2: 115% / 16.1 => 16 H3: 101% / 14.1 => 14 H4: 95% / 13.3 => 13 H5: 85% / 11.9 => 12 H6: 80% / 11.2 => 10 H7: 80% / 11.2 => 10 H8: 75% / 10.5 => 9 H9: 75% / 10.5 => 9 Would never use these values (heading smaller than text body) nor randomly mixed with other attributes (bold, italic). My solution would be to activate the "Default" template and have these hard-coded values only as fallback.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/a25c88daab20f1b7fc82b54171f260c4f20b9ba0 Resolves tdf#142423 - Use absolute values for Writer styles It will be available in 7.3.2. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c6abf6449e26bb1e1da382ddbe769cd14463467f tdf#142423: sw_uiwriter3: Add unittest It will be available in 7.4.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.
(In reply to Commit Notification from comment #11) > Affected users are encouraged to test the fix and report feedback. Yes, feedback here. Cf tdf#151258 long existing behavior with a rationale behind it, has been broken with this change. I suggest to look at other solutions for this bug report.
(In reply to Heiko Tietze from comment #9) > H1: 130% / 18.2 => 18 > H2: 115% / 16.1 => 16 > H3: 101% / 14.1 => 14 > H4: 95% / 13.3 => 13 My take would be to improve the algorithm to do a round() (for the first 4 headings)..
First of all I believe most users are not familiar with percentage font sizes and don't know a) what it means and b) how to change it. The rounding issue is just one problem. (In reply to Cor Nouws from comment #13) > My take would be to improve the algorithm to do a round() (for the first 4 > headings).. Where do you expect the rounding to happen? 14 * 130% = 18.2 - we must not round the actual font size neither you want to read 128.57%. I see no way out.
(In reply to Cor Nouws from comment #12) > (In reply to Commit Notification from comment #11) > > > Affected users are encouraged to test the fix and report feedback. > Yes, feedback here. > Cf tdf#151258 long existing behavior with a rationale behind it, has been > broken with this change. > I suggest to look at other solutions for this bug report. Let's keep an eye on this and decide if more users expect the percent rather than integer points.