unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: shamino@techie.com (David C.)
Subject: Re: Macintosh character display (128-255)
Date: Wed, 29 Dec 2004 14:00:55 GMT	[thread overview]
Message-ID: <m2zmzx2oh5.fsf@qqqq.invalid> (raw)
In-Reply-To: mailman.9707.1104324115.27204.help-gnu-emacs@gnu.org

Peter Dyballa <Peter_Dyballa@Web.DE> 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)
      (create-fontset-from-fontset-spec
       "-apple-courier-medium-r-normal--14-*-*-*-*-*-fontset-david,
ascii:-apple-courier-medium-r-normal--14-140-75-75-m-140-mac-roman,
latin-iso8859-1:-apple-courier-medium-r-normal--14-140-75-75-m-140-mac-roman,
mule-unicode-0100-24ff:-apple-courier-medium-r-normal--14-140-75-75-m-140-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
this.

> 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:

    http://members.shaw.ca/akochoi-emacs/stories/obtaining-and-building.html

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 21.3.50.1 (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

  parent reply	other threads:[~2004-12-29 14:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-29  9:56 Macintosh character display (128-255) David C.
2004-12-29 10:09 ` kurtz
2004-12-29 10:32 ` Peter Dyballa
     [not found] ` <mailman.9656.1104317240.27204.help-gnu-emacs@gnu.org>
2004-12-29 11:37   ` David C.
2004-12-29 12:26     ` Peter Dyballa
     [not found]     ` <mailman.9707.1104324115.27204.help-gnu-emacs@gnu.org>
2004-12-29 14:00       ` David C. [this message]
2004-12-29 14:59         ` David C.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2zmzx2oh5.fsf@qqqq.invalid \
    --to=shamino@techie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).