Description: Image caption frame size to small after copy/paste Steps to Reproduce: 1. Open the attached file 2. Copy the image frame (containing image) 3. CTRL+N 4. CTRL+V -> Caption hidden Actual Results: Caption hidden Expected Results: Not so Reproducible: Always User Profile Reset: No Additional Info: Found in 7.2 and in 4.4.7.2 and in LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
(In reply to Telesto from comment #0) > Steps to Reproduce: > 1. Open the attached file Attachment is missing => NEDINFO
Created attachment 168572 [details] Example file
I confirm it with Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Additional information: It does't happen, if you paste frame into the same document.
Dear Telesto, 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 present in Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded It happens because of different PS: PS Caption in original document has spacing before and after paragraph 0 cm and font size 11. In new paragraph PS Caption has 0,21cm spacing before and after and font size 12.If you change all values to values of original document, it works as expected. So I could narrow down the problem as follows 1. Open attachment 168572 [details] 2. Change PS of last paragraph to Caption or wirte a new paragraph with PS Caption (this makes it obvious, that problem isn't related to captions 3. Copy paragraph 4. Ctrl+N 5. Ctrl+V 6. Compare Settings of PS (font size and spacing) Actual result: Different settings Expected result: Not sure about it. Perhaps current result is expected or original formatting of PS should be retained. => I've changed bug summary => needUXEval
Similar topic in bug 112697 for Impress. We can a) silently apply the target style (current situation) b) silently copy/rename of source style ("Caption_1", for example) c) show a dialog to resolve the conflict In the case of Writer, the goal of styles is to create a consistent document. Therefore b) makes no sense to me. Showing a dialog would be a major nuisance for most users, so maybe some kind of paste special option where all attributes are taken from the source. In fact pasting as RTF does not work, likely since we do not copy every single attribute. My take: NAB, aka a).
(In reply to Heiko Tietze from comment #6) > In the case of Writer, the goal of styles is to create a consistent > document. Therefore b) makes no sense to me. Showing a dialog would be a > major nuisance for most users, so maybe some kind of paste special option > where all attributes are taken from the source. In fact pasting as RTF does > not work, likely since we do not copy every single attribute. > > My take: NAB, aka a). Heiko, I understand your arguments, but I don't agree with the conclusion. Original bug report shows, that it isn't always easy to figure out, why a pasted text doesn't look as expected. So in the case you paste text from another document I would at least expect a message like: "You paste content from another document. Copied style formatting will be overwritten by styles with the same name." OK | Cancel | Don't show message again (Of course you can use a better English)
(In reply to Heiko Tietze from comment #6) > We can > a) silently apply the target style (current situation) > b) silently copy/rename of source style ("Caption_1", for example) > c) show a dialog to resolve the conflict (In reply to Dieter from comment #7) > So in the case you paste text from another document I would at least expect > a message like: "You paste content from another document. Copied style > formatting will be overwritten by styles with the same name." OK | Cancel | > Don't show message again (Of course you can use a better English) There are three actual cases usability-wise: 1. The user pastes as plain text - i.e., the current Ctrl+Alt+Shift+V behavior; 2. The user would want the pasted rich text to follow the styling of target document (i.e., the same-name styles get the meaning they have in the target document; absent styles are added; direct formatting is applied as in the source) - i.e., the current Ctrl+V behavior; 3. The user wants the pasted text to look as it looked in the source. This is what this issue is about. The #3 indeed must *not* be implemented by modifying the existing styles (because that would re-format existing text); and I would tell that renaming styles would also be poor, because it would proliferate automatically generated styles - consider a document, into which you copy some text from other source many times - will it generate new style_1, style_2, ... style_N each time? The reasonable implementation of "keep source formatting" paste option would be to use the target styles, *but* additionally apply direct formatting atop, to override any formatting in the target document which does not match what was in the source. The "I want the text to look the same as in the source" case is a clear sign of unstructured approach (at least locally), and DF is IMO absolutely fine. And IMO, some improvement of the paste process would be nice. A dialog is a no-go; but we already have a drop-down paste toolbar button; and we could try to implement more convenience tools - see e.g. how MS Word does that, by displaying a floating toolbar on paste, with buttons allowing to change the formatting of the pasted text *retroactively*. I don't suggest to copy that approach, but I suppose that some improvement is possible without intrusive (blocking) UI (which is a dialog).
I agree with your reasoning, Mike.
What is the actual use case? Shouldn't the style "Text Body" or "Frame" be consistent across one document, exactly as implemented? And if a document has headings with blue text color I see no reason to keep that for another document with red headings.
(In reply to Heiko Tietze from comment #10) Users may (and often do) *not* care about styles; they often cate about look. And pasting some data from other sources, and wanting it to *look* exactly as it was in the other source, is a frequent request: people might want some look and feel of the original (in a form of "insertion", like "this is how it appeared in source Foo"). And they *really* don't care that someone had created the other source using the same styles that they are using in their new destination: both could use Heading N, but customized differently. Users might have valid reasons to expect *just copy something from a random document, paste into another random document, and have an option to make the result look exactly like in the source*, no matter what.
(In reply to Mike Kaganski from comment #11) > Users may (and often do) *not* care about styles; they often care about look. I think we talk about the Eve-users who properly format one document with styles and the other one too.
(In reply to Heiko Tietze from comment #12) Who told you that? We talk about any use case. What is a rationale behind random limitation of this to a case when an advanced user works with documents that they authored themselves? Two artificial limitations in one sentence ;)
(In reply to Heiko Tietze from comment #6) > a) silently apply the target style (current situation) This is true only if the particular paragraph style is not already used in the target document. So this is a bug, since in the reported case, the frame incl caption is pasted in an empty document.
and apart from #14: (In reply to Mike Kaganski from comment #8) > And IMO, some improvement of the paste process would be nice. A dialog is a + 1 - but different topic, IMO.
(In reply to Cor Nouws from comment #14) > > a) silently apply the target style (current situation) > > This is true only if the particular paragraph style is not already used in > the target document. I disagree. This would be an additional, big and unmanageable source of problems. Styles in documents are *document content*, even when they are yet unused. If you ignore that, templates loose their meaning at all. I prepare templates for further reuse of styles (among other things); so when you paste and re-define my template styles, it is simply wrong. Please don't introduce this "redefine if unused". I could agree with "redefine all if explicitly requested", but not that.
(In reply to Mike Kaganski from comment #16) > Please don't introduce this "redefine if unused". I could agree with > "redefine all if explicitly requested", but not that. And I disagree with annoying confirmation dialogs. So it turns out that we can only provide some special paste option where the formatting is kept (but existing styles are not overwritten, meaning it gets a the name). Not worth the effort, IMO, since the use case is weak (comment 12).
(In reply to Heiko Tietze from comment #17) > (In reply to Mike Kaganski from comment #16) > > Please don't introduce this "redefine if unused". I could agree with > > "redefine all if explicitly requested", but not that. > > And I disagree with annoying confirmation dialogs. > > So it turns out that we can only provide some special paste option where the > formatting is kept (but existing styles are not overwritten, meaning it gets > a the name). > > Not worth the effort, IMO, since the use case is weak (comment 12). Honestly, such use case is frequently asked here. I.e., they copied a paragraph from one text document and paste into another file (maybe new, maybe existing) and asked to keep the original paragraph style. It seems to be a default behavior in Microsoft Word, as the users said.