Issue 102637 - After updating to 3.1: printed slides are no longer framed
Summary: After updating to 3.1: printed slides are no longer framed
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: printing (show other issues)
Version: OOo 3.1
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-10 11:42 UTC by sp908
Modified: 2009-07-30 11:30 UTC (History)
1 user (show)

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


Attachments
Patch with fix (763 bytes, text/plain)
2009-07-03 18:11 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description sp908 2009-06-10 11:42:34 UTC
I updated from 3.0.1 to 3.1, loaded a presentation I last worked on with 3.0.1.,
and printed handouts with 2 slides on a page.

I noticed that the slides are unfortunately not framed any longer in the output.

This effect has been reproduced by at least one other user, see
http://user.services.openoffice.org/en/forum/viewtopic.php?f=10&t=19555

This was a showstopper, because I had to produce handouts for a commercial
seminar, and the missing frames makes them look unprofessional.

This is the third time for me that a new stable release version of OO.org
introduced a problem in Impress that impairs a previously flawlessly working
feature (stable releases should really not do that).
Comment 1 wolframgarten 2009-06-10 11:57:17 UTC
Reproducible. Reassigned.
By the way: did you test the developer builds and the release candidates before
the final version? This would have been a way of finding these kind of problems
earlier..
Comment 2 clippka 2009-06-22 09:24:10 UTC
reassigned
Comment 3 sp908 2009-06-22 09:33:09 UTC
No, testing the developer builds and the release candidates is unfortunately
only very rarely an option for me, for various reasons.
Comment 4 Armin Le Grand 2009-07-03 16:39:40 UTC
AW: Taking a look. In OOO310 m12, inside the primitive creation callback, no
geometry at all is created for the SdrPage objects. Getting a DEV300 m29 SD,
adding some debug and taking a look who/where that frame was painted at all in
the 3.0 version...
Comment 5 Armin Le Grand 2009-07-03 17:48:12 UTC
AW: Frame is painted at ViewContactOfPageObj::PaintObject when
if(!(rDisplayInfo.OutputToPrinter() && !pPage)) is true. Thus, when printing, a
frame is painted when pPage is set. Checking OOO310 m12 code...
Comment 6 Armin Le Grand 2009-07-03 17:54:35 UTC
AW: Indeed, the ViewObjectContactOfPageObj::createPrimitive2DSequence which is
responsible for primitive creation only has a
if(!GetObjectContact().isOutputToPrinter()) condition for adding the frame.
Adding '|| pPage' condition and taking a look...
Comment 7 Armin Le Grand 2009-07-03 18:10:49 UTC
AW: Compared all cases between DEV300 m29 and OOO310 m12: Page pane, notes view,
handout view, Slide sorter, print (with all 4 variations), export to PDF (with
handouts). All looks the same as in 3.0 with that change.
To make sure i re-compared with unchanged OOO310 m12: Error is in printing
handouts and in printing notes. No error in PDF export with slides (noprinter
used). Adding patch to this task..
Comment 8 Armin Le Grand 2009-07-03 18:11:26 UTC
Created attachment 63356 [details]
Patch with fix
Comment 9 Armin Le Grand 2009-07-06 10:22:23 UTC
AW: Discussed with QA, adding to CWS aw074, changing target to 3.1.1. Done.
Comment 10 Armin Le Grand 2009-07-06 16:42:54 UTC
AW: Ckecked with wntmsci12.pro build, works as expected.
Comment 11 Armin Le Grand 2009-07-07 09:57:11 UTC
AW->WG: Please review as described.
Comment 12 wolframgarten 2009-07-09 09:25:29 UTC
Verified in CWS.
Comment 13 wolframgarten 2009-07-30 11:30:46 UTC
Tested in m17. Closed.