help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs 22 release


From: Peter Dyballa
Subject: Re: emacs 22 release
Date: Thu, 29 Sep 2005 12:14:17 +0200


Am 28.09.2005 um 22:35 schrieb Kevin Rodgers:

Peter Dyballa wrote:
> I don't see so many changes from stable GNU Emacs 21.4 to GNU Emacs 22 > from CVS. The latter still can't handle completely the case of dealing
> with more than one ISO or Unicode encoding.

Did you happen to turn off unify-8859-on-encoding-mode?  (It's enabled
in Emacs 22 by default.)  Did you try turning on
unify-8859-on-decoding-mode?

In my 'standard' edition of GNU Emacs 22 I have not changed the default values. Adding

        (setq unify-8859-on-encoding-mode nil)
        (setq unify-8859-on-decoding-mode t)

makes no change in that field which I address in my writing: I can't i-search again for the same 8bit character when I change from buffer a in encoding a to buffer b in encoding b.


> And printing is still bad
> too! This message comes from trying to print a buffer in ISO 8859-15/ISO
> Latin-9:
>
>     These characters in the buffer can't be printed:
>     €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
>     Click them to jump to the buffer position,
>     or C-u C-x = will give information about them.
>
> And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...

Have you submitted a bug report?

Not yet, but you motivate me to do so! (Again. I think I reported something similiar earlier this year and Kenichi Handa then made some changes that the message about unprintable characters became more realistic, being based on the actual glyphs of the encoding used. He promised that in Unicode Emacs 23 the problem will be solved. Could be some backlash happened in the meantime that the reports are not true again ... as in real life and its politics. Or politicians?)


Also, that error message includes 4 characters that are outside ISO
8859-x: 0x80 (twice), 0x8A, and 0x9A.  Your message was sent as:

        Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
        Content-Transfer-Encoding: quoted-printable

I work on Mac OS X and use Apple's Mail. I think it's so clever to use the encoding of the incoming message for the response's encoding. Looking at what Mail tells me about this eMail's encoding I see 'US-Standard' checked! Whatever this means ... I mean, outside the U.S. of A! The characters from outside any ISO 8859 encoding you mention can come from copying them in GNU Emacs, transferring them to the Mac OS X clipboard and then pasting them into Mail. At least *I* can see in your citation the same shapes that I saw in Emacs and in my message!


> Is it really that complicated to determine the system's TrueType fonts
> and use the Unicode encoded ones to print in whatever ISO, Greek, or
> Cyrillic encoding? Or in Arabic or Hebrew?

I don't know, but I suspect it is hard to do for all the platforms that
Emacs supports.

It can't be that problematic. There is just a handful of Unicode encoded fonts which are regular parts of a Linux or BSD distribution. Kind of a standard base edition. And there is too customisation. So a 'rich' user can make use of her or his set of fonts.

But the problem actually is inside the Elisp code for ps-print: it does a censorship on those glyphs it supposes they can't be printed. Here is an excerpt from an ISO 8859-15 encoded buffer:

          = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE
        ¡ = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK
        ¢ = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN
        £ = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN
        € = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN
        ¥ = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN

and here is that same region as censored by ps-print:

        LHL
        /f0 F
        (\240) S
        /f0 F
        ( = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE) S
        LHL
        /f0 F
        (\241) S
        /f0 F
        ( = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK) S
        LHL
        /f0 F
        (\242) S
        /f0 F
        ( = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN) S
        LHL
        /f0 F
        (\243) S
        /f0 F
        ( = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN) S
        LHL
        1 1 SB
        /f0 F
        ( = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN) S
        LHL
        /f0 F
        (\245) S
        /f0 F
        ( = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN) S

[LHL does a 'hard' linefeed, F selects an encoded font /f0, S does complicated things with the string in (), SB paints an empty box]

The Euro sign is taken away, although since five years or even longer no PostScript printer entered the market without being able to print a €. And you too see that ps-print leaves ¡, ¢, £ in the PS output -- although claiming the contrary!

From these bugs I'd like to estimate that Unicode Emacs 23 will be released before GNU Emacs 22. It's worth to go directly to Unicode, without wasting the valuable resources of the developers.


> I'd look forward to Unicode Emacs 23.

You'd be looking very far forward.

The elder you become, the easier it gets to look very far away! (I am writing from own experience.)

--
Greetings

  Pete                           <]
             o        __o         |__    o       HPV, the real
    ___o    /I       -\<,         |o \  -\),-%     high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________






reply via email to

[Prev in Thread] Current Thread [Next in Thread]