Bug 122023 - FILEOPEN PPTX shape with "Shrink text on overflow": Calibri Light font size 55,7 instead of 54 and text splits a word into two lines
Summary: FILEOPEN PPTX shape with "Shrink text on overflow": Calibri Light font size 5...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:pptx
: 107694 117393 123103 130011 132895 136229 149997 (view as bug list)
Depends on:
Blocks: PPTX-Textbox Autofit
  Show dependency treegraph
 
Reported: 2018-12-11 15:33 UTC by 張修銘
Modified: 2023-08-27 14:33 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
pptx file that can reproduce the bug (36.50 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2018-12-11 15:34 UTC, 張修銘
Details
Screenshot of Office PowerPoint opening the file (59.72 KB, image/png)
2018-12-11 15:35 UTC, 張修銘
Details
Screenshot of LibreOffice Impress opening the file (143.57 KB, image/png)
2018-12-11 15:36 UTC, 張修銘
Details
Modified example file from PP 2016 (38.18 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2023-08-24 22:48 UTC, Gabor Kelemen (allotropia)
Details
The first slide of the new example file in PP 2016 and Impress master (121.79 KB, image/png)
2023-08-24 22:49 UTC, Gabor Kelemen (allotropia)
Details
The second slide of the new example file in PP 2016 and Impress master (114.08 KB, image/png)
2023-08-24 22:50 UTC, Gabor Kelemen (allotropia)
Details
The third slide of the new example file in PP 2016 and Impress master (109.02 KB, image/png)
2023-08-24 22:51 UTC, Gabor Kelemen (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 張修銘 2018-12-11 15:33:28 UTC
Description:
I created a pptx file in Office PowerPoint 2016, but when I open it in Impress, it splits a word into two lines. For example, in first page in the screenshot, "often" is split into "ofte" in the first line and "n" in the second line, and in the second page, "people" is split into "p" in the first line and "eople" in the second line, making text hard to read. Only the second paragraph in the first page is fine.

Steps to Reproduce:
1. Create pptx in Office PowerPoint 2016 and input some words.
2. Open the file in Impress

Actual Results:
Impress splits a word into two lines

Expected Results:
Do not split words. Instead, move the whole word to the next line. (like in PowerPoint)


Reproducible: Always


User Profile Reset: Yes



Additional Info:
LibreOffice from my distribution:
Version: 6.0.7.3.0+
Build ID: 6.0.7-2
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: zh-TW (zh_TW.UTF-8); Calc: group

Also use Appimage to test older version:
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b

And I tested Latest Appimage:
Version: 6.3.0.0.alpha0+
Build ID: e4c2d0bb57ab8ea8f5c400d103d01376b8140f22
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-30_21:37:10
Locale: zh-TW (zh_TW.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 張修銘 2018-12-11 15:34:40 UTC
Created attachment 147441 [details]
pptx file that can reproduce the bug
Comment 2 張修銘 2018-12-11 15:35:42 UTC
Created attachment 147442 [details]
Screenshot of Office PowerPoint opening the file
Comment 3 張修銘 2018-12-11 15:36:20 UTC
Created attachment 147443 [details]
Screenshot of LibreOffice Impress opening the file
Comment 4 Durgapriyanka 2018-12-11 17:58:43 UTC
Thank you for reporting the bug. I can confirm that the bug is present in 

Version: 6.1.3.2
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
CPU threads: 2; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: group threaded
Comment 5 Timur 2019-01-11 17:27:27 UTC
OO opens with font size 44 so looks correct but not. 
LO 3.3 opens with font 24. 
LO 3.4 font 60. 
LO 5.0 font 52,2 so looks correct but not.
LO 6.0 font 52,2.
FWIS in LO 6.3+ Windows, split is different but wrong regardless. LO 6.3+ opens font with size 55,7 although it should be 54. If changed to 54, no split.
I guess same as Bug 107694. But no need to duplicate until some fix.
Comment 6 Timur 2019-02-15 15:36:38 UTC
*** Bug 117393 has been marked as a duplicate of this bug. ***
Comment 7 張修銘 2019-04-24 13:38:10 UTC
Hello, I found a way to make the file display correctly. I go to Format > Character... > Fonts and set Language In Western Text Font to [None] (Language In Western Text Font was set to Chinese (traditional) originally), now a word is not splited.
Comment 8 Timur 2020-11-02 12:24:58 UTC
*** Bug 130011 has been marked as a duplicate of this bug. ***
Comment 9 Timur 2020-11-02 12:50:07 UTC
*** Bug 107694 has been marked as a duplicate of this bug. ***
Comment 10 Timur 2020-11-02 13:02:07 UTC
Change in 4.3, bibisect Lin, single commit:

commit 07dbe52544f811e75d56a5ddcd59aecf1d8f0310
Date:   Thu May 28 17:37:02 2015 +0800

    source-hash-798a563db133ebed3876c245459d90ef54ee7c9a
    prev source-hash-e8df1838ec2d4aa52522334e94e77fae00223490
    
    commit 798a563db133ebed3876c245459d90ef54ee7c9a
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Wed Dec 4 14:30:43 2013 +0100
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Wed Dec 4 14:52:26 2013 +0100
    
        drawingml import: don't set CharEscapementHeight unconditionally
Comment 11 張修銘 2021-09-09 12:12:50 UTC
I can no longer reproduce this on LibreOffice 7.1.5. I think this can be closed.
Comment 12 Timur 2021-09-09 13:17:07 UTC
No. 
It's true that text looks good. But size is till 55,7. And real problem is that this became feature bug for "Shrink text on overflow" which is still NOK.

So I set New again. You can tick (never email me about this bug).
Comment 13 Timur 2022-07-15 13:24:14 UTC
*** Bug 149997 has been marked as a duplicate of this bug. ***
Comment 14 Timur 2022-07-15 13:30:31 UTC
*** Bug 136229 has been marked as a duplicate of this bug. ***
Comment 15 Gabor Kelemen (allotropia) 2023-08-24 22:48:38 UTC
Created attachment 189134 [details]
Modified example file from PP 2016

There seems to be a bit of a difference in case of Title type placeholders and the "Shrink text on overflow" setting.
This file demonstrates the setting with 60, 40 and 20 pt font sizes and small placeholder boxes.

The key is that the same setting operates a different resizing algorithm, depending on the placeholder type: 

- if it's a Title, then the font size is reduced by exactly 10%. So we get 54pt, 36pt and 18 pt, but overall the text happily overflows the small boxes.

- if it's not a Title, but Subtitle, Content then the font size is reduced as much as is needed for the text to fit inside the available box. So we get around 10-20 pt font sizes for the lower boxes.

Impress does the latter algorithm for all textboxes (approximately correctly), but for Title type boxes, should do the "10% font size reduction" one.
Comment 16 Gabor Kelemen (allotropia) 2023-08-24 22:49:48 UTC
Created attachment 189135 [details]
The first slide of the new example file in PP 2016 and Impress master

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c9916d9be9c060d43fc063b76d70629162650fea
CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: threaded
Comment 17 Gabor Kelemen (allotropia) 2023-08-24 22:50:25 UTC
Created attachment 189136 [details]
The second slide of the new example file in PP 2016 and Impress master
Comment 18 Gabor Kelemen (allotropia) 2023-08-24 22:51:02 UTC
Created attachment 189137 [details]
The third slide of the new example file in PP 2016 and Impress master
Comment 19 Gabor Kelemen (allotropia) 2023-08-24 22:53:59 UTC
*** Bug 123103 has been marked as a duplicate of this bug. ***
Comment 20 Gabor Kelemen (allotropia) 2023-08-25 11:54:07 UTC
*** Bug 132895 has been marked as a duplicate of this bug. ***