Re: grokking char encodings

[rustom]

On Feb 3, 1:53 am, Eli Zaretskii <e...@gnu.org> wrote:
> > From: rustom <rustompm...@gmail.com>
> > Date: Mon, 2 Feb 2009 00:16:19 -0800 (PST)
>
> > I browsed it in firefox (version 3.0.5).
> > When I save it as web-page  complete I get this behavior
> > When I save it as web-page html only it behaves well -- no unicode
> > boxes on printing, no ^Ms in emacs but it is css-free printing as far
> > as I can see
>
> With Firefox 2.0.0.20, I don't see any empty boxes, but I do see the
> ^M characters.  This happens because the very first line of the file
> written by Firefix has a Unix-style EOL: a single LF character, while
> the rest of the lines end with DOS-style CR-LF pair.
>
> > emacs-version shows 22.1.1 on windows XP service pack 2
>

> Put cursor on one of the empty boxes and type "C-u C-x =".  Emacs will
> pop a buffer describing the character it sees at that point.  Post
> that here, and maybe I or someone else could explain that to you.
Heres the output (seems like a space to me :-)


  character: SPC (32, #o40, #x20, U+0020)
    charset: ascii (ASCII (ISO646 IRV))
 code point: #x20
     syntax:    which means: whitespace
   category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0])
l:Latin
buffer code: #x20
  file code: #x20 (encoded by coding system iso-latin-1-unix)
    display: by this font (glyph code)
     -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-
iso8859-1 (#x20)

There are text properties here:
  fontified            t

--------------------------------------
Note that in my diagnosis emacs is slightly confused
firefox is more confused.
emacs' confusion is the ^Ms at EOLs
ff shows the file normally in normal browse mode
shows it funny in print preview mode (the characters seem to run into
each other)
and prints unicode boxes only in actual (hardcopy) printing

Anyhow this seems to be a moving target.  The html/css/js seem to be
under intensive development