Open attachment 57492 [details] [Actual] some unreadable text at the top of slide [Expected] no unreadable text as in PowerPoint Tested in Windows XP with official 3.6 beta 1
Created attachment 62838 [details] screenshot in 3.6.0 beta1
Created attachment 62839 [details] screenshot in powerpoint 2007
Could you attach any example documents to allow others to check on different system/build?
Sorry that I didn't write this clearly in comment 0, but please use attachment 57492 [details]. Thanks!
(In reply to comment #4) > Sorry that I didn't write this clearly in comment 0, but please use attachment > 57492 [details]. Thanks! This is an attachment of bug 46487, which is in RESOLVED WORKSFORME state. Does this mean, that your problem was not resolved, as stated in https://bugs.freedesktop.org/show_bug.cgi?id=46487#c1?
(In reply to comment #5) > Does this mean, that your problem was not resolved It is a *different* problem. Original problem in bug 46487 is "No images are showing up", but this bug is about "some unreadable text at the top of slide". Please see screenshot comparing LibO and PowerPoint. Thanks again.
For the "unreadable texts" problem, I checked again in Windows XP [REPRODUCIBLE] in official 3.5.0 beta2 and 3.5.3 [NOT REPRODUCIBLE] in official 3.4.4 regression, also set version field accordingly
Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Text field with stacked texts present as on screenshot. Field is deletable, but LO is quite unresponsive while working with it.
(In reply to comment #8) > Confirmed with: Thanks! Set as NEW. > Text field with stacked texts present as on screenshot. Field is deletable, but > LO is quite unresponsive while working with it. Yes, I confirm this. Anyway, checking again, I find that this problem is solved in master, but not in libreoffice-3-6 branch. It is solved between build from tinderbox W2008R2@16-minimal_build, pull time 2012-06-24 23:37:39 and 2012-06-26 13:20:00. Commit range is http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=555a8955c71f28f93b032e8dd2c627ab3e794b02..13b6a02ed34e469faa2530537b1595e7f06459d3
Checking on Fedora 15 x86_64 with build from tinderbox Linux-Fedora15-x86_64@4-gcc-4.6-dbgutil; the problem is solved between pull time 2012-06-24 22:37:03 (d4e2a95a2f7376c36c1241f91a55021fc856c758) and 2012-06-25 23:42:59 (ff27d84e08951660edb77938db6ee7dbf806f4f8&). Intersecting with range in comment 9, we get http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=555a8955c71f28f93b032e8dd2c627ab3e794b02..ff27d84e08951660edb77938db6ee7dbf806f4f8
With my own build on Windows XP at 34513fe619aee112b11a0a90dc2e981dccdb408e (May 6, 2012) master branch, with following patches: * 25dd603fe2044f35341fe0c6d0b632c9295a824e n759982: Win/VC++ stl messes up the namespace vector. ** This is to make importing correct, not related to this bug. * 1309edf3f90882d24c58ade83debce5d85e8b3bb n#759210: Certain smartart drawings weren't imported. The problem is solved. I didn't test the build in -3-6 nor -3-5 branches. @Muthu, is your patch 1309edf3f90882d24c58ade83debce5d85e8b3bb safe enough for both stable branches?
(In reply to comment #11) > * 1309edf3f90882d24c58ade83debce5d85e8b3bb n#759210: Certain smartart drawings > weren't imported. Aw, this should be 11c5699dad06fb0d7fc0e458550a1dac82f8ee5f. Sorry.
@Korrawit: Sorry for the delayed reply, I somehow felt I had commented on this. Yes, the patch should be safe for 3-6 and 3-5 if required. (Nevertheless, this may not be a regression. This was missed out of the smartart import feature)
As the patch was pushed in master (will be 3.7) (see comment 12), I mark this as FIXED and set target accordingly. Anyway, the mail asking for review for 3.6 and 3.5 still have no reply ... http://nabble.documentfoundation.org/REVIEW-3-6-3-5-n-759210-Certain-smartart-drawings-weren-t-imported-td3994683.html
(In reply to comment #14) > http://nabble.documentfoundation.org/REVIEW-3-6-3-5-n-759210-Certain-smartart-drawings-weren-t-imported-td3994683.html Pushed to -3-6 and -3-5 => set target accordingly.