Apache OpenOffice (AOO) Bugzilla – Issue 50705
insert textfile with html content will not insert as plain text
Last modified: 2013-08-07 14:38:26 UTC
I use OOo1.9.104 on WinXP Home German. I've got a HTML-file which is stored with filename "Normalparabel.txt". 1. Open a new textdocument and write some text. 2. Use Insert - File 3. Select the file "Normalparabel.txt" 4. Select the filetype "Text (*.txt)" 5. Insert Result: The content is interpreted as HTML and is shown as in a browser. Expected behaviour: The file will be inserted as plain text, so that you can see the tags. OOo1.1.4 inserts it as plain text. The same wrong behaviour appears with filetype "TextEncoded (*.txt)".
Created attachment 27156 [details] will not insert as plain text
Reassigned to ES.
ES->OS: description: a *.txt file contains in fact HTML code (starting with <!DOCTYPE HTML PUBLIC... and so on) When inserting this file over "File - Insert", on gets followings: LINUX: OOo 1.1.4 -> formatted HTML file OOo 2.0 (current) -> formatted HTML file WINDOWS: OOo 1.1.4 -> Plain text HTML code OOo 2.0 (current) -> formatted HTML file Question, is this a bugfix or a regression from 1.1.4 to 2.0? ;) Users may want both behaviors (autorecognition of the file header/magic or insertion as plain text, espcially when the "encoded text" filter has been chosen) I have no opinion about this. Please ask UserEx if needed.
The filter detection code has been changed for 2.0 and I'm sure the current behaviour (to load depending on the document content) is correct.
I think the behaviour of OOo2.0 is not good. 1. If I select a filter expressly I do not want an automatic detection. If a choose "text", I want to get plain text. If I wanted HTML, I would have chosen "HTML Document". 2. Now the behaviour of 'file insert' differs from the behaviour of 'file open', where the selection of "text" leads to plain text. So if you decide that this behavior is intended, than please turn this issue to "enhancement": If a user selects a filter, OOo should first try to use that filter. Only if it fails, it should detect the filter from content. You can add a list item 'automatic detection' to the filetyp list, to force a filter detect from content.
Sorry, I overlooked the filter selection in the initial description.
.
Nothing changed in here - and still not functioning in 680M154 @ OS <snip> The filter detection code has been changed for 2.0 and I'm sure the current behaviour (to load depending on the document content) is correct. </snip> I hope you understood, that this feature is not working as expected - and by that must be replaced by the old manner Just to mention this: Open HTML-Files - change view to HTML-Source - Select and Copy - insert with PASTE SPECIAL as unformated-text to new writer-file That gives the expected result - but it should not be like that - it's crazy. I hope you will raise the target-milestone Martin P.S.: BTW: Re-Export to HTML is impossible - try it with this attachment - you will have to use an external html-editor to copy a tag you can see in OO-writer to a html-file. We have a similar problem, when you "construct" a link in a Calc-sheet with some stringoperations, you can not save/export this link as HTML, as the unicode-letters for < and > will be replaced wrong? Have a look.
*** Issue 62901 has been marked as a duplicate of this issue. ***
a) The content of the file is realy HTML. TypeDetection will show that. b) HTML Content will be layouted inside writer as "content" ... not as "plain ascii text". c) The only way to fix that: dont make a type detection ... use the selected filter hardly without any question about it. ... But then you will might be into trouble. If your selection was realy wrong (because you thought its HTML ... but in real its a binary file having an extension HTML) it can happen that the selected text ascii filter crashes by buggy code, which stops on "null bytes". Of course that can be fixed ... But because our office can be extended by external components it can happen that another filter crashes and cant be fixed by us. This "FIX" seams to dangerous for me. I will discuss it here internaly if we think we can go this way. d) You mentioned that copy/paste works as aspected. Please note: most applications copies such HTML code as "pure string" to the clipboard. So here detection will return text ascii and it will work. But dangerous filters wont be used here in general .. because no external application (as source of the copied content) will place a signature into the cliboard which says: "this is a starwriter 5.0 content". So this use case is a little bit different to "Insert From File" functionality.
Reset assignee on issues not touched by assignee in more than 1000 days.