Re: special charcthers

From: Robert Bonomi (bonomi_at_host122.r-bonomi.com)
Date: 02/07/05 

Date: Mon, 07 Feb 2005 17:30:34 -0000

In article <slrnd0a8pl.4aj.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <this.address@is.invalid> wrote:
>2005-02-05, 18:29(-00), Robert Bonomi:
>[...]
>> Then there is the 'minor issue' of how those 'special/uncommon' symbols will
>> be displayed on _other_ devices -- e.g. your 'cent sign', above, showed here
>> as a lower-case letter 'o', with an accent grave -- no way in h*ll I'd have
>> guessed that you "meant" a cent-sign, if you hadn't expressly so stated. :)
>[...]
>
>Then, your news reader has to be broken or not MIME-compliant.

Thank you for playing.

The actual situation is "none of the above"

The news-reader software is fine.

The _dumb_terminal_ I'm using does not have the *HARDWARE* support needed.
There is _no_ 'cent sign' in the character generator 'memory'.

Given that situation, the news reader software has a very limited spectrum
of alternatives:
  1) don't send _any_ symbol for that character. (in effect "deleting" it
     from display)
  2) substitute a ASCII [SP] (in effect 'ignoring' the character)
  3) substitute a 'non-blank' filler character (indicating 'something
     "unprintable" goes here -- that *assumes* that the display device does
     have something that can be so used, however)
  4) pass the _unaltered_ symbol code to the device, and let the device
     decide 'what, if anything' to do with it.

"Pass the buck" (option 4), means that "pass the blame" also occurs. The
latter *is* appealing to designers in _any_ field -- when you can say "it's
not *my* fault" that the 'right thing' did *not* happen, life is easier. :)

>
>The OP clearly stated in the headers:
>Content-Type: text/plain; charset=iso-8859-1
>
>And in iso-8859-1, character number 162 has to be displayed as a
>Cent symbol, certainly not as « ò » (o accent grave).

You lie. "has to" is _not_ correct. "Should", or "is intended to" is closer
to reality.

Devices that do not have the physical capability to render the 'intended'
character *are* allowed to 'do the best they can, within their limitations'.

>Note that the characters with eighth bit on may be unusual or
>uncommon in English speaking countries but they are not
>elsewhere.

*ANY* character-set encoding "may be unusual or uncommon", somewhere, while
"not elsewhere".

BTW, "characters" do _not_ have an "eighth bit" (or any other 'bits', for
that matter). Characters are typographic symbols, with specific _shape_
characteristics. Numeric 'encodings' of characters have bits. sometimes
an 'eighth' bit; sometimes even higher-numbered ones.

>(even in Britain, £ (pound sign) is a non-ASCII character).

"BFD" applies. My original remark, as relates to "making sure that the
_receiving end_ can *DISPLAY*AS*INTENDED* the symbols used", does apply.

You can have a "MIME-compliant" message reader/displayer that does _not_
have support for some particular 'character-set' installed. If the sender
uses that character-set, the receiver will *not* see the message "as the
sender intended it".

For "communication" to occur, the sender and receiver must _agree_ on the
symbols used to exchange information. While it would seem, at first glance,
that this is an equal responsibility on both parties, in fact this is *NOT*
the case. The _sender_ does bear the greater responsibility. *THEY* have
the greater interest in ensuring that _communication_ occurs -- otherwise
they wouldn't be bothering to =send= the information in the first place.
This is not to say that the receiver has _no_ responsibility in the matter,
that is obviously not true.

The sender who _assumes_ *anything* about the capabilities of the recipient
is doing _exactly_ that -- making an ASSUMPTION. Even "assuming" ASCII as a
least-common-denominator is not necessarily reasonable, when dealing with
some Pacific Rim areas, for example.

In Western Europe, North America, and parts of Africa, you are *almost*sure*
to be safe in "assuming" the '48 printable' characters of the old IBM 026 key-
punch, and the IBM 1403 printer. You can *probably* rely on the 95 printable
characters of 7-bit US-ASCII. Anything beyond that, and a 'wise man' *will*
check to make sure that the recipient can 'speak the same language' as far as
the symbols used for communication.

Relevant Pages

  • Re: OT. Question.
    ... On my server it is all jumbled up. ... but instead the configuration of your news reader or mail ... Try to limit line length to 69-72 characters per line. ... Free download of technical exercises worth a lifetime of practice: ...
    (rec.music.classical.guitar)
  • Re: OT. Question.
    ... On my server it is all jumbled up. ... but instead the configuration of your news reader or mail ... Try to limit line length to 69-72 characters per line. ... Free download of technical exercises worth a lifetime of practice: ...
    (rec.music.classical.guitar)
  • Re: Who else uses Outlook Express here?
    ... Most replies I make work fine; the> characters go down the side, ... a couple of recipients only, on EVERY reply they will not appear! ... XanaNews is a news reader worth considering: ...
    (uk.net.web.authoring)
  • Re: Should all us pensioners be banned from driving? :(
    ... I just counted the 70 characters to a line on this group, ... It flows in mine so goes to the right side of the window then flows to the next line. ... It is difficult to read though because your news reader doesn't snip all text after the sig separator, so my news reader treats it all as a signature and shows it in a small grey font. ...
    (uk.people.silversurfers)
  • =?utf-8?B?UmU6IGZpbHRlciBvdXQgInN0cmFuZ2UiIHRleHQgaW4gcGVybCA/IMOtwrXilpPCvc+E4pSk4paRzqbDouKCpw
    ... Posting "strange characters" to Usenet is useless. ... Every news reader ... of bytes wherever it appears would be a horrible solution, ... You should find out why the disruptive strings are there in the first ...
    (comp.lang.perl.misc)