ianf@nada.kth.se (Ian Feldman) (10/11/89)
In article <14008@well.UUCP> of 8 Oct 89 20:22:46 GMT Leonard Rosenthol (svc@well.UUCP) writes: [ descriptions of how MicroPhone II v.3.0 addresses the need to translate and emit non-USASCII characters (via "non-Script Manager BUT Internationally compatible"), claiming support for any "roman based language" on both the terminal-display, keyboard-remapping and the scripting-language levels ] The real question is not whether any self-respecting terminal program ought to provide translation of 7/8-bit codes to national character sets but how does it go about it. Let us for the moment leave aside the special cases of non-Western scripting directions, context-dependent glyphs and the like. Let's not worry about the mere mechanics of character substitution - in the end it all comes down to proper translation tables. What I'm personally concerned with is having access to more than one character set during the same terminal session, either one of which could be switched in depending on the need or the content, manually or via software. After all -- if I need or elect to communicate by mixing languages then it shouldn't be the terminal software's task to limit my use of same. Unfortunately, by and large, this is what is the case with the Macintosh telecommunication software of today. Save for an exception or two (of which more later) the Macintosh terminal-access programs come in two basic flavours: those that allow an option of switching in a single national character set (to be displayed using the monospaced Monaco - or equivalent - font of single predefined size) and the rest that simply map the incoming 8-bit character codes onto the 7-bit USASCII. Seldom, if ever, is there a choice of multiple active alphabets and/ or of alternative display fonts. Characters that are not present in the Monaco set might as well not exist and won't be displayed onscreen either. Among the exceptions that I'm aware of are: the TeleFinder (v 1.0) permits selection of any font that's available to the system; alas, strips away the high bit from the transmitted characters. the MacTerminal (version 2.3 of the "Macintosh System Software") works as advertised in a variety of Western languages, allows switching between two different character sets (G0 and G1), but uses the (non-changeable) system font Monaco 9 for display purposes. the MacKermit (Swedish 1NE version) allows choice of either the E47 or the D47 (Swedish) character set, displayed in a native VT100-compatible font (plain and bold). The most flexible solution seems however to be provided by the Terminal DA (v1.5) which permits on-the-fly switching among several Western alphabets, all displayable using a native DEC-compatible font. On top of that it also allows one to map selected codes to freely definable substitution strings making it fully possible to display odd symbols like <copyright sign> as "(c)", not to mention other one- language-specific, unusually accented or transformed, characters. Granted, the Terminal DA was written by three Germans who did not think of umlauts in terms of "exotic". BTW: this little gem (32KB!) is available from Sumex, in the DA section. Alas, neither one of the above nor any other terminal software that I know of caters for the East-European Latin languages: Polish, Czech, Slovakian, Serbo-Kroatian, Latvian, Lithuanian, Estonian. Possibly there are still more unusual Latin-based languages though it might always be argued that the market for, say, Albanian terminal software for the Macintosh is probably not that large at the moment. However, that's besides the point. There was no market for computers before computers either and look where we are now: hacking the American Standard Code for Information Interchange when we all should be fast asleep! ;-) -- ---- ------ ianf@nada.kth.se/ @sekth.bitnet/ uunet!nada.kth.se!ianf ---- --
svc@well.UUCP (Leonard Rosenthol) (10/11/89)
In article <2046@draken.nada.kth.se> ianf@nada.kth.se (Ian Feldman) writes: > >In article <14008@well.UUCP> of 8 Oct 89 20:22:46 GMT Leonard Rosenthol >(svc@well.UUCP) writes: > > [ descriptions of how MicroPhone II v.3.0 addresses the need to > translate and emit non-USASCII characters (via "non-Script > Manager BUT Internationally compatible"), claiming support for > any "roman based language" on both the terminal-display, > keyboard-remapping and the scripting-language levels ] > > [stuff deleted for inews] > > What I'm personally concerned with is having access to more than one > character set during the same terminal session, either one of which > could be switched in depending on the need or the content, manually > or via software. After all -- if I need or elect to communicate > by mixing languages then it shouldn't be the terminal software's task > to limit my use of same. Unfortunately, by and large, this is what is > the case with the Macintosh telecommunication software of today. > I have to agree with you. It is certainly possible that you may want to send a letter to Sweden and then one to Germany (in their respective langs) and so it is possible to switch the 'installed Character Set' on the fly either manually by choosing from a list or you could create a script which would set the CharSet for you (and then give it a cmdKey or FKey). Since it is possible to change the charSet on the fly via scripting, you could change it AT ANY TIME based on context of the incoming/outgoing data (ie IF TEXT EQUALS "'hejs'" SET CHAR SET "'Swedish'") > Save for an exception or two (of which more later) the Macintosh > terminal-access programs come in two basic flavours: those that allow > an option of switching in a single national character set (to be > displayed using the monospaced Monaco - or equivalent - font of > single predefined size) and the rest that simply map the incoming > 8-bit character codes onto the 7-bit USASCII. Seldom, if ever, is > there a choice of multiple active alphabets and/ or of alternative > display fonts. Characters that are not present in the Monaco set might > as well not exist and won't be displayed onscreen either. > > I have to admit that I although I can see the need for a choice of display font (which permits additional langs such as Russian, etc.), I do not see how multiple active alphabets would be useful - in fact I would see it as a hinderance. Which conversion gets done first, and then which one? If the same char is mapped in both who gets priority, etc!?!?!? As we have mentioned MPII does the mapping via the CharSet translation tables which can be used to map 8->7, 7->8, 7->7 or 8->8 (bits) into the appropriate code which is display using our Monaco varient which does contain some characters not present in standard Monaco which permit us to support Icelandic. The only characters which are nonPrinting in our Font are those chars in the CTRL range (0-32) plus Delete (127) everything else has a displayable character. > [Discusion of other East-European Langs such as Polish, Czech, etc.] > There was no market for computers before > computers either and look where we are now: hacking the American > Standard Code for Information Interchange when we all should be fast > asleep! ;-) > I agree with you that there are still markets to be tapped - Hell I would LOVE to do Kanji and Hebrew terminal software (which at least would sell some copies!) but there are so many issues to be confronted when moving outsie the defined territory of standard ASCII and the ISO character tables. Many companies have tried to establish standards for other character mappings (Hell, Xerox has a WONDERFUL book on the subject!) but things are still in a state of flux for anyone to do it right for these contries. I can say that myself and Software Ventures are committed to supporing the international user as best we can with our software and we will continue to do our best to develop interniontall and potentially script manager compatible software. Leonard Rosenthol Software Ventures MicroPhone II Development Team -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025