Ørjan:
Rather than write a conversion routine so that you can continue using your
non-standard fonts, why not just adopt a standards-based solution. You may
still need a conversion routine to get existing apps converted, but there
wouldn't be any problems with new documents.
The characters you mention are all supported by Win98, Win2000, WinNT and
Win95. Unless someone is using non-standard fonts or perhaps different apps
or different versions of some app where different codepage support is an
issue, there isn't any reason why they would have problems going between
these OSes except for the following possibility: if documents are 8-bit and
are created in an app that doesn't record the codepage or charset (e.g. if
the files are plain text) and if the different systems are set up with
different system codepages, then characters may not appear the same from
one system to the next. There can be some additional complications if the
preceding conditions apply and you're also using custom-encoded fonts or if
some of the systems are running Win95 or NT 4 without support for the euro
(support for z with caron was added to these OSes as part of the euro
update).
You mentioned (MS) Word. Word documents at least from Word 95 on allowed
runs of text to have different charsets/codepages, and this info was stored
in the document. If you're using Word 95 or later, it shouldn't matter what
the system codepage is since Word will keep track of what codepage is
needed. Actually, Word 97 and later use Unicode rather than 8-bit text +
codepage, so a Word 97 doc should appear the same on *any* system, assuming
the same fonts are available. The only possible problem that could occur
with Word 95 would be in the event that the codepage used for a run of text
is not installed on a particular system, but I don't think that's very
likely to occur. So, if you're using Word 95 or later, you wouldn't be
having these problems provided you stuck with standard fonts.
The specific characters you mentioned are all supported in Windows
codepages 1250 and 1257 (and, of course, in Unicode). Each of the OSes in
question provide keyboard layouts that would be associated with one of
these, e.g Czech or Latvian. If you use one of these keyboards along with
standard fonts, you won't experience any problems moving documents from one
machine to the next.
If none of the keyboards provided with the OS suits your needs, you can
also create you're own. There are some helpful tools available for doing
this, e.g. Keyman 4 from Tavultesoft (www.tavultesoft.com), which works on
each of these OSes (actually, I'm not sure if it runs on Win2K, but I know
that version 5, which is in the works, will). Just make sure that you
specify that the keyboard is to be associated with one of these codepages.
By the way, if the problems you are encountering are limited to the 8-bit
character codes x80, x8e and x9e (d128, d142, d158), then that's a problem
specifically related to a change made about two years ago to codepage 1252.
If that's the case, I can give you some further info regarding that,
including workarounds to keep you non-standard font working properly in all
versions of Windows. But since standards exist that appear to meet your
needs, I think that would be the better way for you to go.
Peter Constable
From: <orjan.jenssen@fm-fi.stat.no> AT Internet on 05/30/2000 01:19 AM
To: <unicode@unicode.org> AT Internet@Ccmail
cc: (bcc: Peter Constable/IntlAdmin/WCT)
Subject: how to make a program/macro that toggles ascii/unicode chara
Hello everyone,
I'm working in i public office in Finnmark, the northernmost county of
Norway. Here we regularly use sami/lappish characters like c, s and z, all
with caron (and a few others). Before (and still), we used a nonstandard
true type font, resulting in files with ascii-values that make sense only
when this font is used.
Now some of us have NT machines, and some Win95, -98 or 2000. This makes a
mess, because new files made with NT and extended character sets (Latin ext
A) can't be shown correctly on 95/98-machines. And old files with this
special font don't look right on NT machines.
I want to make a program in Visual Basic, or a macro in Word, that can
change characters both ways. That is, I want to be able to convert old
files so that they look right with NT, and to convert new files written i
NT so that they look right with this special old font.
I've made a similar program before, which changes ascii-values, ex between
NS4551 and ansi. This is simply done by the routine
if asc(sign) = nnn then sign = chr(yyy), and replacing the asciivalue in
the file.
But this doesn't seem to work with unicode and values outside 255.
Can it be done - and how?
With regards,
Ørjan W. Jenssen
Office of Nature Management,
The Finnmark County Governor
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:03 EDT