Re: Patch for multibyte printing (long)
- On Mon, Jan 19, 2004 at 10:05:32PM -0000, Mike Williams wrote:
> Normally, each country's ASCII code range differs in a couple ofOn which systems does the "ASCII range" differ, other than Japanese Windows
> characters from, er, true ASCII. If you are using Courier for
> characters in the ASCII code range, then you can specify true ASCII
> character set printing with another field, a:, which takes yes or no
> as its value.
systems having a broken backslash? There are probably a couple more that
I'm not aware of, but it's definitely not normal at all for ASCII codepoints
to deviate; it's exceptional (albeit an important exception that must be
- On 19 Jan 2004 at 17:18, Glenn Maynard wrote:
> On which systems does the "ASCII range" differ, other than Japanese WindowsI don't have my reference to hand but each country has it's own
> systems having a broken backslash? There are probably a couple more that
> I'm not aware of, but it's definitely not normal at all for ASCII codepoints
> to deviate; it's exceptional (albeit an important exception that must be
> dealt with).
national character set standard for the one byte code range, which is
similar to the ASCII character set but can differ in a couple of
For the example you give, the Japanese standard defines a Yen symbol
for the code 0x5c which is a backslash in ASCII (is this what you
mean by broken?) and an overline (a high horizontal line) in place of
a tilde. Another example is with Simplified Chines where ASCII code
for the dollar is used for the yuan.
These slight differences can cause problems when printing files that
are dependent on the US-ASCII character set - such as Perl or PHP
(especially on Windows!). It is a simple option to let the user
force the use of US-ASCII for one byte characters in this case.
Perhaps, what I should do is allow for this to be done without having
to use Courier as well. I'll have a look.
I is a uni student.