Created attachment 50475 [details]
MAC formatted file

Created attachment 50476 [details]
UNIX formatted file

Created attachment 50477 [details]
WINDOWS formatted file

MRU->MBA: could you please assign this to an appropriate developer? Thanks a lot!

target 3.0

*** Issue 89694 has been marked as a duplicate of this issue. ***

@os: it seems that the Writer filter detection disdains text files with Unix or
Mac line ends. Can you verify - or even better ;-) - fix this?

*** Issue 84264 has been marked as a duplicate of this issue. ***

*** Issue 91199 has been marked as a duplicate of this issue. ***

This follows issue 91199, since closed as a duplicate of this one (84774) which 
I hadn't found in a keyword search. Issue 84774 is similar but differences 
exist, and I was asked for an attachment, which I'll try to supply here, if I 
can figure out how in time. This response is partly in light of comments within 
91199.

Most users of a word processor opening a document will expect it to open in the 
word processor. That's not an enhancement. The violation of the normal 
expectation is a failure, thus a defect.

I've now seen the priority-setting information. Thank you. I accept the 
correction.

Here are the steps for opening Text-Encoded-test.txt in read/write mode:

Writer > File > Open > select file. The unlabeled drop-down list for which the 
tooltip says "Select which types of files are shown" already reads "All files". 
Click Open. Result: Text Import dialog. Set Character set to Western Europe 
(ISO-8859-1) (which I used for document creation) instead of default Unicode 
(UTF-8). Click OK. Calc opens with the document. Not good.

Writer > File > Open > select file. Change the unlabeled drop-down list for 
which the tooltip says "Select which types of files are shown" to Text Encoded. 
Click Open. ASCII Filter Options dialog already shows proper charset 8859-1 and 
proper paragraph break CR & LF (I used 8859-1 for document creation and prefer 
CR&LF). Click OK. Writer opens the document. That's good.

Writer > File > Open > select file. Select File type > Text documents. Leave 
the unlabeled drop-down list for which the tooltip says "Select which types of 
files are shown" at "All files". File type > Text documents (which includes 
txt). Click Open. Result: Text Import dialog. Set Character set to Western 
Europe (ISO-8859-1) (which I used for document creation) instead of default 
Unicode (UTF-8). Click OK. Calc opens with the document. Not good.

Writer > File > Open > select file. Select File type > Text documents. Leave 
the unlabeled drop-down list for which the tooltip says "Select which types of 
files are shown" at "All files". File type > Text Encoded. Click Open. ASCII 
Filter Options dialog already shows proper charset 8859-1 and proper paragraph 
break CR & LF (I used 8859-1 for document creation and prefer CR&LF). Click OK. 
Writer opens with the document. That's good.

How I made the file: Writer > File > New > Text Document. Enter text. File > 
Save As > File type > Text Encoded; enter Name; checkmark Edit filter settings; 
click Save button. Message on format or content incompatility. Click Yes. ASCII 
Filter Options dialog already shows proper charset 8859-1 and proper paragraph 
break CR & LF (I prefer 8859-1 and CR&LF). Click OK.

The file extension is that added automatically by OOo, namely, .txt. That's 
good, since I also open, edit, and save the same file on Win machines and back 
again in OOo.

When opening files, counterintuitivity occurs when the dialog proposes to open 
all the files when it perhaps won't open any. It occurs again when file type's 
pick list has text documents long before text encoded, leading us to apply the 
former.

I understand the problem of Writer being told to open a file but not knowing 
what type it is. But the solution is not to hand it off to Calc. Rather, 
perhaps add a dialog after the file-open dialog has been clicked to Open when 
All files has been selected and ask the user to reconsider, and state at that 
point that All files and nothing in the picklist is too general, so users 
change something rather than watch Calc take over and turn a memo into a 
spreadsheet and not know what to do. This is a usability defect.

Version 2.4 just came out, and downloading and upgrading, in my recent 
experience, take time. I imagine you already know if this fault has been fixed, 
but since a search told me nothing about the issue, I doubt it was fixed for 
2.4.1.

Thanks.

-- 
Nick

Created attachment 54873 [details]
small test file in Text Encoded format made in OOo 2.4

->as: As the files do not match the system encoding on Windows the simple text
filter detection fails. Writer is not asked for the text encoded filter.

There is only one "default" filter for a particular extension and this is "Text"
for txt. The default filter is called first when a file with its extension shall
be detected. All other possible filters are called in arbitrary order and so the
Calc text filter is called before the Writer encoded text filter.

