Multiview - Text files

A forum for general AmigaOS 4.x support questions that are not platform-specific
Post Reply
Lemen
Posts: 6
Joined: Fri Sep 09, 2011 11:14 pm

Multiview - Text files

Post by Lemen »

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.

User avatar
trixie
Posts: 395
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Multiview - Text files

Post by trixie »

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.
Smoke me a kipper, I'll be back for breakfast!

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

chris
Posts: 552
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: Multiview - Text files

Post by chris »

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)

xenic
Posts: 1164
Joined: Sun Jun 19, 2011 12:06 am

Re: Multiview - Text files

Post by xenic »

@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.
AmigaOne X1000 with 2GB memory - OS4.1 FE

xenic
Posts: 1164
Joined: Sun Jun 19, 2011 12:06 am

Re: Multiview - Text files

Post by xenic »

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.
AmigaOne X1000 with 2GB memory - OS4.1 FE

chris
Posts: 552
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: Multiview - Text files

Post by chris »

@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?

User avatar
djrikki
Posts: 138
Joined: Fri Jun 17, 2011 10:21 pm
Location: Grimsby, Lincolnshire, UK
Contact:

Re: Multiview - Text files

Post by djrikki »

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 :D Just drag an image or image folder over it and browse to your hearts content in a more comfortable environment.

Post Reply