Bug 147121 - FILESAVE PPTX: font size of empty line break in multi-line list item increases
Summary: FILESAVE PPTX: font size of empty line break in multi-line list item increases
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Attila Bakos (NISZ)
URL:
Whiteboard: target:7.4.0 target:7.3.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: PPTX-Paragraph
  Show dependency treegraph
 
Reported: 2022-02-02 09:04 UTC by Gerald Pfeifer
Modified: 2022-03-07 12:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample slide in ODP format (705.01 KB, application/vnd.oasis.opendocument.presentation)
2022-02-02 09:04 UTC, Gerald Pfeifer
Details
Visual comparison before (in LO) / after (same in LO and 365) (239.36 KB, image/png)
2022-02-02 09:07 UTC, Gerald Pfeifer
Details
Difference between PP and Impress (189.30 KB, image/jpeg)
2022-02-04 13:23 UTC, Attila Bakos (NISZ)
Details
The XML of PP and Impress, and the problem marked (267.04 KB, image/jpeg)
2022-02-16 14:41 UTC, Attila Bakos (NISZ)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2022-02-02 09:04:14 UTC
Created attachment 177978 [details]
Sample slide in ODP format

How to reproduce:

 1. Open the sample document (which is ODP, but the same can be 
    reproduced with PPTX).
 2. Save sample document as PPTX.
 3. Reopen just saved version.
 4. Observe how the empty line in each of the two list items
    suddenly is much bigger.

Observation: This only happens when the lines (= the second lines
in the list items) are empty; even a space character makes the issue
go away.


This is a regression somewhere between 7.1 and 7.2.

Seen with:

Version: 7.2.6.0.0+ / LibreOffice Community
Build ID: 3db1a060a033a2f84bdf798bed3c7e2515a498ce
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-2, Time: 2022-01-30_18:48:19

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 5c138ac6a8334825ef171ac6291b66b277eb4288
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Not seen with:

Version: 7.1.8.0.0+ / LibreOffice Community
Build ID: 4784990eda6098f0408276b4d424e81382a50460
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-10-15_11:37:03
Calc: threaded
Comment 1 Gerald Pfeifer 2022-02-02 09:07:20 UTC
Created attachment 177980 [details]
Visual comparison before (in LO) / after (same in LO and 365)
Comment 2 Gerald Pfeifer 2022-02-02 09:10:49 UTC
Bug #50831 looks to be about a similar issue with RTF export.

Bug #146690 looks like a duplicate at first sight, but doesn't seem to
be since I could already reproduce with LO 6.4, whereas the present bug
does not occur with 6.4, 7.0, or 7.1 in my testing, only 7.2 and 7.4.
Comment 3 Xisco Faulí 2022-02-02 11:50:27 UTC
Regression introduced by:

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

author	Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu>	2021-04-20 13:02:44 +0200
committer	László Németh <nemeth@numbertext.org>	2021-04-29 10:48:27 +0200
commit b6b02e0b4c9d739836e1f61a886ea45b01e6696e (patch)
tree 5a50d8696222361f7903a45f595dcdaab37c1917
parent 80d7bedee20eb191b1f5a6b2767630eb823d63b2 (diff)
tdf#111903 tdf#137152 PPTX export: fix placeholders

Bisected with: bibisect-linux64-7.2

Adding Cc: to Attila Bakos
Comment 4 Attila Bakos (NISZ) 2022-02-04 13:23:09 UTC
Created attachment 178058 [details]
Difference between PP and Impress

Well, there are so many problems. Not only the font size but the font-name, style, etc. is different in PP and Impress.
My fist idea is, (and you try it in PP that will prove this) the size is come from the master slide. If I change the size in PP from 44 to 20 for example, the empty paragraph will be smaller.
In case of Impress I have no idea where the 32 came from... because there is no placeholder in the master...
To summarize, i think this problem seems like if the font size information is missing in the xml and the two programs tries to guess it in two different way. This also can be proved with this xml part from slide1.xml:
...
<a:r>
 <a:rPr b="0" lang="en-US" sz="1800" spc="-1" strike="noStrike">
   <a:solidFill>
     <a:schemeClr val="accent1"/>
   </a:solidFill>
   <a:latin typeface="Poppins Medium"/>
 </a:rPr>
 <a:t>Open Source is about Collaboration.</a:t>
