[Top][All Lists]

[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 14:00:55 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Peter Dyballa <address@hidden> writes:
> Trust me: with a bad font or fontset setup in a carbonized Emacs all
> your other settings are worthless: from where can Emacs take the
> glyph to display a number, a slot in a font's encoding? *This*
> mapping has to be correct! For example the Lucida Sans Typewriter
> font is for Mac OS X mac-cyrillic encoded although you can proof
> with other means that it's a "simple" Unicode font and the first few
> hundred code positions follow exactly the Unicode rule as for
> example shown in Character Palette, but since Mac OS X thinks
> different and maps 161 dec to some cyrillic glyph at U+04xx.

I understand that I'll need this if I want to view Unicode
characters, but it shouldn't be necessary if everything is 8-bit.

On my Windows system, setting a font is sufficient.  Characters in
the range 128-255 are simply displayed as-is.  Sure, if I specify an
encoding that differs from the font, I'll get the wrong characters,
but that's not really a big deal, since I won't be using Emacs to
work on Unicode files.

That being said, I visited the MacOS X Emacs list and used some of
their postings in conjunction with your advice to come up with this
addition to .emacs:

      (set-selection-coding-system 'mac-roman)
      (set-keyboard-coding-system 'mac-roman)
      (set-frame-font "fontset-david")
      (standard-display-8bit 128 255)

This allows hi-page characters generated by programs (like Gnus) to
be displayed, and I can still see the characters of my test document
after a find-file.  But I still see squares when I do a insert-file
into the scratch buffer or a newly-created document buffer.

> Make the fontsets match your inventory, make them usable at your
> site, and use them, then you'll see a difference in GNU Carbon
> Emacs.

I'll see what I can do here, but I really don't want to spend the
next month writing thousands of lines of lookup tables in order to do

> Did you look into the Help menu ->
> Describe -> Show all of Mule Status? (Is it self-compiled or did you
> fetch it from the net?  The OS version number looks unknown to
> me. From where did you fetch it?)

I just found out about that menu now, when you mentioned it.

WRT my version, I downloaded the sources using the instructions here:

and compiled my own copy.  Every binary distribution I've gotten has
failed to even launch, for some strange reason.  That particular
build was made on my system in January, so was probably MacOS 10.3.1
or 10.3.2.

I just downloaded and recompiled a new copy (on MacOS 10.3.7), in case
I was seeing a bug.  The new version is:

    GNU Emacs (powerpc-apple-darwin7.7.0) of 2004-12-29

But it didn't change anything.

> The t in your scratch buffer's mode-line stands for an undecided raw
> text: when you save it to a file you can decide about the coding
> system used for this. But till then Emacs does not know how to
> display character codes starting from 128 because there are so many
> coding systems in the world. So it has no real effect to force Emacs
> to display 8bit codes via (standard-display-8bit 128 255): Emacs is
> willing, and it is so by default, but which mapping do you wish?

Right.  And what I'm trying to do is tell it "assume mac-roman and
ignore everything else" because that's what will be generated when I
type those characters into a buffer.

> From which of the thousands of fonts can it take the glyphs? Try
> once: M-x set-frame-font TAB TAB -- and save this buffer for later
> contemplation!

I would hope, that after setting a single font for the frame, it
would realize that I want everything to be displayed according to
that one font.

This all was much simpler back in Emacs-19.  Everything was simple
and obvious before they started forcing users to re-invent the wheel.

-- David

reply via email to

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