Issue 47134 - The display of the slide numbers is wrong
Summary: The display of the slide numbers is wrong
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: 680m91
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: christian.guenther
QA Contact: issues@graphics
Keywords: needmoreinfo
: 50230 (view as issue list)
Depends on:
Reported: 2005-04-11 09:47 UTC by Unknown
Modified: 2005-07-26 16:11 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

ppt presentation (63.50 KB, application/
2005-04-11 09:48 UTC, Unknown
no flags Details
screenshot (70.99 KB, application/vnd.sun.xml.draw)
2005-04-11 09:50 UTC, Unknown
no flags Details
Screenshot showing the defect in fresh installed m108 german (14.17 KB, image/png)
2005-06-13 14:14 UTC, ansorg
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2005-04-11 09:47:30 UTC
In a presentation, when in editing mode, in "Normal view" and "slide sorter" 
view, the display of the slide numbers are not correct. In "Normal view" the 
slide numbers are very big. In "Slide sorter" view the slide numbers are big 
and misplaced. This changes when you switch between the modes. This happens 
with an imported ppt presentation and with a new presentation created in OOo 
1.9m91 on Windows xp
Comment 1 Unknown 2005-04-11 09:48:15 UTC
Created attachment 24909 [details]
ppt presentation
Comment 2 Unknown 2005-04-11 09:50:32 UTC
Created attachment 24910 [details]
Comment 3 wolframgarten 2005-04-11 11:18:43 UTC
Comment 4 christian.guenther 2005-04-11 16:48:50 UTC
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?
Comment 5 Unknown 2005-04-12 08:00:57 UTC
After opening the file attached click on the tabs above the display of the 
slide. Normal, outline, handouts and slide sorter. 
Comment 6 christian.guenther 2005-04-12 16:19:13 UTC
That is exactly what I did.
What Windows (language) do you use.
It is possible that this bug depends on the system fonts.
Comment 7 christian.guenther 2005-04-12 16:24:12 UTC
Set to new and change the status
Comment 8 christian.guenther 2005-04-12 16:25:40 UTC
You said you found an area where this could happen.
Please have a look.
Comment 9 groucho266 2005-04-12 17:13:34 UTC
Have to check the sd::slidesorter::view::FontProvider class if it can create a
font with such a wrong size.
Comment 10 Unknown 2005-04-13 08:08:34 UTC
The testing was done on a OOo 1.9m91 on Hebrew Windows XP
Comment 11 groucho266 2005-05-19 13:53:15 UTC
*** Issue 49395 has been marked as a duplicate of this issue. ***
Comment 12 groucho266 2005-05-19 13:54:55 UTC
See issue 49395 for attached documents.  I have been able to reproduce the bug
with them under Linux.
Comment 13 groucho266 2005-05-19 17:09:00 UTC
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.
Comment 14 groucho266 2005-05-23 13:35:07 UTC
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
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.
Comment 15 groucho266 2005-05-23 13:35:49 UTC
Please take over.
Comment 16 frank.meies 2005-05-25 12:59:16 UTC
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.
Comment 17 groucho266 2005-06-01 10:29:24 UTC
I will check whether this is a duplicate, or not.
Comment 18 groucho266 2005-06-01 16:55:10 UTC
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
Affected files:
/sd/source/ui/slidesorter/inc/model/SlsPageDescriptor.hxx    rev.
/sd/source/ui/slidesorter/view/SlsFontProvider.cxx    rev.
/sd/source/ui/slidesorter/view/SlsLayouter.cxx    rev.
/sd/source/ui/slidesorter/view/SlsPageObjectViewObjectContact.cxx    rev.
Comment 19 christian.guenther 2005-06-02 10:45:37 UTC
*** Issue 50230 has been marked as a duplicate of this issue. ***
Comment 20 ansorg 2005-06-13 14:14:45 UTC
Created attachment 27131 [details]
Screenshot showing the defect in fresh installed m108 german
Comment 21 groucho266 2005-06-28 16:08:32 UTC
Reopening and setting target to OOo 2.0
Comment 22 groucho266 2005-06-29 09:35:50 UTC
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.
/sd/source/ui/slidesorter/view/SlsLayouter.cxx    rev.
/sd/source/ui/slidesorter/view/SlsPageObjectViewObjectContact.cxx    rev.
Comment 23 groucho266 2005-06-29 16:36:48 UTC
Back to QA for verification.

re-open issue and reassign to
Comment 24 groucho266 2005-06-29 16:36:52 UTC
reassign to
Comment 25 groucho266 2005-06-29 16:36:57 UTC
reset resolution to FIXED
Comment 26 christian.guenther 2005-07-04 11:11:48 UTC
Verified in cws impress62
Comment 27 groucho266 2005-07-26 16:11:34 UTC