Hyperion Entertainment Message Boards

A problem with the way Multiview displays text files, or rather,
doesn't display them when alt characters are used.

If you open Notepad and type "abc" and save, Multiview will display ok.
If you now add an alt character, say alt-1 to give the ¹ character and save,
Multiview will now not be able to open the file and gives the error window
"Unknown data type for test.readme".

If you play around with the font used in Notepad, this also seems to have an
effect on whether Multiview will be able to open the file or not.

I've tried other text editors with the same result.

That's not a MultiView problem, it's a text.datatype problem. Apparently, the datatype performs filetype check and if it finds non-standard characters, it fails to recognize the text file and returns an error.

datatypes.library differentiates between ASCII, binary and IFF files, and only passes these to matching descriptors. If you have a file that datatypes.library has identified as binary, it will never get checked by any descriptors for ASCII filetypes (such as plain text, certain PNM variants etc).

ascii.datatype is a bit different as it's one of the "default" datatypes, so doesn't have a descriptor (the others are iff.datatype, binary.datatype and directory.datatype). When MultiView sees your file with non-ASCII codes in it, it is determining that it is a binary file, checking with the binary-handling descriptors and ultimately passing it along to binary.datatype (which doesn't exist in a standard OS4 installation, hence the "unknown datatype" error).

The fix would be for datatypes.library to have an expanded view of what is classed as ASCII - ie. expand the character set range to encompass all 8-bit printable characters. That might cause some binary files to be detected as ASCII though, and doesn't help with text files which start with ESC code sequences (there is a possibility they are accepted anyway; I haven't checked)

@Trixie & Chris
I did some experimenting with this issue and I don't think it's strictly a simple datatype rejection of non-standard characters. Whatever algorhythm is being used to detect binary files gets confused by some combination of characters. For example if I enter "Test ¹ ² ³ ¢ ¼" in a text editor and save to a file, Multiview won't display the file but if I add some more ASCII text after the initial text like "Test ¹ ² ³ ¢ ¼ for Multiview display." then Multiview displays the file. It isn't just failing to recognize some characters outside the normal ASCII range, It's stumbling over combinations of those characters and standard ASCII characters. The problem gets even stranger if you try the same type of experiments with other Locale language settings.

I think that a beta tester or developer needs to perform some experiments with text containing "ALT" characters in combination and in combination with various ASCII characters. I haven't been able to establish a pattern in the Multiview rejection of text containing "ALT" characters but is obviously not simply a case of rejecting text that contains any "ALT" characters.

Lemen wrote: If you open Notepad and type "abc" and save, Multiview will display ok.
If you now add an alt character, say alt-1 to give the ¹ character and save,
Multiview will now not be able to open the file and gives the error window
"Unknown data type for test.readme".

If you play around with the font used in Notepad, this also seems to have an
effect on whether Multiview will be able to open the file or not.

I was unable to reproduce the problem with your example; possibly because I have a different font setting or locale setting. However, I was able to reproduce the problem with other ALT character combinations. "abc ¹¹¹" saved to a file will not be displayed by Multiview but "abc ¹¹¹ abc" will be displayed by Multiview. I think it's more complicated than simply a rejection of files containing ALT characters.

@xenic

Obviously I don't know exactly how the detection works, but it is the detection at the datatypes.library level, not at text.datatype level. Your tests show that it is being a bit cleverer then I gave it credit for - maybe it is the ratio of ASCII to non-ASCII characters in [unspecified header length] that determine if it is an ASCII or binary base type?

I prefer to open text files in Notepad all the time rather than use this archiac Multiview. It would however be a handy addition if we could make Notepad the default tool for an icon and combine it with a LOCKED=YES tooltype. If one was to set this tooltype, buttons could grey out and become unavailable, equally relevant menu options could also become inaccessible.

Image files are the same, in Multiview you can't even do anything simple like Zoom-in. I'd rather use a third-party tool for opening images, I suggest Jack Just drag an image or image folder over it and browse to your hearts content in a more comfortable environment.