I wonder why we need two different type detections for text - could we detect
both in one run? Or - do we really need two text filters in Writer? Couldn't we
use only one and make it a filter option (that is added while detecting) whether
the dialog is shown or not?

Calc also has only one text filter and if encoding etc. is passed in the
arguments the dialog is not shown. I would prefer to see that in Writer too.

AFAIK there's no way to decide about the dialog while detecting. If it were it
might hinder the user to force the dialog. 
It would make sense to me to remove the non-dialog ascii filter and keep the
encoded filter. Filter options could be set to sensible values by default.

Would be fine for me also.

But I don't get the reason for that.
Let's put Calc aside for the moment. 

If a user opens a txt file Writer detects whether it's text with default
encoding. If the detection is successful, the file is opened without a dialog.
If not, later on another detection checks whether the file could be "encoded"
text and in case it is, the file is opened with a dialog.

My proposal would that Writer only has one "text" filter that - depending on its
detection whether encoding is default or not - suppresses its filter dialog or
shows it (this will depend on the fact whether an "Encoding" parameter is found
in the arguments that the type detection might have added if it could be
detected without doubt). That would exactly be the same as now - with the
additional benefit that we have one filter less and that this bug will be fixed.

Additional experience: Starting Writer the other day brought up the
OpenOffice.org Document Recovery dialog. (I don't remember the state at the last
previous exit of Writer, so I don't question why that dialog appeared.) Clicking
Next for a file and "Recovery in progress" yielded the Text Import dialog, which
didn't say Calc but it looked like it was going to import into Calc, since a
window within the dialog appeared to present a spreadsheet. The dialog promised
a crash report tool, but when I exited Calc the result was that all of OOo
exited, meaning Writer also had exited, and the exiting left me no crash report
tool.

While I understand that in recovery for Writer to know the file type might be a
stretch, on the other hand defaulting to a non-Writer format also seems like a
stretch. I mention this in this OOo Issue's context in case the cause is the same.

Thanks.

-- 
Nick

I have just encountered this problem with OpenOffice.org 3.0.0rc2 (OOO300m8
build:3597) on Mac OS X 10.5.5.  It's particularly egregious because I'm opening
a *local-format* text file and having the wrong thing happen. It's no longer a
matter of the Windows ME build misbehaving with a foreign-platform text file.

The workaround of opening as file type "Encoded Text" does successfully open the
file as text, after clicking [OK] to an intermediate dialog box about encoding
and line endings.

I've voted for this issue.

.

Possibly narrowing the problem:

Writer > File menu > Recent Documents > 1: . . . [path/file] opened a Text
Encoded file in Writer, as it was supposed to, not in Calc, which is how it
opens when using the File menu > Open method without specifying Text Encoded
instead of All files in the menu that is tooltip-described as "Select which
types of files are shown" when running the Gnome 2.10.0 desktop (KDE's desktop
makes the Open dialog different).

Speculation (mine) on why Recent Documents works: Writer stores the file type
for a file created during the same Writer session, or possibly for any file
still in that submenu regardless of when created or last modified. If so, a
kludge would be for the Open process to access that type history, although that
would result in intermittent performance when Open opens some files in Writer
and others in Calc and all are of the same type.

I once tried Gnome desktop > Main Menu > Places > Recent Documents, but no Text
Encoded or Writer file was in that submenu, although Calc files were. I tried it
again and some Text Encoded files were listed but others from the same OOo
session were not and the difference mystifies me.

-- 
Nick

I think the type detection of text files must be improved also, see e.g. issue
71757. It seems that binary files that OOo accepts as text files can cause a
crash and I think it's hard to fight against that after OOo has inserted the
"text" of the file. We must make some reality checks here, e.g. by checking the
line length resulting from the import or others things where a reasonable number
usually has a limited value. But that surely needs some thinking.

This might have some influence on how a possible solution for this issue here
will look. IMHO we can't detect a text file reliably before we know its
encoding. So when the user has entered what (s)he thinks is the encoding, we
must verify the type "text" again. Thus it seems that the dialog must be shown
while we detect the file, not after that as now.

*** Issue 105665 has been marked as a duplicate of this issue. ***

I tested with DEV300m100 and it was obviously fixed already.
Opening the mac or unix file on Windows brings up the Writer "text encoded" filter dialog and opens the file in Writer.

I don't know if older versions opened the file without the dialog, but that would be wrong anyway, at least if we follow the current design of our filter detection.

closing