Re: Frequent incorrect guesses by the charset autodetection in IE7

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Jul 19 2006 - 05:57:58 CDT

  • Next message: Samuel Thibault: "Re: Frequent incorrect guesses by the charset autodetection in IE7"

    From: "Samuel Thibault" <samuel.thibault@labri.fr>
    > Cristian Secară, le Tue 18 Jul 2006 01:40:49 +0300, a écrit :
    >> On Mon, 17 Jul 2006 20:55:00 +0100, Sinnathurai Srivas wrote:
    >>
    >> > ISO word processing woks perfectly with mostly all applications.
    >>
    >> The supported encoding of a word processor depends mainly on the
    >> operating system on where the word processor is runing.
    >> As far as I know, except for web browsers and e-mail clients, Microsoft
    >> and Apple platforms do not support true ISO-8859-x at all, at least not
    >> directly.
    >
    > Even web browsers and e-mail clients make funny things with ISO-8859-x
    > charsets...

    Microsoft does support ISO-8859-x in its word processors, using the support from the OS. Also indirectly through the Windows codepages 125x which are extensions of ISO-8859-x where C1 controls have been replaced by other characters (for example Windows 1252 supports ISO-8859-1 except C1 controls, and maps characters existing in ISO-8859-15 and a few other punctuations commonly used on the web, like the bullet for lists); There are several file formats supported, including legacy Word6 .doc format, RTF, and new XML-based formats (based on Unicode).

    Word has absolutely no difficulty to read texts encoded with ISO-8859-x (the only complication is that there's not always the possibility to select the effective charset when loading a text file, as there's an implicit choice, and the interface was overly simplified, but this selection does exist using VBA with which you can create custom file-open dialogs).

    I don't understand why Microsoft chose to hide such choice to users in the default GUI, despite this is a expensive and large product (I don't speak about WordPad where it's reasonnable to have limitations and a very simplified and non extensible interface).

    Many people criticize OFfice for its complicate interface with too many items enabled by default, but why are such basic thing like file format selection, or more precize functions (like in Excel where there are too many implicit assumptions that can't be overriden, not even by customizing the interface).

    I have little to say against Word, but it's true that Excel really lacks too many basic features (including very basic computing functions) and too frequently makes very bad guesses on the input based on false assumptions, and nothing to override these choice in customization. The implemented wizards or dialogs may be helpful, but when there's no other way to bypass them, it becomes really too complicate to make advanced spreadsheets, without using the unsupported VBA (which is also a security issue in many environments). Things like those are really too difficult to handle in international environments:
    * input of dates
    * input of numeric *strings*
    * lack of many string functions
    * search/replace operations that force unwanted datatype conversions (and change the expected results of formulas)
    * input of matrix formulas
    * too many things that can only be performed using the mouse (too much difficult to use when this must be applied on large tables on lots of rows)
    * no formula to control the generation, extraction or removal of web links (whose input is forced without asking the user)
    * no way to select multiple images or attached objects in a range table without selecting them one by one. This makes the conversion of web tables very lengthy and errorprone, and can't be easily automated.
    * Severe limitation on table sizes, with truncation of the input at random places.
    * File formats really too verbose, with many things that are not even used in the file itself, just because it stores lots of user default options, including the software built-in defaults
    * Formulas in spreadsheets that don't read properly in other localized version of Excel.
    * Impossibility to work reliably simply with the current user locale if it differs from the locale with which a speadsheet was created; data input conflicts with the initial locale. This is a problem for international collaboration on the same documents or templates.
    * To solve those problems, one needs to contact a qualified VBA programmer to make the wanted basic functions; this adds to the usage cost, so Excel is most often used in its very basic features, and users in fact don't need so many wizards and a so complex interface to work on such documents. Excel is an hybrid that does not satisfies either the basic or advanced users. May be it should become two products with different pricing (or with a cost-free basic version that can read all spreadsheets but limits the kind of input in the document being worked on, and an advanced version with less wizards but more precise and general functions, which can be easily automated by scripts, code generators, editable code, but with much less assumptions about the user actions).



    This archive was generated by hypermail 2.1.5 : Wed Jul 19 2006 - 06:05:08 CDT