Thanks, Andreas, for your clarifications.
First of all, sorry for the regression we introduced. I plead guilty. I tried the detection with all kind of renamed odt and sxw files and wpd files as well. I just did not keep in mind that the Word documents were OLE documents and once we made our WP OLE document detection work, (it was not working before due to a use of OInputStreamWrapper instead of OSeekableInputStreamWrapper in our stream class) I did the test only with WP OLE documents and non-OLE documents. Mea culpa, mea maxima culpa.
We knew about the regression about 36 hours before the m83 was released. Since I committed the changes also into Neooffice/J an GPL-ed derivative of OOo for MacOSX, and Mac Word files are normally not having extensions, so it was reported early enough. The patch I committed to the issue solved the problem on Neooffice/J, but I had that annoying Read-Error in m82 with libwpdupgrade merged, so was working on finding the problem instead of reporting the issue with the patch attached :-(
Andreas SchlÃns wrote:
As a result of these fixes the following behaviour should exist:
a) well known and supported word perfect files should be opened using your word perfect filter
b) any other format should be opened by any other suitable filter (of course)
c) and unknwon format (e.g. pdf files which are supported for export but not for import) must bring up the filter selection dialog, where the user can force opening this unknwon file using a special filter. Of course there is no guarantee, that it will not have any side effects .-)
This is what I understood from the docs and from the filter/source/config/cache/typedetection.cxx
Because any filter must deal with the situation, that a complete unknown format is provided to the filter.
WriterPerfect conversion, if you force it to open an unsupported document, will result in a blank document. No crashers.
A deep detection service has to return an empty string for unknown formats and a well defined string for supported formats.
This is what we were believing doing. But, life happens.
A filter has to return TRUE/FALSE only as a result of it's operation.
Throwing of exceptions is limited to RuntimeExceptions only. Errors has to be handled gracefully using the interaction concept. It's not allowed to show dialogs directly!
The exception was just our bug and in no way an intention :-).
You problem regarding the shown error box
"Read-Error. Cannot read the file"
seems to be a problem of another deep detection module.
May be it does not use the provided input stream and try to open the file again ... which is normaly locked then and can't be opened read/write normaly then. On the other side the file is opened by the generic typedetection framework at a central place so problems regarding opening the file are handled one times only. We had several bugs before ... because every modules used by the typedetection framework tried to open the stream ...
But in case the url was wrong it was tried more then ones ... and of course the corresponding error message was shown more then once too.
This is reminding me that in the documentation, it is recommended that if a service creates InputStream from URL, it should add this stream into the MediaDescriptor. Is it something that we should do or is the stream creation handled centrally in all cases? It was not at all this case (central creation of stream) in SRX645. I am asking, because it looks like our TypeDetection is fired as a first one in the list of deep detection services.
BTW: I can't reproduce this error message on a normal m83 version nor on the cws fwkfinal. But you can send me the debugger output ... if it contains more then library names only .-)
email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
If you cannot reproduce it, it could mean that my build is kind of hoarked. Although, I built it simulataneously on two machines with a clean checkout (not dmake clean). I put the file somewhere on the web and I give you the url. You will be able to see if you have time.
Thanks again for your work and sorry again for the regression. I am believing that after we iron these issues, the new WP typedetection will be much better than it was before (all supported WP files are detected as such and all unsupported WP files are detected as unknown format).
Cheers
Fridrich
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
