Created attachment 199540 [details] FixedCellHeight_affectingTable.pptx: the example document It is likely that the Marianne font is needed to really see this issue. The text is spilling out of the (properly sized) table. Marianne is a tall font - with lots of headroom for diacritics. It appears that PowerPoint probably forces a font-independent line-spacing for tables, just like it does for custom shapes. (See OOo bugzilla's issue 15927.) If that is true (and it definitely is related), then most useful will be commit d97d43b576cf091dc27cf3cf61522cc54eeef8e7 and following commits (and a few preceding commits too - but something is messed up with the commit order for "git log") Author: Oliver Bolte on Mon Sep 1 11:02:57 2003 +0000 #i15927# PowerPoint import: added font independent linespacing Steps to reproduce 1.) open FixedCellHeight_affectingTable.pptx The table must not be overlapping the textbox (and it isn't - keep it that way). The text should not be spilling out of the table cell. Notice that if you turn off the textbox's "Autofit: resize shape to fit text" (using PowerPoint), then the table grows so that the text is no longer spilling out of it. The mere existence of the textbox is currently affecting the table's layout (because the customShape-textbox's forced mbIsFixedCellHeight overlaps with the table import for a while). This was checked against master (25.8) and is inherited from OOo (checked 3.3). It is possible that fixing this will also fix bug 148041 (or alternatively it will create more situations where that kind of bug is exposed).
Created attachment 199541 [details] Marianne-Regular.otf: the font used in the document - a popular French font
Created attachment 199542 [details] FixedCellHeight_affectingTable.pptx_import-1.png overlay: RED=PowerPoint 2010, grayscale = LO 25.8 This overlay suggests that the table size is correct (or else there would be a block of red showing). LO's line spacing is clearly too much. However, when I do an overlay of a simple text document, the fonts overlay each other very well, so it doesn't seem to be a problem with the LO's interpretation of the font metrics themselves. It almost certainly is a Microsoft-ism of ignoring the actual font metrics and imposing a fake 20% line spacing based on the basic font height.
Maybe in relation tdf#103476
Created attachment 199584 [details] FixedCellHeight_affectingTableSz28.pptx: hand-mangled - font size increased from 14 to 28 I'm trying a few experiments to test the limits and extent of this special handling. My theory was that the given size of the table would be the ultimate factor - but this example proves that wrong. Powerpoint expands the table height to accommodate the larger sized font, but still has "too small" line spacing.
Created attachment 199586 [details] FixedCellHeight_affectingTableDouble.pptx: hand-mangled to force double spacing (and no other size changes) Theory 2: it only affects single spacing, or else all line spacing is forced to either be the same size, or else forced to fit inside the table cell? No, LO's double spacing still doesn't fit inside the table, despite increasing the table size to match PowerPoint. So yes, PowerPoint does again dynamically increase the table again, in order to handle the extra space needed for double spacing.
Created attachment 199692 [details] 165521_debugAnalysis.docx: possible code pointers? This is my debug output As part of hacking around trying to get SOME understanding of what the code is doing with FixedCellHeight_affectingTable.pptx, I was able to get the table to resize to fit the text (the same way it does when there is no customShape) with https://gerrit.libreoffice.org/c/core/+/182629. However, the since the table size is actually the right height, I have no idea how to tell the text to fit inside of the table.
WIP patches can be seen at https://gerrit.libreoffice.org/c/core/+/183130 https://gerrit.libreoffice.org/c/core/+/183131
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/feb3c03b70ac1534a187e390c3bc1604a919ce12 related tdf#165521 svx: avoid FormatFullDoc, SetFixedCellHeight first It will be available in 25.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c7c543e5f5a361d52dd0cc57379da4304bc3eb7f related tdf#165521 svx: don't start layout until text is set It will be available in 25.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/210c89a34bda429fe7e0b8f0e63ce5bb5add9d8b related tdf#165521 oox: ShapeExport::GetNewShapeID of at least 2 It will be available in 25.8.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.
Sorry - wrong bug that I marked as fixed.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0bd1df2d72bd62327dbbc8b39cc23e06c444f73a tdf#165521 svx layout: clear Outliner FixedCellHeight after use It will be available in 25.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a47776a938c4666d4618b5cbf20d4319f64a6ff4 tdf#165521 pptx layout: don't use font's leading for cells too It will be available in 25.8.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.
Every day I ask God to bless my work, and I'd like to acknowledge a few of those clear blessings seen with regards to this bug as I mark it as fixed. 1.) The bug document itself and the initial QA work gave a clear direction to the task. If not for early recognition that the table itself was the correct size, this would have simply been comment 12's "remove FixedCellHeight bleeding into the table from the custom shape" and that would have been the end of it (with almost certainly a substandard place for doing that). 2.) The encouragement and requirement from my work to keep plugging away on this task until it was done. 3.) At the last minute, a silly clang linker error in CI caused me to get out of the rut I had dug, showing I could drop https://gerrit.libreoffice.org/c/core/+/183131.