Path: utzoo!attcan!uunet!kddlab!ccut!tansei!b39756
From: b39756@tansei.cc.u-tokyo.JUNET (Martin J. Duerst)
Newsgroups: comp.sys.mac
Subject: Re: FullWrite on shelves
Summary: Script Manager Compatibility (of WP in general)
Keywords: FullWrite, Script Manager, Word Processors
Message-ID: <1942@tansei.cc.u-tokyo.JUNET>
Date: 17 May 88 03:39:57 GMT
References: <158@amcad.UUCP> <46100148@uxe.cso.uiuc.edu>
Reply-To: b39756@tansei.cc.u-tokyo.JUNET (Martin J. Duerst)
Organization: Computer Center, University of Tokyo, Japan.
Lines: 78


leonardr@uxe.cso.uiuc.edu (Leonard Rosenthol) writes in comp.sys.mac

>jmunkki@santra.UUCP(Juri Munkki) writes in comp.sys.mac
>
>{Lots and Lots Removed (about compression of CODE ressources)}
>
>>I would REALLY like to get in touch with the developers of FullWrite. (E-Mail
>>would be great and TeleFAX is ok...) I'd like to help them internationalize
>>FullWrite because we need a version with Finnish hyphenation and probably
>>a Finnish spelling checker too. So, if you know how to contact them, please
>>tell me how.
>	Don't hold your breath!!  Unfortunately, do to many things that they had
>to do to get FullWrite to be FullWrite, they had to do some things that will/do
>make internationalization VERY difficult (if not impossible!).  I (and others_)
>had discussions with them relatively early in development about Script Manager
>compat and the answer was IMPOSSIBLE!!
    I don't belive that exactly. 
>	I wish I could get it to work at least 'sort of' with ANY of the Int'l
>Scripts, but alas, NO!  Not even the draw layer works (but it does work better
>than the main program!!!)

   Here is an idea that could help to solve a lot of problems with the
internationalization of FullWrite and many other Word Processors(WP).
It is very clear that elaborated WP don't use the (new) TextEdit and
the ScriptManager because their (relative) lack of speed and functionality.
On the other hand, many users in the US and in many other countries
would shurely appreciate it if they can use non-roman characters in
their documents.
   So why not create a new category of document parts, in the same way as
may be graphics, tables, headers, footnotes, etc., are part of the
document. As for graphics, where e.g. Word 3.0.x just lets Quickdraw
draw a picture on screen or paper without caring about its contents,
text in non-roman scripts could be treated in a similar way. Instead
of calling Quickdraw, the WP would call TextEdit.
As the script depends on the font, it is very easy to
make this changement between WP code and TE (allmost) transparent.
Also, speed is not affected for pure Roman-Script users, because in this
case the only additional check needed is to see wether a font selected
by the user has script Roman or not.
   For users that just want to insert small blocks of foreign text, e.g.
linguists that write an English thesis with foreign-language examples,
the preformance degradation will not be significant, but the additional
functionality very, very valuable.
      (This is, with some tricks, allmost
       possible in WriteNow (don't know about the other WP). Using a Script
       Manager compatible draw program, you 'draw' the text you want, then cut
       and paste it into the document as an inline graphic. Unfortunately,
       the margin for the inline graphic is too big and blows up the corresp.
       lines, but I am shure there are ways to correct this.)
   For users that write a document completly in a non-roman script, the
speed, as well as the functionality, will degrade, but this will depend
on the properties of the individual script. A lot of the nice features
of the WP can still be used, although sometimes not without tricks.
Tabulators for example, not included in the new TE, can be used by taking
a tab in a Roman-Script font.
   As for users with languages like Finish, German, French, etc., where the
script is the same as for English, and where the main problems are spelling
and hyphenation, most WP nowadays have two alternative dictionaries for
British and American English, and if some additional code (for different
scanning strategies/word endings) is included in these dictionary files
instead of being built into the WP, it will not be very difficult to
internationalize these programs.
      (I'm not considering the economic
       aspects (how many users are needed to make producing a foreign dictionary
       profitable) nor the linguistic aspects (spelling checkers are much more
       difficult for most other languages than for english), but only the
       software engineering aspects, which seem to be farely simple.)

This is only an idea, and I don't know if it really works, but if not,
I would like to hear why not. Also, if any (or many, or all) WP
companies want to adopt any of the ideas in this article, please
feel free to do so (the sooner, the better).

Martin J. Duerst, Graduate Student,
Kunii Lab., Dept. of Inf. Sc.,
Fac. of Sc., Univ. of Tokyo
7-3-1 Hongo, Bunkyo-ku, 113 Tokyo, Japan