Created attachment 64382 [details] screen capture of proper format in PowerPoint A powerpoint page with two columns missing left column after opened in LibreOffice.
Created attachment 64383 [details] Screen capture of wrong display in LibreOffice
Created attachment 64384 [details] test case file
Also tested on LibreOffice 3.6.0.0.beta2 with the same result.
Thank you very much for your bug report, especially for the good documentation (sample file, screenshots)! REPRODUCIBLE on MacOS X 10.6.8 (Intel) both with * LibreOffice 3.5.5.3 (Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21) * LibreOffice 3.6.0.1 (Build ID: 73f9fb6) both with German langpack installed. Only the right colum of the slide is visible, just as you see on the reporter's screenhot (attachment 64383 [details]). Can someone else please test this on Windows and/or Linux? Thanks!
[Reproducible] with "LibreOffice 3.5.5.3. German UI/Locale [Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit), but we have had good progress here: 3.3 shows empty page and crashes when I try to edit 3.4 shows empty page and crashes when I try to edit 3.5 shows half of contents (as reported) and crashes when I try to edit contents placeholder 3.6 shows half of contents (as reported) and crashes when I try to edit contents placeholder Works fine for reported problem with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 25608fb]" (tinderbox: 2008R2@20, pull time 2012-07-14 00:31:17), and no longer crashes when edit placeholders. @Roman: I hope you can confirm WFM with Master?
(In reply to comment #5) > I hope you can confirm WFM with Master? Yep; LOdev 3.7.0.0.alpha0+ (Build ID: 042686d, Date: 2012-07-19_10.04.11) opens and displays the sample file without any problems -- this is to say, both columns are visible and editable (as far as a quick test can show). So this issue is really fixed on master branch, wonderful! @Rainer: I'm a bit hesitant about marking this one as WFM, given the fact that the 3.7 release is still more than 6 months away from now; what means that, for normal users, it will *not* work for another 6 months ... But if this is the usual way to proceed, I will not object. Maybe we could ask the developers to backport (if possible) the fix to, let's say, 3.6.1 or 3.6.2? (The difficulty is, however, to find out which commit(s) fixed this!)
> I'm a bit hesitant @Roman Eisele: Hi, me too. If I would know the fix I would have asked for a cherrypick for 3.6, but without this knowledge it might cost a lot of time, also for a developer. My current rating for this Bug is that the fix can wait until 3.7.0, be cause currently only 1 user with 1 document is known who has this problem. If we get DUPs or you or Andika Triwidada have indications that this one's importance is major because the problem affects an often used feature, we should involve Rodo or Thorsten. But of course my rating is a private opinion, if you see more importance please feel free to involve a developer (and may be do an additional attempt to find a similar Bug or even a commit for what the fix brought the breakthrough). Would be great to have bibisecting for Master 3.7 ... .
@Rainer Bielefeld: > If I would know the fix I would have asked for a cherrypick for 3.6, but > without this knowledge it might cost a lot of time You are definitely right here. I did a quick scan of the git log yesterday, but I could not find any commit message which looks especially promising ... > My current rating for this bug is that the fix can wait until 3.7.0, > be cause currently only 1 user with 1 document is known who has this problem. The imporantance of this bug is really hard to judge. I did a Google search for "filetype:pptx", scanned some of the top results and found only few pptx files which looked similar (had a real two-colum layout). This would support our current rating. > If we get DUPs or you or Andika Triwidada have indications that this one's > importance is major because the problem affects an often used feature, we > should involve Rodo or Thorsten. So I have no indications for special importance of this bug, and I agree that "waiting for DUPs" may be the best strategy to deal with this issue for now. At least, it saves us and especially the developers from unnecessary work ;-) @Andika Triwidada: Have you got any indications that PowerPoint slides with similar layouts like your example are frequently used? I mean, have you seen more PowerPoint slides similar to your sample file? Or is this complicated layout rather an exception? Thank you!
@Roman Eisele: For me it is frequent enough, but I can't say for others. Fix for me is not needed asap. I can wait for 3.7, because I usually try to edit PowerPoint files always in PowerPoint and LO files always in LO. Thanks for great work guys!