Description: Contents of text boxes from Draw get wrapped after the text box has been pasted into a Writer document. The text box shows the same dimensions in Writer as in Draw, yet the text is wrapped. This is a nasty bug if you want to copy drawings into your text document that have many text boxes, because all text boxes are affected, and you have to resize each one. Steps to Reproduce: 1. Open a new Draw document, open a new Writer document 2. Insert a text box in the Draw document, write 12 into the box 3. Copy the box 4. Paste the box into the Writer document Actual Results: Text is wrapped in the text box. The box looks like 12 in Draw, but in Writer it is 1, next line 2: 1 2 Expected Results: The text box should show the contents 12 like in Draw. Reproducible: Always User Profile Reset: No Additional Info: Font is Liberation Sans 18. The effect was shown on LO 6.1.0.3 both on Linux and on Windows (x64). Happens in 6.2.0.0 as well, but not for capital letters. It is still unclear which contents are affected. For longer strings, only the last letter is wrapped to the next line. The dimensions of the box are equal between the original and the pasted box, according to the settings dialog.
I can't confirm this with Version: 6.2.0.0.alpha0+ (x64) Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04 Locale: en-US (de_DE); Calc: CL To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Renamed the profile folder and tried again - same result. I tried - 6.1.0.3 Linux x86_64 - 6.1.0.3 Windows x86_64 in Virtual Box - 6.1.0.3 Windows x86_64 native (freshly installed LibreOffice, no profile existed) - 6.2.0.0.alpha0+ Build ID: 1d0727a104d76210814f41c1169df318e40c9d80 Linux x86_64 Every time: Open Calc, open Writer, insert Text field in Calc doc, type 12 into text field, mark the field, CTRL-C (or Copy in context menu), put Writer doc in focus, CTRL-V (or Paste in context menu). Result is 1 2
(In reply to Michael Zapf from comment #2) > Every time: Open Calc, open Writer, insert Text field in Calc doc, type 12 > into text field, mark the field, CTRL-C (or Copy in context menu), put > Writer doc in focus, CTRL-V (or Paste in context menu). Result is Just for clarification: Is this bug about Draw (see bug summary), about Calc (see comment 2) or is it about both?
Sorry, s/Calc/Draw/g I wanted to say DRAW.
No repro. Tried creating the text box both by clicking once and clicking'n'dragging. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 8b1501d80dc9d3f42c351c6e026fa737e116cae5 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 23 September 2018
Could it be locale-specific? I tried a DE Windows installation of 6.1.1 on the PC of two other persons, and the issue is clearly there and safely reproducible. If desired, I could offer a screen capture. It seems to me as if the pasted text box is a bit too small, maybe due to a rounding error. The original text box in Draw is 1.21cm x 0.96cm. When copied and pasted, the resulting box is 1.20cm x 0.96cm. When I increase the width to 1.21cm, the text is unwrapped. Also, when the size is flagged as protected, the text is not wrapped after pasting, and the pasted target is 1.21cm wide.
this bug is not reproduced. 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 Michael Zapf from comment #6) > Could it be locale-specific? I tried a DE Windows installation of 6.1.1 on > the PC of two other persons, and the issue is clearly there and safely > reproducible. If desired, I could offer a screen capture. > Tried with German locale and Version: 6.1.3.2 (x64) Build-ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded but no repro. Could you please attach your files from draw and fromk writer? Perhaps this can giv a hint. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested documents are provided.
Bug confirmed 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
NEW per previous comment
Dear Michael Zapf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem is still reproducible with LibreOffice 6.3.3.2 (x64) on Windows 10 and Linux as described in the first comment (2018-09-01 20:50:13 UTC).
I can reproduce this too with a nightly build from a day or two ago: Version: 7.0.2.0.0+ (x64) Build ID: 8f1cb34bdb523e17478de2b0ef7d745c29743df7 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Additionally, this happens to me sometimes even when copying text boxes to a different Draw document. I have an example file which consistently reproduces that; don't know if that would be relevant here (possibly the same underlying problem?) or worth its own bug.
Created attachment 168048 [details] The Draw source document
Created attachment 168049 [details] The Writer destination document
Created attachment 168050 [details] What it looks like in LibreOffice Writer
Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded It seems related to drawing resize in Writer : it resizes everything except the text elements as shown in the attachments.
Dear Michael Zapf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible on LO 7.6.1.2 (x86_64). Note that the used font and the font size are relevant. I can safely reproduce the effect with "Liberation Sans" at 18pt. With "Times New Roman", the effect does not occur for any sample between 12pt and 36pt (at least). The effect for Liberation Sans 18 pt is that the width of the text box ("12") is reduced by 0.01cm when pasted into the new Writer document (see comment 6). Observation: The width of the text box "12" using this Liberation Sans 18pt is 1.21 cm with "Fit width to text". If this setting is disabled and the size is changed to 1.22cm, then back to 1.21cm, copy/pasting the text box is done correctly without wrapping. My guess is that the auto-width is fractional and rounded, and that the digit resolution during copying is changed so that rounding on paste yields a slightly smaller dimension, thus wrapping the content.