Created attachment 191644 [details] text document with rotated shape Open attached document. It has a rotated "right triangle" shape. Bring it into text edit mode for to enter some text. Look at section "Shortcut Keys for Drawing Objects" in topic "General Shortcut Keys in LibreOffice" in the Help. The following methods do not work for rotated shapes, but work for not rotated shapes. Select the shape, then Press F2 or Press Enter or Start writing with a letter or a number. Only double-click with the mouse works for a rotated shape. Thus there is no way to enter text to a shape without using the mouse. The problem is specific for Writer. All three mouse-less methods work in Draw. Tested with Version: 7.5.8.2 (X86_64) / LibreOffice Community Build ID: f718d63693263970429a68f568db6046aaa9df01 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded and with Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 43967453e15e1d054972a7586cfef8f8e0866270 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Reproducible with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0f6f5048d223731aa52b768a77244d0208711391 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
This chould be fixed by implementing a .uno command to bring a shape into text edit mode, which then can be used by a short-cut or as menu item. Besides the accessibility problem it is hard in macros to bring a shape into text edit mode, see discussion in https://ask.libreoffice.org/t/macro-to-set-shape-in-writer-in-text-edit-mode/99914. A new .uno command would solve that too.
The rotation angles for a shape to accept text with keyboard seems to be affected by its proportion. Thus a square (1∶1 ratio) receives text until 45,94° And a rectangle (1∶2 ratio) receives text until 38,46° Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded
Created attachment 191846 [details] Test document with both, rotated and unrotated shapes
(In reply to Regina Henschel from comment #2) > This chould be fixed by implementing a .uno command to bring a shape into > text edit mode, which then can be used by a short-cut or as menu item. Is there a specific reason the same mechanism for handling non-rotated shapes shouldn't work, i.e. is there a need to introduce a new mechanism rather than making the existing one work for rotated shapes as well? At a first glance, `SwView::EnterDrawTextMode` gets hit for both cases (rotated and non-rotated shape), then the if (pSdrView->IsMarkedHit(aDocPos) && !pSdrView->PickHandle(aDocPos) && IsTextTool()) check in there is `false` for the rotated case (but `true` when not rotated), and that seems to come from `SdrMarkView::IsMarkedObjHit`. Is one of the methods involved there maybe not correctly taking into account the rotation? (I must admit that I know little about how shapes and their rotation are handled, so maybe there's some obvious reason that would require introducing some new approach that I'm unaware of.) Sample backtrace while experimenting: 1 SwDrawView::CheckSingleSdrObjectHit dview.cxx 207 0x7fffa8e7bf5b 2 SdrMarkView::IsMarkedObjHit svdmrkv.cxx 1923 0x7ffff1aacdce 3 SdrMarkView::IsMarkedHit svdmrkv.hxx 285 0x7fffa9e408c3 4 SwView::EnterDrawTextMode viewdraw.cxx 476 0x7fffa9e3f1bc 5 SwEditWin::EnterDrawTextMode edtwin.cxx 5466 0x7fffa9bc678f 6 SwEditWin::KeyInput edtwin.cxx 2477 0x7fffa9bb8757 7 ImplHandleKey winproc.cxx 1211 0x7fffedbb3682 8 ImplWindowFrameProc winproc.cxx 2724 0x7fffedbb9cef 9 SalFrame::CallCallback salframe.hxx 310 0x7fffe36b62e2 10 QtFrame::CallCallback QtFrame.hxx 228 0x7fffe36b7806 11 QtWidget::handleKeyEvent QtWidget.cxx 676 0x7fffe37110a4 12 QtWidget::handleEvent QtWidget.cxx 712 0x7fffe3711200 13 QtWidget::event QtWidget.cxx 735 0x7fffe3711363 14 QApplicationPrivate::notify_helper qapplication.cpp 3298 0x7fffe0da7a8a 15 QApplication::notify qapplication.cpp 2717 0x7fffe0da5363 16 QCoreApplication::notifyInternal2 qcoreapplication.cpp 1138 0x7fffe2bb0550 17 QCoreApplication::forwardEvent qcoreapplication.cpp 1153 0x7fffe2bb05c8 18 QWidgetWindow::handleKeyEvent qwidgetwindow.cpp 680 0x7fffe0e77dab 19 QWidgetWindow::event qwidgetwindow.cpp 245 0x7fffe0e75f1e 20 QApplicationPrivate::notify_helper qapplication.cpp 3298 0x7fffe0da7a8a 21 QApplication::notify qapplication.cpp 3249 0x7fffe0da789b 22 QCoreApplication::notifyInternal2 qcoreapplication.cpp 1138 0x7fffe2bb0550 23 QCoreApplication::sendSpontaneousEvent qcoreapplication.cpp 1595 0x7fffe2bb1185 24 QGuiApplicationPrivate::processKeyEvent qguiapplication.cpp 2452 0x7fffe1c049bd 25 QGuiApplicationPrivate::processWindowSystemEvent qguiapplication.cpp 2076 0x7fffe1c034d1 26 QWindowSystemHelper<QWindowSystemInterface::SynchronousDelivery>::handleEvent<QWindowSystemInterfacePrivate::KeyEvent, QWindow *, unsigned long, QEvent::Type, int, QFlags<Qt::KeyboardModifier>, unsigned int, unsigned int, unsigned int, QString, bool, unsigned short> qwindowsysteminterface.cpp 105 0x7fffe1cc0185 27 handleWindowSystemEvent<QWindowSystemInterfacePrivate::KeyEvent, QWindowSystemInterface::SynchronousDelivery, QWindow *, unsigned long, QEvent::Type, int, QFlags<Qt::KeyboardModifier>, unsigned int, unsigned int, unsigned int, QString, bool, unsigned short> qwindowsysteminterface.cpp 138 0x7fffe1cba837 28 QWindowSystemInterface::handleShortcutEvent qwindowsysteminterface.cpp 437 0x7fffe1cb8424 29 QGuiApplicationPrivate::processKeyEvent qguiapplication.cpp 2433 0x7fffe1c04899 30 QGuiApplicationPrivate::processWindowSystemEvent qguiapplication.cpp 2076 0x7fffe1c034d1 31 QWindowSystemInterface::sendWindowSystemEvents qwindowsysteminterface.cpp 1109 0x7fffe1cba367 32 xcbSourceDispatch qxcbeventdispatcher.cpp 57 0x7fffe0527bd3 33 ?? 0x7fffea5111f4 34 ?? 0x7fffea514317 35 g_main_context_iteration 0x7fffea514930 36 QEventDispatcherGlib::processEvents qeventdispatcher_glib.cpp 394 0x7fffe3034d1f 37 QXcbGlibEventDispatcher::processEvents qxcbeventdispatcher.cpp 96 0x7fffe0527e08 38 QtInstance::ImplYield QtInstance.cxx 424 0x7fffe36d8b20 39 QtInstance::DoYield QtInstance.cxx 435 0x7fffe36d8c49 40 ImplYield svapp.cxx 390 0x7fffee330c36 41 Application::Yield svapp.cxx 474 0x7fffee3319d4 42 Application::Execute svapp.cxx 368 0x7fffee330929 43 desktop::Desktop::Main app.cxx 1612 0x7ffff7a36b0a 44 ImplSVMain svmain.cxx 229 0x7fffee34fde0 45 SVMain svmain.cxx 261 0x7fffee3500f5 46 soffice_main sofficemain.cxx 94 0x7ffff7aa36ad 47 sal_main main.c 51 0x5555555549d4 48 main main.c 49 0x5555555549ba
Of cause you can fix the rotation case only. But there is no easy way to bring a shape or text box into text edit mode using a macro, and entering text edit mode is not recorded in macro recorder. Therefore I thought it would be better to get a general solution, which could be used for accessibility and macros as well. BTW, the problematic use case is a rotated text box, especially 90deg rotation of text boxes is often used.
(In reply to Regina Henschel from comment #6) > Of cause you can fix the rotation case only. > > But there is no easy way to bring a shape or text box into text edit mode > using a macro, and entering text edit mode is not recorded in macro > recorder. Therefore I thought it would be better to get a general solution, > which could be used for accessibility and macros as well. Thanks for the clarification. Without knowing much about the code in question, I'm wondering whether an added UNO command would (1) effectively use the same code path as the existing code (and would thus run into the same problem unless this gets fixed) or (2) do something else in the first place. In case of (1), I think it might make sense to split adding a UNO command to a separate bug report/feature request as it would then be independent of the rotation aspect that this bug report primarily focuses on.
(In reply to Michael Weghorn from comment #7) > Without knowing much about the code in question, I'm wondering whether an > added UNO command would (1) effectively use the same code path as the > existing code (and would thus run into the same problem unless this gets > fixed) or (2) do something else in the first place. > > In case of (1), I think it might make sense to split adding a UNO command to > a separate bug report/feature request as it would then be independent of the > rotation aspect that this bug report primarily focuses on. I guess, that it would be (1). So your idea to split the problems is right.