Issue 47134

Created attachment 24909 [details]
ppt presentation

Created attachment 24910 [details]
screenshot

Reassigned.

I can' t reproduce the bug.
I see the bug in the screen shot you attached but your document looks correct.
Do I've to do something special?

After opening the file attached click on the tabs above the display of the 
slide. Normal, outline, handouts and slide sorter. 

That is exactly what I did.
What Windows (language) do you use.
It is possible that this bug depends on the system fonts.

Set to new and change the status

You said you found an area where this could happen.
Please have a look.

Have to check the sd::slidesorter::view::FontProvider class if it can create a
font with such a wrong size.

The testing was done on a OOo 1.9m91 on Hebrew Windows XP

*** Issue 49395 has been marked as a duplicate of this issue. ***

See issue 49395 for attached documents.  I have been able to reproduce the bug
with them under Linux.

The FontProvider is called with two different devices, one of which has a font
set that is too large.  This may be due to double buffering in the drawing
layer.  The GetFont() method seems to be called with the actual content window
only by PageObjectViewObjectContact::CalculatePageNumberAreaModelSize() when the
size of that window changes.  

Maybe it would be sufficient to change the font returned by GetFont() only on
such occasions.  At the moment on every call to GetFont() the map mode of the
given device is compared to the one given in the previous call to that method.

We have finally found out what happens here:
The ObjectContactOfPageView, which paints the page containing the slide
previews,employs some kind of double buffering.
For this it uses a VirtualDevice whose font is initialized from
Application::GetDefaultDevice().GetFont().
In some rare cases the Writer directly modifies the size of this font. Together
with its map mode the font size is OK.
The sd::slidesorter::view::FontProvider uses the map mode of the slide sorter
view but takes the font, together with the size set by the Writer.  In
combination this leads to characters 200 pixel large.

Please take over.

FME: I'm not fully convinced that issue 49395 is a duplicate of this one. i49395
only occurs in the (very rare) case, that Writer changes the application default
device. I suggest to reopen i49395 and have another look at this one.

FME->AF: As discussed, please take over again.

I will check whether this is a duplicate, or not.

I still think that issue 49395, or something very similar, is responsible for
the font problems.  But to be on the safe side and because it is the cleaner
aproach anyway I changed the FontProvider::GetFont() method to take the font
from the style settings of the application.  There were some minor problems with
setting up its height correctly: the height of the font is set in point (pica or
didot?) which have to be transformed to pixel and into the logical coordinate
system.
 
Affected files:
/sd/source/ui/slidesorter/inc/model/SlsPageDescriptor.hxx    rev. 1.4.276.1
/sd/source/ui/slidesorter/view/SlsFontProvider.cxx    rev. 1.2.68.1
/sd/source/ui/slidesorter/view/SlsLayouter.cxx    rev. 1.5.44.1
/sd/source/ui/slidesorter/view/SlsPageObjectViewObjectContact.cxx    rev. 1.8.62.1

*** Issue 50230 has been marked as a duplicate of this issue. ***

Created attachment 27131 [details]
Screenshot showing the defect in fresh installed m108 german

Reopening and setting target to OOo 2.0

Integrated into CWS impress62:
/sd/source/ui/slidesorter/inc/model/SlsPageDescriptor.hxx    rev. 1.4.306.1
/sd/source/ui/slidesorter/view/SlsFontProvider.cxx    rev. 1.2.100.1
/sd/source/ui/slidesorter/view/SlsLayouter.cxx    rev. 1.5.76.1
/sd/source/ui/slidesorter/view/SlsPageObjectViewObjectContact.cxx    rev. 1.8.94.2

Back to QA for verification.

re-open issue and reassign to cgu@openoffice.org

reassign to cgu@openoffice.org

reset resolution to FIXED

Verified in cws impress62

Closing.