Created attachment 106903 [details] A draw file containing two text-filled polygon objects Problem description: In OpenOffice draw module (4.1.1), as in all previous version, you can use a polygon object to obtain to create a text that fill an arbitrary shape, and it is then easy to modify the polygon shape with the text that adapts to it dinamically. In LibreOffice 4.3.2 this is not working anymore: the same polygon object filled with text looks completely empty at first, however the text is there because if you double click on the object, then press crtl+A to select all then copy and paste in a text doc, you get the hidden text. I have many files created with OO draw in the past with a large use of polygon objects to manage text in flexible shapes, and they are completely unusable now with LO. I am not sure since which release of LO this regression is present, since I have not used these files in the last year. Steps to reproduce: 1. open the attached file in Openoffice, any release (or older LO releases, results may vary with these). The page contains two polygon objects filled with text that adapts to the polygon shape. The only difference is that the right one does not have a background nor a contour line. Text is visible, try editing the polygon points and see the text adapting to the changes. 2. Now open the same file with LO 4.3.2; you see no text at all, and the object on the right is invisible since it should show only the contained text. If you edit the polygon shapes, nothing happens to the text that remains invisible. 3. you can also create a new polygon and insert some text (a few paragraphs), which at first will be visible but exceed the polygon shape; when you set it to adapt to the contour, the text disappears. Besides the problems with already existing files that are unusable (fortunately they are not corrupted, if you save them with LO and then reopen them with OO the text is there), I could not find another way to obtain the same results without using polygon objects in Draw. Operating System: Windows 7 Version: 4.3.2.2 release
I see the error too in Version: 4.4.0.0.alpha0+ Build ID: 5aeb852efcabdd51545d5d41c92f4bf3cef1d663 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-08_07:01:57 It was correct in Version: 4.2.5.2 Build ID: 6ff819b65674ae6c83f3cbab9e4a4c2b292a7a94 on Windows7.
It is broken too in 4.3.0.0.alpha1+ Build ID: 145f2e970f46a3a3e5456b122d71f17c3abe878f TinderBox: Win-x86@42, Branch:master, Time: 2014-04-26_23:32:36
Working in the bibisect-43all repository, I see from `git bisect bad`: 206506b5a81e183bfab960d6abe62489c8438daf is the first bad commit commit 206506b5a81e183bfab960d6abe62489c8438daf Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun May 11 08:41:16 2014 +0000 source-hash-47811d4cf17688b2db5910e2cd500143137fd6f1 commit 47811d4cf17688b2db5910e2cd500143137fd6f1 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Mon Feb 3 14:14:26 2014 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Mon Feb 3 16:05:11 2014 +0100 Remove SC_DLLPRIVATE -> SAL_DLLPRIVATE indirection Change-Id: I1360a96ebe33bd6d70ac7728844c4ba1137e51ab :100644 100644 5b474b38f50966351e24f947438fe5c5069517f7 3d3c3e89bc6ce55729a3f7156051928798021819 M ccache.log :100644 100644 a3fd0980c9745a4955053f7379284d92ac762c9e 94f6b2d78099d51d4c1555084912fc785cbb1e86 M commitmsg :100644 100644 250e6ec1dd90fc56a556820e4224a2172bbaf996 91055e0134afbd67da71b742d1b94f10a8f1a722 M make.log :040000 040000 155c2bf3bfc627df46fd3d59458da97e6b0356dc e3e391c3d3688aec478adb107e42ed4a144f0cab M opt and from `git bisect log`: # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # skip: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect skip e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # skip: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f git bisect skip 9daa289e178460daaafa4b3911031df5b8736218 # good: [387dd1052972d27a3065a249b357e50e0a29829b] source-hash-35836f350861b33a0c28307a413eff76d0433d1e git bisect good 387dd1052972d27a3065a249b357e50e0a29829b # bad: [d430de9e19582f813f509a2c7ad3fbea51bef646] source-hash-45441c0a7ff182ba429ca10d7cfa563fc49db1f7 git bisect bad d430de9e19582f813f509a2c7ad3fbea51bef646 # good: [6f7541cf54e32992fe5e0cee84f9a7b17c378b76] source-hash-e11a80d0be9db1e8cc1054d166638a99e89defea git bisect good 6f7541cf54e32992fe5e0cee84f9a7b17c378b76 # good: [65883fecdd4e5ccd4091d0089742690dccafdbfa] source-hash-8d8a2f2be58529d70f4783d5d1e91fca350f119f git bisect good 65883fecdd4e5ccd4091d0089742690dccafdbfa # bad: [c7510097bb94f2e426e03f2f83da2f508287ca0c] source-hash-87f52352614aed918501e8a7df8e8a61499efc5b git bisect bad c7510097bb94f2e426e03f2f83da2f508287ca0c # skip: [7055a406c05b6da54733841dd0174c91d35f8652] source-hash-f985e3add3870c1dee7fe88d37388281a333403a git bisect skip 7055a406c05b6da54733841dd0174c91d35f8652 # skip: [c9046ea7e069426d10e071d0bcb01c64685844c6] source-hash-f5115e33e4c5e49e9b79ed32fccc193a99c3dc30 git bisect skip c9046ea7e069426d10e071d0bcb01c64685844c6 # bad: [19163314fd465d533ab673977290f07ac45a3103] source-hash-e45c729da21c6923032b64c543136efe066b756a git bisect bad 19163314fd465d533ab673977290f07ac45a3103 # good: [1f32fb58159d7f43a4bcb838765261d5274cbf38] source-hash-4a169e4203c10ec8f76b9bcb33882c82b65c7bab git bisect good 1f32fb58159d7f43a4bcb838765261d5274cbf38 # bad: [90ec074ec2d27d01be33827b8143f231c5d9776a] source-hash-202d721e3cb35eb4402882dbe4b81ceccd9f4e0a git bisect bad 90ec074ec2d27d01be33827b8143f231c5d9776a # bad: [206506b5a81e183bfab960d6abe62489c8438daf] source-hash-47811d4cf17688b2db5910e2cd500143137fd6f1 git bisect bad 206506b5a81e183bfab960d6abe62489c8438daf # first bad commit: [206506b5a81e183bfab960d6abe62489c8438daf] source-hash-47811d4cf17688b2db5910e2cd500143137fd6f1 Bug 82501 is similar and seems to appear in the same interval, but I am unable to follow the STR in the later version of LibreOffice. Terry.
Today I installed 4.3.3 hoping this regression to be solved, but it is sadly still there... At the moment I have had to put all work on files containing polygon objects on stand-by, since in the present situation it is totally impossible to do anything. Any idea about when this could be addressed? Thanks,
The behaviour seems to have changed from the below commit. Adding Cc: to nthiebaud@gmail.com. Could you possibly have a look at this? Thanks commit 3cbfcee36dd16e451d76c561eaaaee0ff29b01a5 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Feb 2 22:16:48 2014 -0600 xub_StrLen and tools/string.hxx final straw Thre is still some 0xffff limit left and possibly some less than gracefully handled overflow/error cases Change-Id: I00957ee3a30b02f73918ea49d7353056263dc638 Reviewed-on: https://gerrit.libreoffice.org/7787 Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com> Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
This seems to be related to bug 87915, which has some test files attached to it. 4.3.6 and 4.4.0 can open, save and open files with text in polygons, but still do not allow text entry into a polygon.
I have checked the behaviour with 4.4 final (or .03 which is the same I think), it seems to be working now: in my attach file the previously created polygons now show the text inside correctly, and I have created a new polygon from scratch, inserted text, modified the shape with text correctly adapting to the modifications. So to me the bug is no more present: I do not understand your sentence, Mike Sapsard: "but still do not allow text entry into a polygon"... I actually can type text directly into the polygon or paste a text into it after double clicking on the polygon itself, and it works ok to me.
I just created a polygon in Writer 4.4.0.3 and added text to it after a double click. I agree that is working correctly. The method I tried earlier was to create the shape and try to enter text using Draw, so that I could copy it into Writer. The double click to enter text in Draw did not work for me. I also could not paste the polygon into a Writer document. This is a regression.
I see... actually I never tried any of this in Writer, but only working in Draw. I succeeded to create a polygon and insert text into it in Draw, actually: this is was I was talking about in the previous message. Now I have reopened my attached file here copied one of the 2 polygons there and pasted it into a new Writer doc: it seems to be working OK.... I could as well edit the text inside it right there in Writer. So I am finding no problems at the moment, both in Draw AND Writer. I am not so sure to have exactly replicated all of your actions, tough.
To enter text into an object in Draw 4.4.0.3, I must click the text icon. A double click on the object has no effect. To enter text into the same object in Writer 4.4.0.3, I can just double click on the object. Surely the behaviour should be the same in both applications?
Sapsard wrote: "To enter text into an object in Draw 4.4.0.3, I must click the text icon. A double click on the object has no effect." HOW STRANGE... in the same exact release, in Draw, I create a polygon of any shape, then double click on it, the cursor appears and i can type text or paste it directly... I tried again right now. I could imagine the following possible reasons for the different behaviour: - you try to enter text while having the "edit points" functions active: in that state, it is impossible for me too. As soon as you deactivate edit point state, however, text insertion with a double click on the polygon is possible again... - the difference is due to different operating systems where we run LO4.4.3??
I have carefully tested Draw again, and it works as you describe. I had not noticed the setting of the points icon. I now notice that the entered text is at an angle, but I cannot find a way to rotate the text without rotating the object. I'll keep looking and report back.
Created attachment 113257 [details] Contains two polygon objects with text
Draw objects do accept text as agreed. However: 1) Text is at angle of first line drawn (relative to page); 2) A false line break is shown in the displayed text after the first character; 3) In the Format|Text window the anchoring and margins to edge of object are disabled if 'Fit to Frame' or 'Adjust to Contour' are clicked. I have seen the first two reported as separate bugs. I will check for the third in the bug reports.
I do not want to make this a debate between us two, but I have some further notes on your last comment: you say "1) Text is at angle of first line drawn (relative to page);" My comment: the text is shown with an incline of 21.99°, which is the rotation factor that appears in the "size and position" dialog window for the polygon object. The strange thing is that your polygon has a rotation angle which is not 0: I have tried again and again, but every polygon I draw has always 0° rotation, unless you actively rotate it after having created it. So if you get the context menu fro your polygon choose size and location and set the angle back to 0, your text is strictly horizontal. you say "2) A false line break is shown in the displayed text after the first character;" My comment: the capital K which is isolated in the first line of your object is alone because the upper edge of the polygon is no perfectly level. If you drag its left extreme just a little, text will actually flow on the first line, as you see in the same graph on page 2. To me, however, the real problem that emerges is that when you rotate this objects with text contained, the text rotates accordingly but its location and the placement within the polygon edges are completely lost. Check in the third page the same orange polygon of page 2, but with a 45° rotation: as you can see here things really go berserk. Now THIS is a real BUG, IMHO.
Created attachment 113263 [details] An agmented versioni of the previous file with further examples
Andy, I'll go that. I've struggled a little to find some items like 'close shape/polygon'.
Sorry for my poor English... what do you mean by "I'll go that"??
Sorry Andy, Your English is so good that I thought you were English. You have passed the Turing test for English:)) Unfortunately, I made a typo. I should have said "I'll go with that." It means "I agree".
Thanks, of course I know what "i'll go with that" means, and I was suspecting there was some word missing, but you never know... Best wishes
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Norbert Thiebaud
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
The texts is visible in the shape and adapts to the contour in Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: de-DE (de_DE); Calc: CL The problem of wrong position of the rotated text in a rotated polygon is tracked in bug 84507. I don't know which commit fixes the problem, therefore I set the bug to "works for me".