</a:r>
<a:br/>
<a:br/>
<a:r>
...

The above example shows there are two <a:br/> element after, without information  for size, however the previous run has the sz="1800" attribute so it is formatted directly what different from the master. This can be seen when i remove formatting in PP from the first line, that also become bigger.
Solution under consideration, and fixing. :)
Comment 5 Attila Bakos (NISZ) 2022-02-16 14:24:27 UTC
(In reply to Attila Bakos (NISZ) from comment #4)
> Created attachment 178058 [details]
> Difference between PP and Impress
> 
> Well, there are so many problems. Not only the font size but the font-name,
> style, etc. is different in PP and Impress.
> My fist idea is, (and you try it in PP that will prove this) the size is
> come from the master slide. If I change the size in PP from 44 to 20 for
> example, the empty paragraph will be smaller.
> In case of Impress I have no idea where the 32 came from... because there is
> no placeholder in the master...
> To summarize, i think this problem seems like if the font size information
> is missing in the xml and the two programs tries to guess it in two
> different way. This also can be proved with this xml part from slide1.xml:
> ...
> <a:r>
>  <a:rPr b="0" lang="en-US" sz="1800" spc="-1" strike="noStrike">
>    <a:solidFill>
>      <a:schemeClr val="accent1"/>
>    </a:solidFill>
>    <a:latin typeface="Poppins Medium"/>
>  </a:rPr>
>  <a:t>Open Source is about Collaboration.</a:t>
> </a:r>
> <a:br/>
> <a:br/>
> <a:r>
> ...
> 
> The above example shows there are two <a:br/> element after, without
> information  for size, however the previous run has the sz="1800" attribute
> so it is formatted directly what different from the master. This can be seen
> when i remove formatting in PP from the first line, that also become bigger.
> Solution under consideration, and fixing. :)

And, eventually i was able to reproduce it from scratch:
1) Create a blank Impress presentation in 7.4.
2) Go to master slide set the font size so large (60pt)
3) Return to slide mode and set the layout to Title and content, and set the content font size to low (12pt)
4) Type something ("first line") to the content field, hit ctrl+enter (make new line without creating new para) two times and type something again ("second").
5) Save to pptx
6) Reload
->The empty line will have different font size from the others, and that size will be the same what were set in the master (60pt).

Not seems to a real regression, because before there was no connection between the slide placeholder and the master placeholder, so that was impossible the inherit font size from the master (i think it was copied manually in other part of the program code). From the mentioned commit the slide placeholder connected to the master so it inherits its settings unless that is overiden by direct formatting. This issue rather seems to missing implementation, in the export filter where the font size should to be exported, but it is missing from the file. Due to this the programs apply the master setting. Fix soon.
Comment 6 Attila Bakos (NISZ) 2022-02-16 14:41:47 UTC
Created attachment 178310 [details]
The XML of PP and Impress, and the problem marked

And, my last comment is proved by this. :)
One thing left, modifying the filter.
Comment 7 Attila Bakos (NISZ) 2022-02-16 15:16:23 UTC
(In reply to Attila Bakos (NISZ) from comment #6)
> Created attachment 178310 [details]
> The XML of PP and Impress, and the problem marked
> 
> And, my last comment is proved by this. :)
> One thing left, modifying the filter.

fix is here: https://gerrit.libreoffice.org/c/core/+/130005
Comment 8 Commit Notification 2022-02-28 13:54:29 UTC
Attila Bakos (NISZ) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f29c14e8c36819296d0c66bb995201acf0a2647e

tdf#147121 PPTX: fix regression of font size export of empty lines

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.
Comment 9 Gerald Pfeifer 2022-03-03 16:17:58 UTC
Great job, thank you Attila!

I am happy to report that I validated the fix with today's dev-build:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: fb9270b238cba4f36e595c5d7f4d85f6f3f18e1c
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Comment 10 Gerald Pfeifer 2022-03-03 16:18:43 UTC
(And thank you for including a regression test case!)
Comment 11 Commit Notification 2022-03-07 09:56:58 UTC
Attila Bakos (NISZ) committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/2c06fba68d3cd194edfddf49cd2779c761b6bd38

tdf#147121 PPTX: fix regression of font size export of empty lines

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.
Comment 12 Attila Bakos (NISZ) 2022-03-07 12:26:55 UTC
You are welcome! :)