Issue 50705

Summary: insert textfile with html content will not insert as plain text
Product: Writer Reporter: Regina Henschel <rb.henschel>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, mh.hh
Version: OOo 2.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
will not insert as plain text none

Description Regina Henschel 2005-06-14 10:09:23 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)".
Comment 1 Regina Henschel 2005-06-14 10:10:28 UTC
Created attachment 27156 [details]
will not insert as plain text
Comment 2 michael.ruess 2005-06-14 10:19:59 UTC
Reassigned to ES.
Comment 3 eric.savary 2005-06-14 11:44:26 UTC
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.
Comment 4 Oliver Specht 2005-06-14 12:22:18 UTC
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. 

Comment 5 Regina Henschel 2005-06-14 14:10:46 UTC
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.
Comment 6 Oliver Specht 2005-06-14 14:33:06 UTC
Sorry, I overlooked the filter selection in the initial description. 
Comment 7 Oliver Specht 2005-06-14 14:33:41 UTC
.
Comment 8 mhatheoo 2006-02-06 21:59:10 UTC

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.
Comment 9 Regina Henschel 2006-03-08 09:37:00 UTC
*** Issue 62901 has been marked as a duplicate of this issue. ***
Comment 10 andreas.schluens 2007-01-23 14:40:20 UTC
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.
Comment 11 Rob Weir 2013-07-30 02:35:32 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.