Created attachment 118721 [details] image comparing 2 slides in Impress. First slide (current version of Impress) has no selection outline for the active text box, and second one has an outline (suggested change) I am currently using Libre Office 4.4.5.2 on Windows 8, 64 bit, Locale en_US In Impress, it would be convenient if the selection outline box of the text box is made visible when the text box is active (even if its borders are absent). This allows easy scaling/moving of the text box when it is active, without having to search for the selection box every time when it has no borders. Currently, MS Powerpoint follows this and I find it very convenient. I attached an image showing how a textbox currently looks on selection (top) and how I think it would be more convenient according to my suggestion (bottom). I am filing this following a suggestion on the Ask Libre Office forums (https://ask.libreoffice.org/en/question/14015/how-to-show-text-box-outline/ )
The selection outline box is showing for me even in 4.3.0.1 when I am typing into a text box. How have you made it so it is invisible? Maybe we will find out, if you attach a file with the problem? Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI) Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
I came across this bug report when I thought I had the same issue. But after more trials, I find that the actual problem is the textbox is somewhat difficult to select, not that it is not selectable. By difficult, I mean I, as a new user, cannot always select the textbox I want by clicking around the text, and I often need to click multiple times to get it selected. Maybe I (and possibly the bug reporter) did not get the right way to do it?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Sun, 11 Sep 2016 21:43:24 +0200
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20161010
I see the same problem what other people have discovered. "How have you made it so it is invisible? Maybe we will find out, if you attach a file with the problem?" It doesn't make ANY sense to ask for any file. The problem is in program not in the file. As simple as fact any empty file has it. I see the bug under Linux with Openoffice 4.1.3 or any new version of Libreoffice. If I type inside of text box the box borders remain invisible. To be able to select it one need to click slightly above the text, but then I can only see cyan rectangles. That is very inconvenient. Previous versions (3.X) of OpenOffice were working fine. Not it's not. Openoffice as well as Libreoffice are way too bugy. To find a bug one need sometimes less than 5 min. Why nobody test them? Well Openoffice is slightly better.
(In reply to Gospodin Baron from comment #5) > It doesn't make ANY sense to ask for any file. The problem is in program not > in the file. As simple as fact any empty file has it. Then why do I not see the problem? It is completely normal to ask for a file in this case. Do you see the problem in 5.3, if you restart in Safe Mode: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption
Created attachment 132314 [details] example of ppt document without text borders displayed As request test file is provided
(In reply to Gospodin Baron from comment #7) > Created attachment 132314 [details] > example of ppt document without text borders displayed > > As request test file is provided With this file I confirm the missing borders. Now do you believe the request made sense? The bug is already in 4.3. 4.1.6 displays the resizing handles, but not the border. Maybe an initial bibisecting of the disappearance of handles could be valuable. Saving as pptx still preserves the problem. Newest version bug is confirmed in: Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+ (x64) Build ID: 74917d23782413aa0f129bcf9e6bf5a1c496d23b CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-04-02_23:58:52 Locale: fi-FI (fi_FI); Calc: CL
Regression introduced by: author Armin Le Grand <alg@apache.org> 2013-08-29 16:32:05 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2013-08-29 19:02:59 (GMT) commit b1a6dbc2dd118627360282dd304e24263c3bca51 (patch) tree 8a4bd5045cbfa424f03045356285c3620586a87f parent e57a73cc6bedcb8f176e1804792a7ea1fd88796b (diff) Resolves: #i123003# Corrected Handle/Overlay visualization... when TextEdit is active Bisected with bibisect-42max. Adding Cc: to Armin Le Grand
> With this file I confirm the missing borders. Now do you believe the request > made sense? Not really. I just need to install the OO/LO to see the bug. The ppt files aren't coming from Mars. And I don't have a very special & different tool to make them either. If I would, I won't care much about OO/LO and its bugs. Am I right? At least hopefully you can get my point I am also upset, because developers do not accept the bug just because they can't see them. It reduces the motivation of users to file the bug. Trust me nobody want to spent his time doing so. And if people do that it should be appreciated and not ignored. Especially if we talk about OO/LO! That suite has the highest bugs ranking among all programs I've seen before. It seems like developers never ever test or even start OO/LO before release. Personally I just filed the bug, because even in OO 4.1.3 which I have to use under Linux I can see it. I can't find OO 3.X anymore and downgrade further. No wonder, that city of Munich is going back to MS products. With introduction of last LO versions you are running against the wall. Instead of playing with broken features around design you better fix the program. Even DPI font scale is broken at LO and still works fine with OO 4.1.3
Herr Baron, if you like OO more, by all means use it then. We won't mind.
(In reply to Tor Lillqvist from comment #11) > Herr Baron, if you like OO more, by all means use it then. We won't mind. You can always stick your head in the sand. Whether it's a good tactic is a different question. I am just saying, that it's sad, that since so many years starting with StarOffice that suite has never got a broad distribution among people. Just compare what WPS guys have achieved within much smaller time frame. Frankly MSO is not perfect (actually far from it), but the fact is, that nobody came even closer to them with all the efforts made. If that would be a commercial organization they would drop the project long ago. The only solution I see is starting from scratch. Make it clean, compact, plugin based set of programs. Not that super monster we have now. Period.
Created attachment 138078 [details] Native format (ODP) with missing border around text box. I confirm this bug in LibreOffice: 5.4.3.2 Build ID: 5.4.3.2-1.fc27 I see the issue in a presentation in .odp format (see attachment). I consider this as a high priority issue as it severely slows down creating presentations for me. I suggest to rise the priority. Note that I copied the slide in from an other presentation that might have Powerpoint remainders.
Created attachment 138079 [details] Clean native format (ODP) with missing border around text box. I did some more testing. I created a clean new Impress presentation, without using a template. The issue is there (see slide 2 of the attachment). So for me this issue is completely unrelated to the PPT file format.
With last document, 2nd page border is not shown inEditMode. It is shown on selection (tab after changing page) and after ending TextEdit (esc). Not on 1st page. Can be recreated with new Impress doc and two pages - due to 2nd page using Layout 'Title, content'. Seems to be related to that last ObjectType. Creating an empty page (no layout) and/or adding a TextBox that is not connected to PresObj in BG does not show the problem.
High/major should be a more appropriate prioritization considering it's a regression, and we can't really expect users to fish around for the textbox borders.
Bug not reproducible in version Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
(In reply to jenny from comment #17) > Bug not reproducible in version > > Version: 6.3.0.0.alpha0+ (x64) > Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 > CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 > Locale: zh-TW (zh_TW); UI-Language: en-US > Calc: threaded This is false. It is still reproducible/confirmable. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9059457a1a8385cb80b5dd2c797cee77af4222a9 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 30 November 2018
Created attachment 155542 [details] Libreoffice Impress showing no selection outline around a textbox, just little blue squares that are hard to see.
Created attachment 155543 [details] Location of the Break Option in the Draw Menu
Created attachment 155544 [details] Textbox is now 'broken' and has a selection outline, showing its perimeter.
This bug is still happening. I'm on Linux Mint 18.2 Cinnamon, with: LibreOffice Version: 6.3.2.2 Build ID: 1:6.3.2-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded However! I think I found a workaround!! This works at least to provide outlines to text boxes originally made in Microsoft Office Powerpoint, in files converted to use in LibreOffice. Attached find three screenshots. These are lecture slides. I am an instructor, so I have many slides, originally made in powerpoint. The inability to select text boxes by their borders, feeling around the slide for a cursor change, like a man in a dark room trying to identify an elephant by touch alone, was a little too tedious for me, so I sat and tried every command I could find. I noticed that the text boxes from the original PPT had no border (see first screenshot), and also (at some point) a tooltip mentioned they were a special type of object. Hmmm, I thought. So I clicked around the Draw tab (I'm using tabbed interface) until I found, in the Draw drop-down menu, the Break command (see second screenshot). Now, I know that that should be for breaking a shape up into its constituent nodes and line segments. I can make an arrow and use break to convert the poor arrow into a skeleton of itself. But I use break on the Microsoft-created textbox, and it gains the magical blue outline I wanted. (See third screenshot.) If I click away from the textbox and come back, I can no longer return to the draw tab, but it seems to behave just fine as a textbox. So, it seems to have something to do with LibreOffice thinking some textboxes, such as those originating from MS PPT, are more complex polygons, and the Break command removes that property. I hope this is helpful! This is my first entry to Bugzilla...
I have the same problem. Here's what is working for me now: Step 1. Click inside the text box as if to edit it Step 2. Click the "Select" action icon in the toolbar to make the resizing squares visible Step 3. Either use the resizing squares, or position the mouse on the invisible line between the squares to drag the box It would help if we could make the resizing squares always show up around the text box while typing, and also show dotted lines between them to give a hint about where to put the mouse to move the box. It would also help if the action area would be larger around the dragging lines between the resizing squares, because it's really hard to keep the mouse on it -- sometimes when I try to click on the line the mouse moves just a little when I click and then I miss the line, and have to start over with steps 1 & 2 above.
I noticed that I'm having this problem only with text boxes that are part of the slide layout - title, content, etc. including clones where I copied & pasted an affected text box to make a second one. When I add text boxes to a slide with the insert text box tool, I do see a blue border around the box when I click on it, and clicking on the blue border shows the resize boxes. I also noticed that the action area for this blue border extends a few pixels into the text box so it's easier to activate. This behavior is just fine... I'm wondering why this good behavior doesn't apply to the text boxes that are defined by the master slides in my presentation.
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
Perhaps Caolan has some insight on the merge ? AFAICS much of our box selection, and double-click to-switch-to-rotation/shear mode etc. is far too hard to use but ... hey ho.
Created attachment 177335 [details] AOO 4.1.10 (In reply to Michael Meeks from comment #26) > Perhaps Caolan has some insight on the merge ? the merge was bisected as the disappearance of the handles and I seem to see the same effect in AOO 4.1.10
I don't think the handles are really the core of the issue anyway, people want the blue rectangle thing. Taking the sub-case of the example in the comment #14 then at svx/source/svdraw/svdedxv.cxx:1246 in SdrObjEditView::SdrBeginTextEdit we have const bool bVisualizeSurroundingFrame(bTextFrame && !bFitToSize); and in page 2 the second textbox that doesn't have the blue border has bFitToSize set. If autofit is turned off then it gets the blue border. Then taking the original document from comment #7 bTextFrame is false and it doesn't get "bVisualizeSurroundingFrame" of true for that other reason. As far as I can see, in... commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Date: Mon Sep 18 16:07:07 2000 +0000 initial import we also have this special if (bTextFrame && !bFitToSize) { ... } handling (FWIW I seem to have very old memories of having to play "hunt for the border") It's not entirely clear why we have that special handling. If we wanted to treat all these cases the same then https://gerrit.libreoffice.org/c/core/+/128025 would take the route-one approach and they would all act the same.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4b1a57e075af70135703e38337e1096b2f248ebd tdf#94223 always visualize surrounding frame for active text object It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
lets give that a go and see if there are unwanted sideeffects
(In reply to Caolán McNamara from comment #30) > lets give that a go and see if there are unwanted sideeffects Hi... there seems to be an inconvenience when editing tables in Impress. See attachment 182811 [details] from bug 151311. Notice that bounding boxes are appearing inside table cells now. I get the benefits of showing the bounding box for text shapes, but inside tables they don't fit very well. This may be a side effect due to the fact that Impress tables are actually a collection of other shapes, including text boxes.
if tables are unwanted, that's an easy fix, I'll do that via bug 151311.
It has been observed that the issue described is only seen when dealing with text boxes that are integrated into the slide layout, such as the title and content boxes. This includes instances where a duplicate text box was created by copying and pasting an impacted text box. When using the "insert text box" tool to include text boxes into a presentation, it is seen that a distinct blue border surrounds the box upon clicking. Furthermore, interacting with said blue border reveals the presence of resize boxes. Additionally, it is worth noting that the active region of the blue border extends slightly beyond the boundaries of the text box https://coreball.co, therefore facilitating its activation. This conduct is deemed acceptable within the given context. I am curious as to why the aforementioned positive conduct does not extend to the text boxes that are delineated by the master slides inside my presentation.
Thank you for fixing this!