On 27-Apr-99 Razvan Cristian Oprea wrote:
>
> I have a small printing problem and perhaps you can help me.
> I am using a US layout keyboard, but from time to time I also need to
> use some national (Romanian), non-US characters in my documents.
>
> In Wordperfect 8, when I introduce any of this characters (from the
> Insert Symbol I guess menu), this characters are displayed very small
> (and printed accordingly), no matter how big are the 'regular'
> characters...
>
> In StarOffice 5, there is no such problem (all characters displayed
> without any difference), but I don't have available all the characters
> I need, and besides I can't setup my printer to print in different
> modes (fast, normal, best), or two-paged... why is that?
>
> Oh, and I forgot, some folks translated some KDE applications into
> Romanian, but the specific, national characters are displayed like
> something without sense (bars, dots, etc)... is there anything I could
> do to my Linux machine to support national, non-US characters ?
Comprehensive multinational support is a problem right across the board.
The WordPerfect case is due to the changes introduced when WordPerfect 6
for Windows was created. Previously, WP-5.1 handled most of this
satsifactorily provided your printer could handle it. To take one sample:
the Romanian a-breve ("a" with a small bowl-shaped "breve" accent above)
is WP-5 character [1,91], and it is still there as [1,91] in WP-8
("Insert Symbol" -> "Multinational"). However, while in WP-5.1 this would
probably display as a blob on the console, at least it would print right
provided your printer had the "breve" accent (as all standard PostScript
printers do). The WP-5.1 PS printer driver was capable of recognising
whether any accented character was present as a single glyph (like
"e-acute") in the printer's fonts, or whether it had to be composed using
separate glyphs ("a-breve" -> "a" glyph with "breve" glyph printed above
it). In the first case the printer code for the accented character is
sent; in the second case, the code instructing the printer how to print
the two glyphs in the right relationship is sent, all in the current font.
Since WP-6, however, the "WYSYWIG" mentality tied the printer drivers and
the screen display much more closely together. The mechanism just
described apparently no longer exists (unless you create it using WP
macros -- this is not easy!). WP also made the fundamental error of
supplying only a single font for Multinational characters outside
the range of a single ISO-Latin encoding. The result is exactly what
Razvan describes: the Romanian character, being outside the Latin-1
range, both displays and prints in this unique "multinational" font which
is always the same whatever the font (Times, Helvetica, ZCMI, ... ) or
the style (Roman, Bold, Italic). My view on all this, shared by the
various others who have been vituperating on the Wordperfect-8 for Linux
users list, is that WP-8, like everything since WP-6, for Windows or for
UNIX, is useless for multinational purposes. We are hoping that the
amount of criticism this situation has generated will cause Corel to
address the problem properly, but we still hope only.
I can't answer for StarOffice and KDE. It doesn't surprise me that
they don't have every character that Razvan needs: I don't think any
standard WYSIWYG word processing package has ever taken a proper view of
non-English languages. There is specialised software (e.g. "Multilingual
Scholar") which has been created expressly for people who need to do
a correct job in several languages, but I'm not aware of anything like
this available for UNIX/Linux (and they are not complete in the normal
"word processor" sense either).
My own solution to this, which I have been using for the last 15 years
without serious difficulty, relies on troff (now part of the groff suite).
TeX could be made to do just as good a job. This is not a word-processing
package but a text-formatting package with great generality and
flexibility. In particular, you can define any characters you need as
composites or even as chunks of PostScript code which draw them.
So, for instance, with the following in a macro package:
.acc*over-def breve \(ab
.char \[abr] a\*[breve]
the Romanian "a-breve" character can subsequently be invoked as \[abr] at
any time. Similarly the Romanian "t-cedilla" can be defined and given the
invoking code "\[t,]". So I can write to Razvan:
Mul\[t,]umesc pentru t\[abr]u email
meaning:
M u l <t-cedilla> u m e s c p e n t r u t <a-breve> u e m a i l
and it will print fine in any available font, and can also be displayed
on screen using ghostview ("gv") to display the PostScript file (in fact
I use this, editing with vim and running gv in parallel in "watch" mode,
to get a kind of delayed WYSIWIG). (View the little PostScript attachment
to this mail in gv, produced from the troff source above using ms macros
plus custom definitions).
In fact I have no difficulty with any European language nor with Turkish
using the standard PostScript printer resources and, with extra
downloadable fonts, Cyrillic, and (by tweaking) extended Cyrillic for
languages like Uzbek (though actually WP-8 is not too bad for the latter).
It would, however, be nice if the people creating the major main-stream
packages would become properly aware of non-English languages, maybe even
simply that they exist and are used by a potential market of several
hundred millions of people!
Best wishes to all,
Ted.
PS The following subject line, received from the LINGUIST list this
morning, may amuse you:
LINGUIST List: Vol-10-594. Mon Apr 26 1999. ISSN: 1068-4875.
Subject: 10.594, Jobs: Microsoft, Military linguist
(Turns out that these are two separate mailings in a digest, but it
had me worried for a moment ... ).
--------------------------------------------------------------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Date: 27-Apr-99 Time: 13:26:17
------------------------------ XFMail ------------------------------
temp.ps
