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

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

Re: Macintosh character display (128-255)


From: David C.
Subject: Re: Macintosh character display (128-255)
Date: Wed, 29 Dec 2004 11:37:19 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Peter Dyballa <Peter_Dyballa@Web.DE> writes:
> Am 29.12.2004 um 10:56 schrieb David C.:
> 
>> I'm running Emacs 21.3.50, compiled for Macintosh OS X 10.3.
> 
> Are you running it in Terminal, or as carbonized Emacs natively in
> Aqua, or as very good programme under X11?

A carbonized Emacs natively in Aqua.  emacs-version reports:

    GNU Emacs 21.3.50.1 (powerpc-apple-darwin7.2.0) of 2004-01-18

When I run in a terminal window, this problem doesn't happen.  All
the characters always display with the expected glyphs, based on what
font the Terminal window is configured to use.

>> I have set up my system to display the mac-roman version of the
>> courier font for all frames, and to display all hi-page characters
>> as-is, since the font contains glyphs for them all.  The relevant
>> lines from my .emacs file are:
>>
>>     (set-default-font
>>      "-apple-courier-medium-r-normal--14-*-*-*-*-*-mac-roman")
> 
> This is too short! Later more.
> 
>>     (setq default-frame-alist
>>           (append
>>            '((width . 80)
>>              (height . 104)
>>              (font .
>> "-apple-courier-medium-r-normal--14-*-*-*-*-*-mac-roman"))
>>            default-frame-alist))
>>
>>     (standard-display-8bit 128 255)
> 
> I think that's not needed.
> 
>> Using this setup, I find that the hi-page characters still don't
>> display properly.  I get the hollow rectanlges (some extra-wide)
>> representing those characters in all newly-created buffers.  If I
>> load a file with these characters, however, they display OK.
>>
>> As a test, I created a simple text file containing all 128 of the
>> hi-page characters.
>>
>> If I load the buffer (C-x C-f <filename>), all of the hi-page
>> characters display correctly.
> 
> Which coding-system is displayed in the modeline?

The mode-line doesn't seem to show one:

    -:---Emacs  upper-ascii.txt   All L1    (Text Fill)-----------

>> If instead, I create a new buffer (or simply switch to the scratch
>> buffer) and insert the contents of that same file (C-x i <filename>),
>> the even-numbered hi-page characters all display as boxes and the
>> odd-numbered hi-page characters all display as a capital "A" with an
>> umlaut over it.
> 
> Again: which coding-system? You have to teach Emacs to prefer some
> coding-system. If it's running in Terminal, then Terminal should be
> set  to UTF-8, and under X11 and in Terminal you should make Emacs use
> UTF-8  too.

The mode-line here is different:

    -t:**-Emacs  *scratch*      All L1    (Lisp Interaction)---------

According to list-coding-systems, the "t" indicates raw-text

>> I don't think this a frame-setting problem, because I see the problem
>> when both buffers are displayed in the same frame.
>>
>> The "new buffer" behavior is also exhibited when reading messages
>> with Gnus.
>>
>> If I comment off the font-changes from my .emacs file, I get the same
>> behavior as before, but with latin-1 characters displayed for loaded
>> files instead of mac-roman characters.
>>
>> If I comment off the "standard-display-8bit" call, I see a variation
>> on the same behavior.  New buffers show all of the hi-page characters
>> as their octal equivalents, while loaded buffers show octal for the
>> range of 128-159
> 
> In Unicode and ISO Latin these are control codes, only Mac Roman and
> maybe Windows too uses this range as characters. So in a Unicode or
> Latin buffer you can't anything else than octal values.

Mac-Roman is 8-bit and has characters in these positions.  When I
call standard-display-8bit to force the display of these characters,
and do a find-file, the characters in those positions are displayed
with the characters in those positions.

>> Could someone point me in the right direction.  Or even better,
>> suggest a change to my .emacs that will force newly-created buffers
>> to display the mac-roman encoding for all of the hi-page characters?
> 
> Here is a setup for a .emacs file:

I'll try some of this, but it's going to need quite a bit of editing,
since it is setting up all kinds of things that (I hope) are
unrelated to this problem.  (For instance, you LaTeX hooks).

I pulled these lines from your .emacs:

      (set-variable 'file-name-coding-system           'utf-8)
      (set-variable 'default-buffer-file-coding-system 'mac-roman-unix)
      (set-default-coding-systems                      'mac-roman-unix)
      (set-keyboard-coding-system                      'mac-roman)
      (prefer-coding-system                            'mac-roman-unix)

When I do this, every buffer is created in the Mac-Roman encoding.
And as a result of this, every buffer (whether new or loaded) shows my
test file as nothing but empty squares.  In other words, it made the
problem worse.

As for all the fontset work, I appreciate your assistance here, but I
really don't think fontsets are the issue.  As I wrote originally, my
existing font configuration _DOES_ show the required characters when
I do a find-file on the buffer.  It only has problems for new
buffers.  And all buffers in all frames are using the same font.

> The fontsets are bit more complicated (excerpts from other postings to
> the Mac OS X Emacs list
> List Post: <mailto:macosx-emacs@email.esm.psu.edu>
> List Archives: <http://www.esm.psu.edu/mac-tex/MacOSX-Emacs-Digests/> ):

This is a resource I didn't know about.  Thanks.

-- David


reply via email to

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