Description: first off, it works... the problem is "ONLY" that it doesn't actually does what it suggests it's doing... As we might all know, a Writer document is actually a zip file, which among other components, has a "content.xml" -- well this is our document... this is its "source code"... this "code" (text with info and tags) is very messy... which is a bad thing... this means that the Microsoft's approach is still inherent in Libreoffice, that is, what matters is what you eventually see on your screen and in your prints... But how we achieve this look, this surface, should remain our dirty little secret... (the developers'), while the user is being happy with her/his document... that s/he "created) (only did the typing, it is us who created it! :)) I believe in transparency which HTML5 represents. More importantly, I believe that we all believe in it ... ODT docs and the machinery behind should be transparent in that sense... the text's source code should be clean... (I know, I know: a document's text can come from very surreal places, and from a series of various places, different machines, languages settings, vintages, templates, etc, etc) But cleanness should be a priority... Why? Because, for example, messiness simply causes Scribus (a program, application which deserves respect in terms of compatibility and common workflow, too) to import text jammed up... "jamming" only means only that here and there a space is missing... but when you've been editing a book for weeks, and the text is finished, it is a surreal situation that you "may have" some minor faults in your originally almost perfect text document... after importing it... SO, I think, there should be applicable methods for cleaning the messy source code.. and one such method could be "paste as unformatted text"... Imagine that you paste 10 pages like that, and then you have to format everything from scratch.. It'd be cool! But... headings and emphases could be kept.. and that would be even more superb... Unfortunately, "paste as unformatted text" only means "unformatted for the appearance"... cause the messy source code is just being pasted over... later perhaps, similar to "clear all direct formatting", there could be a tool "clear all formatting".... BTW: despite using styles, the source code really looks (in some cases) like directly formatted... sometimes a space or a letter of a word separately gets a new tag... which is mess... and style names proliferate wildly... like, ranging from "text style name: T2" ... to... "T18". within one paragraph... which could be called mess... the main problem is that once a letter is separated from a word, it will remain like that... and the source code will get more and more fragmented by course of time.... this is why a method of cleaning, or even more methods could be a wonderful thing... acting against the messy and messier tendency ... Steps to Reproduce: 1. copy some paragraph from a text... 2. paste it in a new document... 3. open the source code file (context.xml) Actual Results: what you see is that broken up words remained as they were in the original (messed up) source file... Expected Results: you should see that pasted unformatted text's source code is CLEAN... only 2 tags, one at the beginning, one at the end... broken up words, lonely spaces embraced by tags should all be united in just one line of text... Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This is completely incorrect interpretation. Pasting as unformatted text is *expected* to not bring formatting present in the available rich clipboard formats to the target documents. It has nothing to do with the further processing of the pasted text content in the target document; e.g., with the metadata (anonymous annotations) added to the document content added in different editing session, used to provide useful version comparison results [1, 2, 3]. The RSID generation can be disabled; and also there is bug 88298 addressing some of your concerns. Everything else in your description is just unrelated and incoherent rant on something that you don't seem to understand. The software is for users, not for IT pros; the complexity of the markup is the result of the WYSIWYG software using fixed algorithms to compose and store vast amount of information *potentially* useful in great variety of use cases, without an intelligence that an IT expert could apply when generating the markup manually. [1] https://git.libreoffice.org/core/+/062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c [2] https://wiki.documentfoundation.org/ReleaseNotes/5.0#Optional_RSIDs [3] https://help.libreoffice.org/7.5/en-US/text/shared/optionen/01040800.html?DbPAR=SHARED#hd_id521597320824763
Agree => NAB And would note that the ODF zip archive is nicely supplemented by the ODF XML flat file representation. Multi-paragraph parsing of input text is quite reasonable, and any single appropriate Paragraph Style can be applied to to pasted text. Splitting out Titles, Headings/Outline elements (changing the Paragraph Style) is fluid, and can be automated with text markers and marcros. So our current "paste as unformatted text" is functional for all reasonable needs, from single sentences to multiple page text runs. What is done with it next can be a simple direct formatting--or a robust application of Styles pre-defined in a template document.