Created attachment 181763 [details]
Visual comparison presentation mode (bug shows) vs edit mode

Repro with

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 641d92a73e5b3d0e062e16ed4b42236e1a4796a5
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL

Not repro with

Version: 7.2.6.2 / LibreOffice Community
Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded

BTW also repro with

Version: 7.3.5.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1
Calc: threaded

This seems to have begun at the below commit.
Adding Cc: to Armin Le Grand; Could you possibly take a look at this one?
Thanks
 af064b4dee052d8808fb08dbe3610e095cdca181 is the first bad commit
commit af064b4dee052d8808fb08dbe3610e095cdca181
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Feb 2 10:05:12 2022 +0100

    source 4d535c4f867d86d40786788e5e5c9fd061a65673

https://git.libreoffice.org/core/+/4d535c4f867d86d40786788e5e5c9fd061a65673

Same regression commit as bug 147576.

(In reply to Justin L from comment #6)
> Can you create a clean-room ODP example?

You are right; I managed to simplify and create a plain ODP file.
Verified that it's still a regression there, too.

Created attachment 182243 [details]
Simplified sample slide (ODP)

Took a look, this *is* very strange.
1st thought all objs on masterpage might be wrong scaled, but no - only the one in the PageNumber field.
CCing that to page (so not MasterPage) shows the same error.

Inserting new PageNumber fields on master & page do *not* show that error.
Inserting *any* other field on MasterPage or Page does *not* show the error.

Original file is a *.pptx file, so it looks like an import error - some properties are not set correctly....?

Checked on Win due to the FontSize defs are different on the system-dependent side, but same effect there.

Reverted locally (git revert 4d535c4f867d86d40786788e5e5c9fd061a65673) to check if that's really causing it - it is. Thus it might be a problem with the BoundRect (?)

Debugging now old and curr version in parallel, I indeed get different Bounds for the same TextObject (with the funny name "Foliennummernplatzhalter 28"):

old: 1410/17380/1952/19145
new: 1410/17380/1952/17733

Same width, but different height. Looking for reason(s)...

Could reproduce with own inserted shape now.

Load bugdoc fontsizediff.odp, change to MasterView, select PageNumberField-Object bottom-left (the one that causes trouble), open Dlg "Position and Size".

You see that 'Fit width to text' and 'Fit height to text' is off. You also see that the text "<number>" is formatted in Obj's width, but vertically - because the Obj cannot grow with text. It's vbisible with the "<number>" text on MasterPage, but also happens when the text is replaced by "1" on the Page. If you insert more slides (CTRL+M) starting with Slide "100" that wrong formatting is also on the Page.

When inserting an own one (Insert/Field/Slide Number) you see it's much bigger, also contains <number>, but since bigger is well-formatted on MasterPage, also on Page.

You cannot make it smaller as "<number>" needs as space, opening Dlg shows that 'Fit width to text' and 'Fit height to text' are both SET. That's the difference.

You can switch those off, then make it smaller and get the same error as with the imported one from *.pptx, the strange formatting AND the scale-error in Slideshow.

-> Possible solution (a): Imported fields could be adapted to:
  - switch 'Fit width to text' and 'Fit height to text' OFF
  - or guarantee that text fits into them

Switching off for the imported Obj immediately expands it horizontally to fit "<number>" text, while keeping the extended but not officially applied height  (?), it works in Slideshow.

Question is now: Why did it work before?
Partial answer I can already give is two-folded:
(b) with the fix for tdf#126319 the BoundRect (the now smaller one) is more correct than before.
(c) the text flows over the BoundRect of the TextObject *by purpose* (see as it is on the MasterPage), that was AFAIR another compatibility-fix. It also seems as if the BoundRect for the text "<number>" is used what is an error.
(d) independent from c being an error the MetaFile gets it's PrefSize set to that wrong Bounds. The Slideshow then scales the Metafile content to it's PrefSize -> error with the scaled content.

How to fix that? There is a (switched off) possibilty to clip text content against TextBox size (as mentioned, that was another fix). Since paint works for normal EditView including invalidate there *must* be some code somewhere doing this 'extended' BoundRect handling. If I can identify this I can try to adapt that for creating the MetaFile for the Presentation, too.

Note: All that would not be needed if Slideshow would just use Primitives nowadays - the problem is the Metafile and it's PrefSize magic...

This is very strange - if I *force* a re-calculation of BoundRect in reverted code

                    tools::Rectangle aR1(pObj->GetCurrentBoundRect());

I *also* get the new values (1410/17380/1952/17733) and the error in slideshow. That means it only worked before that other fix because that Bound was calculated at SdrObject before and not invalidated(!) for a change that would have needed invalidation.
Now I would need to find out why and when that obviously wrong but working values were originally calculated (!?)

The m_aOutRect is only calculated once after doc load (in view init/hit test due to BoundRect being requested there 1st time). It gets calculated indeed for the string "<number>".
Looking at the SdrPage of the SdrObject it gets calculated for shows that it's a MasterPage, so that would be correct.
There is indeed no SdrObject on the Page representing the replaced PageNumber ("1"), but this would have to be done/recalculated/used when the Page in ditView is shown.
It seems this has used the once calculated m_aOutRect based on string <number> all the time. That m_aOutRect indeed is never reset or recalculated, the SdrObject *is* in the Background when the EditView shows the Page. If the EditView shows the MasterPage, using that string is correct.

The Primitives are more clever and need (and do) that replacement of placeholders in the fields, else the EditView showing the Page would not show the "1". The fix tdf#126319 uses the Primitives, so uses the *correct* BoundRect for an EditView of page "1" being prepared to be shown in the PresentationEngine.

I will have to find a way that the PresentationEngine runs/works with that correct BoundRect.

Did I mention that all that would not be needed if PresentationEngine would use Primitives - as is suggested in tenders since YEARS...?

Problem is two different BoundRects get used for the same XShape:
(1) The one containing text "<number>"
(2) The one containing replacement text "1"
The Metafile for the presentation uses (2), so geometry content is correct all the time.
The DrawShape::DrawShape in slideshow/source/engine/shapes/drawshape.cxx that prepares the shape for presentation uses
  maBounds( getAPIShapeBounds( xShape ) ) -> leads to (1)
and
  mpCurrMtf = getMetaFile(...) ->> leads to MTF with PrefSize from (2)

Before the fix tdf#126319 the PrefSize from the MTF was also from (1). Since both used the (wrong) Bounds from MasterPage, the Transformation built by the SlideShow worked.

Since fix tdf#126319 the PrefSize from the MTF is based on (2), so fits the content and is correct. Thus the Transformation built by the SlideShow now *scales* the correct content with the correct PrefSize to the size of the wrong Bounds of the XShape on the MasterPage.

-> problem is that maBounds( getAPIShapeBounds( xShape ) ) leads to (1). When correcting this hard numerically in debugger all is correct.
-> using UNO API to get the XShape bounds does return the MasterPage Bounds. There is no way to get the Bounds View-dependent.

That is the core problem: The Bounds of that XShape *are* view-dependent, so any kind of info what XPage is displayed/processed when the Bound of that Shape is processed  would be needed. In principle the SlideSHow knows which XPage it displays, but there is no UNO API way to get the view-dependent Bounds for that -- that is simply not provided in the concept, but *needed* for any Text that may contain variably expanded Fields.
The Primitives offer that by allowing to define the XPage in the ViewInformation when creating/processing, but -as stated - we do not use Primitives here yet.

The correct fix would need to 'somehow' get the view-dependent Bounds using the UNO API in getAPIShapeBounds( xShape ). That is unfortunately out of question for fixing this, so I have to think/dig deeply how to fix this...

A rough and working fix would be:
----
diff --git a/slideshow/source/engine/shapes/drawshape.cxx b/slideshow/source/engine/shapes/drawshape.cxx
index ba6f2b0cbfb2..46b8adf7ea7e 100644
--- a/slideshow/source/engine/shapes/drawshape.cxx
+++ b/slideshow/source/engine/shapes/drawshape.cxx
@@ -389,6 +389,22 @@ namespace slideshow::internal
             if (!mpCurrMtf)
                 mpCurrMtf = std::make_shared<GDIMetaFile>();
 
+            if(mpCurrMtf && !maBounds.isEmpty())
+            {
+                const double fWidthDiff(fabs(mpCurrMtf->GetPrefSize().Width() - maBounds.getWidth()));
+                const double fHeightDiff(fabs(mpCurrMtf->GetPrefSize().Height() - maBounds.getHeight()));
+
+                if(fWidthDiff > 1.0 || fHeightDiff > 1.0)
+                {
+                    maBounds = basegfx::B2DRange(
+                        maBounds.getMinX(), maBounds.getMinY(),
+                        maBounds.getMinX() + mpCurrMtf->GetPrefSize().Width(),
+                        maBounds.getMinY() + mpCurrMtf->GetPrefSize().Height());
+
+                    bool bBla = true;
+                }
+            }
+
             maSubsetting.reset( mpCurrMtf );
 
             prepareHyperlinkIndices();
----
This implies that *always* the PrefSize of the Metafile is more correct than the getAPIShapeBounds size of the XShape. That contains the view-dependent Bound of the XShape.
This is probably too rough. It is possible to detect the error as seen above, it  it would be possible to check for
- XShape has Text
- Text has Fields
or, alternatively
- get the Seq of Primitives
- calculate the true Bounds locally from them
- what would need to link slideshow against drawinglayer which is not yet done but would need to be done anyways when once (hopefully) in the future change to primitives.

Have to discuss with someone with deeper knowlege of slideshow...

*** Bug 150934 has been marked as a duplicate of this bug. ***

Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1b0ff1c166211b34370f53995ae9fb3f8eed182e

tdf#150402 Correct wrong Bound of Shape in Slideshow

It will be available in 7.5.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.

Created attachment 182566 [details]
Another self-constructed bugdoc demonstrating the problem (before it gets lost)

Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/8cefc95845c585d830f642a8d6a575863e75b987

tdf#150402 Correct wrong Bound of Shape in Slideshow

It will be available in 7.4.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.

Thank you, Armin. Great detective work!

And happy to confirm that with

  Version: 7.5.0.0.alpha0+ / LibreOffice Community
  Build ID: e79741488cc740f49ebd4426c40b45e7139ff663
  CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US

both of my sample documents from this report render fine for me now
again in presentation mode.

*** Bug 147576 has been marked as a duplicate of this bug. ***

Do you want to close this bug, Armin, or would you prefer me to do so
based on my validation as original reporter?

Thank you, Armin!  This bug bit me as well, although I was only able to find this bug report when it was mentioned in the 7.4.2 RC1 "Bugs fixed" list.  I can gladly report that the bug is gone in my reproducing ODP files as well.  (Manual LO 7.4.2 installation on Ubuntu 22.04/x86-64)