MIME types and text versus plain

[David Stone]

Slightly OT, but I know some of the regulars here have more
experience with these things...

Is there an RFC I can cite which explains that, in a MIME multipart
message or document, the section described as

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

should NOT be chock full of html tags and &xxxx; entities, especially
when immediately followed by _exactly_ the same content denoted as

Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

?

The offending piece of web-based software responsible for this
is Blackboard Learn 9.1, and I sincerely hope none of you have to
deal with this monstrosity on a daily basis.

[Andreas Prilop]

On Fri, 16 Nov 2012, David Stone wrote:

> Is there an RFC I can cite which explains that, in a MIME
> multipart message or document, the section described as
> Content-Type: text/plain; charset=UTF-8

> should NOT be chock full of html tags and &xxxx; entities,

<strong>Of course not.</strong> You are free to write anything
including <em>HTML tags</em> and <em>HTML entities</em>
into a <code>text/plain</code> message.

> The offending piece of web-based software responsible for this
> is Blackboard Learn 9.1, and I sincerely hope none of you have
> to deal with this monstrosity on a daily basis.

When you reply, quote the text/plain part with all its HTML
markup. ;-)

--
¹ superscript 1 ¼ fraction 1/4 Ð D stroke Þ Thorn
² superscript 2 ½ fraction 1/2 ð d stroke þ thorn
³ superscript 3 ¾ fraction 3/4 Ý Y acute
× multiply sign ¦ broken bar ý y acute

[David Stone]

In article
<Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,

Andreas Prilop <prilo...@trashmail.net> wrote:

> On Fri, 16 Nov 2012, David Stone wrote:
>
> > Is there an RFC I can cite which explains that, in a MIME
> > multipart message or document, the section described as
> > Content-Type: text/plain; charset=UTF-8
> > should NOT be chock full of html tags and &xxxx; entities,
>
> <strong>Of course not.</strong> You are free to write anything
> including <em>HTML tags</em> and <em>HTML entities</em>
> into a <code>text/plain</code> message.

But what would be the point of that when you have text/html
as a declarative option? Seriously?

And surely the intent of software that claims to send both
plain text and html text versions of a message in an email
ought to be that one should be full of tag soup and the
other should not?

[Andreas Prilop]

On Fri, 16 Nov 2012, David Stone wrote:

>> <strong>Of course not.</strong> You are free to write anything
>> including <em>HTML tags</em> and <em>HTML entities</em>
>> into a <code>text/plain</code> message.
>
> But what would be the point of that when you have text/html
> as a declarative option?

Of course it is pointless. But you are free to produce
pointless messages.

> And surely the intent of software that claims to send both
> plain text and html text versions of a message in an email
> ought to be that one should be full of tag soup and the
> other should not?

No doubt this software is broken and produces nonsense.
But you are free to produce and send nonsense messages.
From what you say, I think there is nothing *formally*
incorrect.

You cannot argue with RFCs here. Write to the senders
(and programmers) and explain what is wrong.
But nothing is *formally wrong*.

--
Outgoing mail is certified free from defamation of Islam™
and insult of the Prophet™.
Checked by Thinkpol anti-obscenity system v. 6.66.

[Barry Margolin]

In article
<Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,
Andreas Prilop <prilo...@trashmail.net> wrote:

> On Fri, 16 Nov 2012, David Stone wrote:
>
> >> <strong>Of course not.</strong> You are free to write anything
> >> including <em>HTML tags</em> and <em>HTML entities</em>
> >> into a <code>text/plain</code> message.
> >
> > But what would be the point of that when you have text/html
> > as a declarative option?
>
> Of course it is pointless. But you are free to produce
> pointless messages.
>
> > And surely the intent of software that claims to send both
> > plain text and html text versions of a message in an email
> > ought to be that one should be full of tag soup and the
> > other should not?
>
> No doubt this software is broken and produces nonsense.
> But you are free to produce and send nonsense messages.
> From what you say, I think there is nothing *formally*
> incorrect.
>
> You cannot argue with RFCs here. Write to the senders
> (and programmers) and explain what is wrong.
> But nothing is *formally wrong*.

I suppose you could say that if the intent is that the two alternatives
should display the same text, modulo formatting, then including the HTML
markup in the text/plain alternative violates the spec. The spec
presumably says that HTML tags should be interpreted in text/html, and
presented verbatim in text/plain.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[David E. Ross]

Note that, when a message is both HTML-formatted and ASCII-formatted,
the HTML bloat is compounded. If the meaning of the message can be
fully expressed in ASCII, what is the point of also formatting it in HTML?

--

David E. Ross
<http://www.rossde.com/>

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Eli the Bearded]

In comp.infosystems.www.authoring.html,
Andreas Prilop <prilo...@trashmail.net> wrote:

This whole thread seems like it would be more appropriate for comp.mail.mime.

> On Fri, 16 Nov 2012, David Stone wrote:
> > And surely the intent of software that claims to send both
> > plain text and html text versions of a message in an email
> > ought to be that one should be full of tag soup and the
> > other should not?
> No doubt this software is broken and produces nonsense.
> But you are free to produce and send nonsense messages.
> From what you say, I think there is nothing *formally*
> incorrect.

RFC 1521
7.2.3. The Multipart/alternative subtype

The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In particular,
each of the parts is an "alternative" version of the same
information.

Systems should recognize that the content of the various parts
are interchangeable.

text/plain
It is wrong to think these two lines are interchangeanble.

text/plain
<p><b>It is wrong to think these two lines are interchangeanble.</b></p>


If the text/plain part doesn't have the same message as an alternative,
then it is wrong. Adding in all sorts of supposed to be hidden mark-up
and calling that a text/plain version is not a "formally correct" version
of multipart/alternative, even if the html itself can be a "formally
correct" text/plain message.

> You cannot argue with RFCs here. Write to the senders
> (and programmers) and explain what is wrong.
> But nothing is *formally wrong*.

You are looking at the RFCs far too narrowly.

Personally, as someone who prefers to use the text/plain version of
multipart/alternative messages, I find it is a very difficult task to
get people to see that the text/plain versions they produce are wrong.
Most people are not interested in the text/plain version and are not
testing the text/plain version and are only dimly aware of the existence
of a text/plain version.

Elijah
------
uses text/plain version of flickr mail to automatically put photos in sets

[Barry Margolin]

In article <k86b4n$fpe$1...@news.albasani.net>,

"David E. Ross" <nob...@nowhere.invalid> wrote:

> On 11/16/12 10:17 AM, David Stone wrote:
> > In article
> > <Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,
> > Andreas Prilop <prilo...@trashmail.net> wrote:
> >
> >> On Fri, 16 Nov 2012, David Stone wrote:
> >>
> >>> Is there an RFC I can cite which explains that, in a MIME
> >>> multipart message or document, the section described as
> >>> Content-Type: text/plain; charset=UTF-8
> >>> should NOT be chock full of html tags and &xxxx; entities,
> >>
> >> <strong>Of course not.</strong> You are free to write anything
> >> including <em>HTML tags</em> and <em>HTML entities</em>
> >> into a <code>text/plain</code> message.
> >
> > But what would be the point of that when you have text/html
> > as a declarative option? Seriously?
> >
> > And surely the intent of software that claims to send both
> > plain text and html text versions of a message in an email
> > ought to be that one should be full of tag soup and the
> > other should not?
> >
>
> Note that, when a message is both HTML-formatted and ASCII-formatted,
> the HTML bloat is compounded. If the meaning of the message can be
> fully expressed in ASCII, what is the point of also formatting it in HTML?

Because it's "prettier". Style matters to many people.

[David E. Ross]

Yes, to many people, appearance is more important than content.
However, appearance does not convey information; only content does that.

[tlvp]

On Fri, 16 Nov 2012 13:17:53 -0500, David Stone wrote:

> But what would be the point of that when you have text/html
> as a declarative option? Seriously?
>
> And surely the intent of software that claims to send both
> plain text and html text versions of a message in an email
> ought to be that one should be full of tag soup and the
> other should not?

You said it's Blackboard Learn, didn't you? The intent may be to let
recipients learn what the HTML tag soup actually is that results in the
prettified html text version of the message :-) .

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Barry Margolin]

In article <k87bsj$r75$1...@news.albasani.net>,

So? There's more to life than just information.

If a web site is styled using 1990's HTML, with few graphics, and simple
layout, people are more likely to think that they didn't put much effort
into it, and it's probably not worth much, than think "That's fine, the
information I need is there."

Maybe it's not rational, but neither are most people.

[Andreas Prilop]

On Fri, 16 Nov 2012, Barry Margolin wrote:

> "David E. Ross" wrote:
>> If the meaning of the message can be fully expressed in ASCII,

Correct: “can be fully expressed in plain text”
HTML text may be in ASCII; plain text may be non-ASCII.

>> what is the point of also formatting it in HTML?
>
> Because it's "prettier". Style matters to many people.

In my experience, almost all people sending text/html
do not style at all. They probably don’t even know what
they are sending (i.e. HTML text).

[Beauregard T. Shagnasty]

Andreas Prilop wrote:

> Barry Margolin wrote:
>> "David E. Ross" wrote:
>>> If the meaning of the message can be fully expressed in ASCII,
>
> Correct: “can be fully expressed in plain text”
> HTML text may be in ASCII; plain text may be non-ASCII.
>
>>> what is the point of also formatting it in HTML?
>>
>> Because it's "prettier". Style matters to many people.
>
> In my experience, almost all people sending text/html do not style at
> all. They probably don’t even know what they are sending (i.e. HTML
> text).

I concur with your experience. Virtually *all* of the personal email I
receive in HTML is merely 'plain text' in some standard default font,
size, and color. No styling whatsoever. Most of it comes from web-based
email systems (the yahoo/hotmail/gmail users). They don't know what they
are doing.

The only HTML styling I see is in commercial email notices (bank, etc) and
of course in spam.

--
-bts
-This space for rent, but the price is high

[David E. Ross]

So people are sending E-mail to spread aesthetics and not to communicate?

[dorayme]

In article
<Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,
Andreas Prilop <prilo...@trashmail.net> wrote:

> HTML text may be in ASCII; plain text may be non-ASCII.

Plain text, unlike ASCII, includes a smidgen of formatting help - to
wit, some return codes that make for paragraphs. Anything else?

--
dorayme

[Jukka K. Korpela]

2012-11-18 0:31, dorayme wrote:

> Plain text, unlike ASCII, includes a smidgen of formatting help - to
> wit, some return codes that make for paragraphs. Anything else?

Are you under the impression that ASCII does not contain control
characters? See
http://www.cs.tut.fi/~jkorpela/chars/c0.html
(based on actually reading the ASCII standard).

ObHTML: Only three of them, namely 0x09 HT, 0x0A LF, and 0x0D CR are
allowed in an HTML document, by
http://www.w3.org/TR/REC-html40/sgml/sgmldecl.html

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[John W Kennedy]

John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

[John W Kennedy]

On 2012-11-17 06:46:42 +0000, David E. Ross said:

If you are actually denying that there is semantic content in, e.g.,
font changes, indentation, and paragraph breaks, I suggest that you
back away from your computer and spend the next year or two reading
books printed in the 19th and 20th centuries.

--
John W Kennedy
"...when you're trying to build a house of cards, the last thing you
should do is blow hard and wave your hands like a madman."
-- Rupert Goodwins

[Chris F.A. Johnson]

In what way is any of that semantic content?


--
Chris F.A. Johnson
<http://torontowebdesign.cfaj.ca/>

[Christoph Becker]

John W Kennedy wrote:
> If you are actually denying that there is semantic content in, e.g.,
> font changes, indentation, and paragraph breaks, I suggest that you back
> away from your computer and spend the next year or two reading books
> printed in the 19th and 20th centuries.

IMHO you're right! There's quite some semantic meaning in font changes
(of course restricted to font-weight and font-style [1]), indentation
and paragraph breaks.

Unfortunately it's not even *possible* to use and convey any of it
with /plain text/ mails... at least, if you use a newsreader that's
apparently optimized for the more questionable parts of usenet, and
ignores the "basics".

In this case, I suggest that you back away from your computer and spend
the next decade or two reading any books you like, until your newsreader
is able to cater for the most basic text formatting.

Sorry for being so harsh---but apparently you do not have the slightest
clue, what you're talking about. What doesn't imply that I do.

[1] Using different font-families within a single paragraph also conveys
a semantic meaning: *typically* this crap can be ignored.

--
Christoph M. Becker

[Joy Beeson]

On Sat, 17 Nov 2012 20:09:24 -0500, "Chris F.A. Johnson"
<cfajo...@gmail.com> wrote:

> In what way is any of that semantic content?

I don't know how you are defining "semantic", but I spend hours
putting paragraph breaks in the right places. When some tom-fool
graphic designer wipes them all out because a great slab of
undifferentiated words all smooshed together is "prettier", I tend to
get a mite testy.

Spacesarecontenttoo.

--
Joy Beeson
joy beeson at comcast dot net
http://roughsewing.home.comcast.net/
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.

[Christoph Becker]

Joy Beeson wrote:
> On Sat, 17 Nov 2012 20:09:24 -0500, "Chris F.A. Johnson"
> <cfajo...@gmail.com> wrote:
>
>> In what way is any of that semantic content?
>
> I don't know how you are defining "semantic", but I spend hours
> putting paragraph breaks in the right places. When some tom-fool
> graphic designer wipes them all out because a great slab of
> undifferentiated words all smooshed together is "prettier", I tend to
> get a mite testy.
>
> Spacesarecontenttoo.

Unfortunately neither spaces nor "paragraph breaks" [1] are allowed in
plain text messages. [2]

[1] Semantically there is no such thing as a "paragraph break". You can
have a paragraph; you can have a line break---but you can't have a
"paragraph break".

[2] Of course I'm just kidding :)

--
Christoph M. Becker

[Thomas 'PointedEars' Lahn]

Christoph Becker wrote:

> Unfortunately neither spaces nor "paragraph breaks" [1] are allowed in
> plain text messages. [2]

I am not so sure about the latter. The <VT> character could be used.

> [1] Semantically there is no such thing as a "paragraph break". You can
> have a paragraph; you can have a line break---but you can't have a
> "paragraph break".

<http://en.wikipedia.org/wiki/Paragraph#Paragraph_breaks>

> [2] Of course I'm just kidding :)

I'm not.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

[Barry Margolin]

In article <k88bt9$1vl$1...@news.albasani.net>,

I don't think it's needed much for personal email. The most styling I've
ever put in a personal email is marking an occasional word in bold or
italics.

But if you're sending out an email newsletter for instance, HTML makes
sense.

[David E. Ross]

Aha! For several reasons, I have always believed that newsletters
should be Web pages on a Web server and not sent as E-mail. See my
<http://www.rossde.com/internet/newsletters.html>.

Yes, there should be E-mail for a newsletter: a very brief message
indicating a new edition of the newsletter and a link to its Web page.

[Ed Mullen]

See first paragraph in:

http://en.wikipedia.org/wiki/Semantics


--
Ed Mullen
http://edmullen.net/
Bad breath is better than no breath.

[Christoph Becker]

Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Unfortunately neither spaces nor "paragraph breaks" [1] are allowed in
>> plain text messages. [2]
>
> I am not so sure about the latter. The <VT> character could be used.

I hardly can see any advantage of using a <VT> instead of a double line
break to separate paragraphs in plain text messages.

>
>> [1] Semantically there is no such thing as a "paragraph break". You can
>> have a paragraph; you can have a line break---but you can't have a
>> "paragraph break".
>
> <http://en.wikipedia.org/wiki/Paragraph#Paragraph_breaks>

Obviously one can have paragraph breaks. I stand corrected. But still:
doesn't a text conceptionally consist of paragraphs, or does it consist
of paragraphs and paragraph breaks or even words and paragraph breaks?

>
>> [2] Of course I'm just kidding :)
>
> I'm not.

I'm not surprised :)
>
>
> PointedEars

--
Christoph M. Becker

[Chris F.A. Johnson]

On 2012-11-18, Ed Mullen wrote:
> Chris F.A. Johnson wrote:
>> On 2012-11-18, John W Kennedy wrote:

...

>>>> Yes, to many people, appearance is more important than content.
>>>> However, appearance does not convey information; only content does that.
>>>
>>> If you are actually denying that there is semantic content in, e.g.,
>>> font changes, indentation, and paragraph breaks, I suggest that you
>>> back away from your computer and spend the next year or two reading
>>> books printed in the 19th and 20th centuries.
>>
>> In what way is any of that semantic content?
>
> See first paragraph in:
>
> http://en.wikipedia.org/wiki/Semantics

Right. It's the words, not their presentation, that has semantic
content.

[dorayme]

In article <8nqnn9-...@cfa.johnson>,

"Chris F.A. Johnson" <cfajo...@gmail.com> wrote:

Depends on what quite you mean by presentation. Obviously you would
not be including word order, the order is critical to meaning. In fact
a unit of meaning is rather whole sentences; and now and then it might
be more accurate to say a set of sentences, even a paragraph or
stretching it, a series of paragraphs. Meaning comes from contexts and
background understandings, often supplied outside particular small
sets of words.

--
dorayme

[tlvp]

On Sun, 18 Nov 2012 19:02:16 +0100, Christoph Becker wrote:

> doesn't a text conceptionally consist of paragraphs, or does it consist
> of paragraphs and paragraph breaks or even words and paragraph breaks?

In my world, paragraph breaks separate successive paragraphs from one
another, just as line breaks separate successive lines from each other (and
spaces separate successive words from each other). But what do I know :-) ?

[Jukka K. Korpela]

2012-11-18 23:55, tlvp wrote:

> On Sun, 18 Nov 2012 19:02:16 +0100, Christoph Becker wrote:
>
>> doesn't a text conceptionally consist of paragraphs, or does it consist
>> of paragraphs and paragraph breaks or even words and paragraph breaks?
>
> In my world, paragraph breaks separate successive paragraphs from one
> another, just as line breaks separate successive lines from each other (and
> spaces separate successive words from each other). But what do I know :-) ?

There are two schools, or approaches, here. The classical view is that
text is divided into paragraphs, normally with one paragraph discussing
one topic, describing a short course of events, or something like that.
In speech, there is usually a noticeable pause between paragraphs,
supported by changes in voice. In this view, a line is just a physical
unit necessitates by the characteristics of presentation, and the
division into lines is a typographic question. This is more or less the
HTML model too, manifested in the <p> element, reflecting word processor
practices.

A different view is that lines can be basic units of text, so that the
division into lines is significant. This is natural in some rather
different areas of human activities, such as poetry and programming. In
this approach, a paragraph may be viewed as a container for lines,
rather than just container for text. HTML has no natural "line" concept
in this sense.

You can use <br> of course, but it does not create elements. To make a
line an element that can be styled and processed in scripting, you would
have to wrap it inside <span ...>...</span> and still use <br>, or you
would have to use <div ...>...</div> for a line, and then you can't use
a <p> as a container but need to use <div> (or maybe <section> if you
are an HTML5 believer).

There's the option of using <pre>, but that's more like an escape from
HTML to plain text rather than good HTML.

So HTML is rather primitive in this area. It's mostly a miracle that
HTML became a success. ;-)

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Joy Beeson]

On Sat, 17 Nov 2012 22:46:53 -0500, Barry Margolin
<bar...@alum.mit.edu> wrote:

> But if you're sending out an email newsletter for instance, HTML makes
> sense.

And if I click "view message body as plain text", I can actually read
it, if it isn't too scrambled.

What brought on the current fad for pale-grey letters on sorta-white?

[dorayme]

In article <s3via8ldhlv62nnnt...@4ax.com>,

Joy Beeson <jbe...@invalid.net.invalid> wrote:

> What brought on the current fad for pale-grey letters on sorta-white?

This question has been asked many times. It has no particularly good
answer.

--
dorayme

[Adam H. Kerman]

Andreas Prilop <prilo...@trashmail.net> wrote:
>On Fri, 16 Nov 2012, Barry Margolin wrote:
>> "David E. Ross" wrote:

>>> If the meaning of the message can be fully expressed in ASCII,

>Correct: “can be fully expressed in plain text”
>HTML text may be in ASCII; plain text may be non-ASCII.

>>> what is the point of also formatting it in HTML?

>> Because it's "prettier". Style matters to many people.

>In my experience, almost all people sending text/html
>do not style at all. They probably don’t even know what
>they are sending (i.e. HTML text).

Why do you send articles with quoted-printable transfer enconding?

[Manuel Collado]

El 19/11/2012 0:08, Jukka K. Korpela escribió:
> 2012-11-18 23:55, tlvp wrote:
>
>> On Sun, 18 Nov 2012 19:02:16 +0100, Christoph Becker wrote:
>>
>>> doesn't a text conceptionally consist of paragraphs, or does it consist
>>> of paragraphs and paragraph breaks or even words and paragraph breaks?

>> ...

>
> There are two schools, or approaches, here. The classical view is that

> text is divided into paragraphs, ...

>
> A different view is that lines can be basic units of text, so that the

> division into lines is significant...
>
> You can use <br> of course, but it does not create elements...

>
> There's the option of using <pre>, but that's more like an escape from
> HTML to plain text rather than good HTML.
>
> So HTML is rather primitive in this area. It's mostly a miracle that
> HTML became a success. ;-)

HTML's simplicity is probably a key factor for its success.

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

[Jukka K. Korpela]

2012-11-19 13:19, Manuel Collado wrote:

>> So HTML is rather primitive in this area. It's mostly a miracle that
>> HTML became a success. ;-)
>
> HTML's simplicity is probably a key factor for its success.

Simplicity isn't the same as primitiveness. But original HTML was fairly
simple too. However, this wasn't really the key.

HTML became a success because it was needed to create web pages; there
were no serious competitors. Plain text is too limited. The potential of
PDF was not widely known, and browsers don't handle PDF natively. MS
Word suffers from being proprietary and from not being handled by
browsers natively.

But even though the competitors had too serious issues (as publishing
formats on the web), any of them worked better in the area of paragraphs
than HTML originally did (before the advent of CSS).

Think about indenting the first line of each paragraph - the age-old
convention in print media. It's easier to achieve that even in plain
text than in HTML, since in HTML, leading whitespace is ignored, and you
would need the trick of using no-break spaces, and for various reasons
people actually typed &nbsp;&nbsp;. That's primitive. The simple way is
e.g. to set first-line indent in paragraph style in MS Word, or - in the
modern days - in CSS.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Thomas 'PointedEars' Lahn]

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> Unfortunately neither spaces nor "paragraph breaks" [1] are allowed in
>>> plain text messages. [2]
>> I am not so sure about the latter. The <VT> character could be used.
>
> I hardly can see any advantage of using a <VT> instead of a double line
> break to separate paragraphs in plain text messages.

It was a distinct possibility.

>>> [1] Semantically there is no such thing as a "paragraph break". You can
>>> have a paragraph; you can have a line break---but you can't have a
>>> "paragraph break".
>>
>> <http://en.wikipedia.org/wiki/Paragraph#Paragraph_breaks>
>
> Obviously one can have paragraph breaks. I stand corrected. But still:
> doesn't a text conceptionally consist of paragraphs, or does it consist
> of paragraphs and paragraph breaks or even words and paragraph breaks?

Since we are in .html, for me the answer definitely is no. I am using P/p
elements instead of consecutive BR/br elements, and strongly recommend that
to others.

>>> [2] Of course I'm just kidding :)
>> I'm not.
>
> I'm not surprised :)

You should be.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

[John W Kennedy]

On 2012-11-18 18:02:16 +0000, Christoph Becker said:
> Obviously one can have paragraph breaks.

Actually, in true plain text, one can't; one can have only line breaks.
Flowable text, as is used in modern email, allows simulation of
ordinary paragraphs, but does not permit inset paragraphs or reverse
indents. (You could use the 1C-1F characters, I suppose, but it could
never be more than a private convention.)

--
John W Kennedy
A proud member of the reality-based community.

[Andreas Prilop]

On Mon, 19 Nov 2012, Adam H. Kerman wrote:

> Why do you send articles with quoted-printable transfer enconding?

Because they show up correctly at groups.google.com.

--
Outgoing mail is certified free from defamation of Islam™
and insult of the Prophet™.
Checked by Thinkpol anti-obscenity system v. 6.66.

[tlvp]

On Sun, 18 Nov 2012 19:28:40 -0500, Joy Beeson wrote:

> What brought on the current fad for pale-grey letters on sorta-white?

Belgian white-on-white table linens, I suppose :-) . Cheers, -- tlvp

[Christoph Becker]

John W Kennedy wrote:
> On 2012-11-18 18:02:16 +0000, Christoph Becker said:
>> Obviously one can have paragraph breaks.
>
> Actually, in true plain text, one can't; one can have only line breaks.
> Flowable text, as is used in modern email, allows simulation of ordinary
> paragraphs, but does not permit inset paragraphs or reverse indents.
> (You could use the 1C-1F characters, I suppose, but it could never be
> more than a private convention.)

IMHO not the paragraph break is the semantically important concept, but
rather the paragraph itself. The latter can easily be conveyed as such
even in conventional non-flowed plain text messages (which I prefer) by
just separating paragraphs with two consecutive line breaks (which might
be regarded as a paragraph break; if I'm not mistaken that's exactly
what's done in TeX).

This even allows for indented paragraphs. Either the indent has to be
typed in manually or the editor allows to automate this. In the latter
case it might be even possible to have reverse indents without any hassle.

I don't know how this is displayed on google groups or other web based
news readers, but OTOH I don't care too much about it. IMHO a usenet
newsgroup is best followed with a plain text newsreader. Who prefers
HTML or another markup language is probably better off with another
platform.

--
Christoph M. Becker

[Adam H. Kerman]

Andreas Prilop <prilo...@trashmail.net> wrote:
>On Mon, 19 Nov 2012, Adam H. Kerman wrote:

>>Why do you send articles with quoted-printable transfer enconding?

>Because they show up correctly at groups.google.com.

>--=20
>Outgoing mail is certified free from defamation of Islam=99
>and insult of the Prophet=99.

>Checked by Thinkpol anti-obscenity system v. 6.66.

I doubt that unconventional .sig delimiter shows up correctly anywhere.
Also, you've changed you 8-bit character set. I'm not sure Google Groups
doesn't screw that up, too.

[Adam H. Kerman]

Jukka K. Korpela <jkor...@cs.tut.fi> wrote:

>Think about indenting the first line of each paragraph - the age-old
>convention in print media. It's easier to achieve that even in plain
>text than in HTML, since in HTML, leading whitespace is ignored, and you
>would need the trick of using no-break spaces, and for various reasons
>people actually typed &nbsp;&nbsp;. That's primitive. The simple way is
>e.g. to set first-line indent in paragraph style in MS Word, or - in the
>modern days - in CSS.

There's a reason why ghod invented the EM. That's the easy way to indent
the first line of a paragraph just the right amount. In a word processor,
if you change font size because you're trying to avoid having a few lines
after a page break, you really should adjust the first-line indent so it
looks right with the different font. Word processor styles don't make
relative adjustments to the first line indent like that.

When I was a newspaper reporter, we did everything but distribute the
paper. We did our own typesetting. I got to learn on a phototypesetter.
Alas, I'm not old enough to have set Monotype or Linotype, but that
would have been fun. The output from that phototypesetter was so much
denser than a typical laser printer, there was no comparison.

As any printer would use, the first line indent was an EM.

You don't want to use an EM for Courrier New when you're trying to
imitate typewriter output. It's not large enough.

[Jukka K. Korpela]

2012-11-20 7:44, Adam H. Kerman wrote:

> There's a reason why ghod invented the EM.

You mean the em unit, right? I have no informations abouts possible
dhivine intentions. Whatever they might have been, their manifestation
in the human world is that the em unit square was invented by some
people for use as a typographer’s conceptual device when designing a
font. And the em unit is the length of a side of that square.

> That's the easy way to indent
> the first line of a paragraph just the right amount.

According to Bringhurst (The Elements of Typographic Style, p. 40), one
em is the most common value for first-line indent. Not “just the right
amount” but the usual value. He adds that one lead (i.e., the line
height) is another common value; so in CSS, if you set e.g. line-height:
1.3, then you could have p { text-indent: 1.em; }. And he says that one
en (i.e., 0.5em) is the minimimum and that for long lines, 1½ or 2 em
“may look more luxurious”, but indents larger than 3em “are generally
counterproductive”. So there is a lot of variation.

In HTML (that is, plain HTML with no CSS cheating), you could do
first-line indents of a multiple of half an em by using the EN SPACE and
EM SPACE characters. Using other fixed-width characters is possible too.
But this 1) causes varying results when the font being used does not
contain those characters, 2) is not guaranteed to work, since the effect
of these characters has explicitly been declared as undefined in HTML
specs, 3) is very old-fashioned as these characters reflect hot lead
typesetting rather than modern approaches, 4) was not possible in
original HTML, which was limited to ISO-8859-1 characters.

> In a word processor,
> if you change font size because you're trying to avoid having a few lines
> after a page break, you really should adjust the first-line indent so it
> looks right with the different font. Word processor styles don't make
> relative adjustments to the first line indent like that.

Such things apply to word processor styles in general. They don’t use
the em concept, sadly enough.

> You don't want to use an EM for Courrier New when you're trying to
> imitate typewriter output. It's not large enough.

First-line indents were not commonly used in typewriting. Typewriting is
one of the things that gave us “technical paragraphs”, i.e. the
presentation style where paragraphs are separated by empty lines (with
no first-line indents).

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Adam H. Kerman]

Jukka K. Korpela <jkor...@cs.tut.fi> wrote:

>2012-11-20 7:44, Adam H. Kerman wrote:

>>There's a reason why ghod invented the EM.

>You mean the em unit, right? I have no informations abouts possible
>dhivine intentions. Whatever they might have been, their manifestation
>in the human world is that the em unit square was invented by some
>people for use as a typographer's conceptual device when designing a
>font. And the em unit is the length of a side of that square.

Yes.

>>That's the easy way to indent the first line of a paragraph just
>>the right amount.

>According to Bringhurst (The Elements of Typographic Style, p. 40), one
>em is the most common value for first-line indent.

It's in common use because it makes the paragraph easy to read. That's the
purpose of most typographical conventions.

>He adds that one lead (i.e., the line height) is another common value;
>so in CSS, if you set e.g. line-height: 1.3, then you could have p {
>text-indent: 1.em; }.

'Tis true. That's similarly easy to read, as it's only a slightly larger
horizontal space.

It's worth noting that these solutions were discovered long ago, that using
a relative amount of space for certain purposes is the best solution.

>In HTML (that is, plain HTML with no CSS cheating), you could do
>first-line indents of a multiple of half an em by using the EN SPACE and
>EM SPACE characters. Using other fixed-width characters is possible too.
>But this 1) causes varying results when the font being used does not
>contain those characters, 2) is not guaranteed to work, since the effect
>of these characters has explicitly been declared as undefined in HTML
>specs, 3) is very old-fashioned as these characters reflect hot lead
>typesetting rather than modern approaches, 4) was not possible in
>original HTML, which was limited to ISO-8859-1 characters.

I promise you that I avoided pouring hot lead into the phototypesetter
for surely that would have destroyed it. I'm not quite that old fashioned.

>>In a word processor, if you change font size because you're trying to
>>avoid having a few lines after a page break, you really should adjust
>>the first-line indent so it looks right with the different font. Word
>>processor styles don't make relative adjustments to the first line
>>indent like that.

>Such things apply to word processor styles in general. They don't use
>the em concept, sadly enough.

It bugged me because it was so much easier to do certain things on the
phototypesetter than with a word processor.

>>You don't want to use an EM for Courrier New when you're trying to
>>imitate typewriter output. It's not large enough.

>First-line indents were not commonly used in typewriting.

If I was typing a manuscript, I always used them. For a memo or a short
business letter, no indent.

[Chris F.A. Johnson]

On 2012-11-20, Jukka K. Korpela wrote:
...

> First-line indents were not commonly used in typewriting. Typewriting is

> one of the things that gave us ?technical paragraphs?, i.e. the

> presentation style where paragraphs are separated by empty lines (with
> no first-line indents).

Both indents and empty lines were common in typewriting.

[Adam H. Kerman]

Chris F.A. Johnson <cfajo...@gmail.com> wrote:

>On 2012-11-20, Jukka K. Korpela wrote:
>...

>>First-line indents were not commonly used in typewriting. Typewriting is
>>one of the things that gave us ?technical paragraphs?, i.e. the
>>presentation style where paragraphs are separated by empty lines (with
>>no first-line indents).

>Both indents and empty lines were common in typewriting.

If you were double spacing, as in a manuscript, you had to indent
paragraphs, otherwise you'd fail to spot them.

[Andreas Prilop]

On Tue, 20 Nov 2012, Adam H. Kerman wrote:

> X-Newsreader: trn 4.0-test76 (Apr 2, 2001)

>
>> --=20
>> Outgoing mail is certified free from defamation of Islam=99
>> and insult of the Prophet=99.
>

> I doubt that unconventional .sig delimiter shows up correctly anywhere.

Using a newsreader that does not understand MIME (defined in 1993)
is worse than using a web browser that does not understand CSS.

If your crippled newsreader is really unable to display MIME messages
correctly, you cannot complain. Get a newsreader that conforms to
standards of 1993.

> I'm not sure Google Groups doesn't screw that up, too.

<http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_thread/thread/21fedb43b2bf344/>
<https://groups.google.com/forum/?fromgroups=#!topic/comp.infosystems.www.authoring.html/Ah_ttDsr80Q>

--
Outgoing mail is certified free from defamation of Islam™
and insult of the Prophet™.

[John W Kennedy]

And I seem to remember being explicitly taught (my high-school had a
college-prep typing course) that an indent was five spaces, no more, no
less. (Although that's very wide by typographic standards.)

--
John W Kennedy
If Bill Gates believes in "intelligent design", why can't he apply it
to Windows?

[Warren Oates]

In article <50ab90ee$0$9828$607e...@cv.net>,

John W Kennedy <jwk...@attglobal.net> wrote:

> And I seem to remember being explicitly taught (my high-school had a
> college-prep typing course) that an indent was five spaces, no more, no
> less. (Although that's very wide by typographic standards.)

It's also wide by computer code formatting standards. I mostly start
with 3 spaces if I'm setting it up myself.
--

Soulless fruitflies are the nanotechnology of the fear industry -- Bucky

[tlvp]

On Tue, 20 Nov 2012 05:44:04 +0000 (UTC), Adam H. Kerman wrote:

> ... not old enough to have set Monotype or Linotype, but that
> would have been fun ...

If you call flesh and clothing burns from molten lead squirts "fun" :-) .

[tlvp]

On Tue, 20 Nov 2012 08:45:26 +0200, Jukka K. Korpela wrote:

> First-line indents were not commonly used in typewriting.

Mmm ... when I was taught typing, I was taught always to set up a first tab
stop about three characters from the left margin, so as to be able to
tab uniformly to a proper indentation depth when starting a new paragraph.

Of course, that was just in a little high school in NYC in the '50s, so it
could well have been a far from universal principle :-) .

[Chris F.A. Johnson]

On 2012-11-20, Tim Streater wrote:
> In article <nlsrn9-...@cfa.johnson>,

> "Chris F.A. Johnson" <cfajo...@gmail.com> wrote:
>

>> On 2012-11-20, Jukka K. Korpela wrote:
>> ...
>> > First-line indents were not commonly used in typewriting. Typewriting is
>> > one of the things that gave us ?technical paragraphs?, i.e. the
>> > presentation style where paragraphs are separated by empty lines (with
>> > no first-line indents).
>>
>> Both indents and empty lines were common in typewriting.
>

> And plenty of people still seems to treat Word and the like as glorified
> typewriters. They also press the return key a number of times at the end
> of any doc - perhaps they hope that paper will scroll out of the top of
> the display.
>

I once watched a secretary correcting a document in a word
processor; she was adding a word to the first line of a
paragraph.

As she added the word, the last word on the line dropped to
the next line, but it didn't flow into the rest of the
paragraph. There was a hard return at the end of the line.

She put a hard return where the new line ending was and joined
the word that had dropped to the next line. This forced the
last word of that line to move down. She put a hard return
where that line now ended and joined the word....

This continued to the end of the paragraph.

[Adam H. Kerman]

Andreas Prilop <prilo...@trashmail.net> wrote:
>On Tue, 20 Nov 2012, Adam H. Kerman wrote:

>>X-Newsreader: trn 4.0-test76 (Apr 2, 2001)

>>>--=20
>>>Outgoing mail is certified free from defamation of Islam=99
>>>and insult of the Prophet=99.

>>I doubt that unconventional .sig delimiter shows up correctly anywhere.

>Using a newsreader that does not understand MIME (defined in 1993)
>is worse than using a web browser that does not understand CSS.

It understands that I want characters passed along to the terminal
emulation just fine, thanks for your concern. It also parses for MIME
boundaries, so it's quite MIME aware. I am displaying the codes of the
characters which you so helpfully encoded using quoted-printable over
this very fine 8-bit clean medium of communication, which I then quoted
in followup. With a different setup, I'd be decoding them.

I don't think newsreaders expect an encoded space character in a delimiter,
but perhaps you're right.

>>I'm not sure Google Groups doesn't screw that up, too.

><http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_thread/thread/21fedb43b2bf344/>
><https://groups.google.com/forum/?fromgroups=#!topic/comp.infosystems.www.authoring.html/Ah_ttDsr80Q>

Google Groups claims those two pages are in UTF-8. You used two different
Latin 1 character sets. Various people have caught mistranslation problems
over the years. I'll have to check if the transformation is correct from these
two character sets to UTF-8.

One thing no one's ever said is that the things that Google screws up don't
get screwed up with the use of quoted-printable.

Has that been your experience and is that why you're using it? Can you give
me an example of non-encoded text that Google Groups would screw up?

I'm giving you the benefit of a doubt that you're doing this with purpose.

[Adam H. Kerman]

John W Kennedy <jwk...@attglobal.net> wrote:

>On 2012-11-20 12:14:26 +0000, Adam H. Kerman said:
>>Chris F.A. Johnson <cfajo...@gmail.com> wrote:
>>>On 2012-11-20, Jukka K. Korpela wrote:

>>>...

>>>>First-line indents were not commonly used in typewriting. Typewriting is
>>>>one of the things that gave us ?technical paragraphs?, i.e. the
>>>>presentation style where paragraphs are separated by empty lines (with
>>>>no first-line indents).

>>>Both indents and empty lines were common in typewriting.

>>If you were double spacing, as in a manuscript, you had to indent
>>paragraphs, otherwise you'd fail to spot them.

>And I seem to remember being explicitly taught (my high-school had a
>college-prep typing course) that an indent was five spaces, no more, no
>less. (Although that's very wide by typographic standards.)

Half an inch, so 5 spaces at 10 pitch (fixed-width characters per inch)
and 6 spaces at 12 pitch.

[Adam H. Kerman]

tlvp <mPiOsUcB...@att.net> wrote:
>On Tue, 20 Nov 2012 05:44:04 +0000 (UTC), Adam H. Kerman wrote:

>>... not old enough to have set Monotype or Linotype, but that
>>would have been fun ...

>If you call flesh and clothing burns from molten lead squirts "fun" :-) .

Hey, you actually did that? Interesting. I guess phototypesetters removed
all the danger from the occupation.

[Thomas 'PointedEars' Lahn]

Adam H. Kerman wrote:

> Andreas Prilop <prilo...@trashmail.net> wrote:
>> On Tue, 20 Nov 2012, Adam H. Kerman wrote:
>>> X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
>>>> --=20
>>>> Outgoing mail is certified free from defamation of Islam=99
>>>> and insult of the Prophet=99.
>>>
>>> I doubt that unconventional .sig delimiter shows up correctly anywhere.
>>
>> Using a newsreader that does not understand MIME (defined in 1993)
>> is worse than using a web browser that does not understand CSS.
>
> It understands that I want characters passed along to the terminal

> emulation just fine, thanks for your concern. […]

> I am displaying the codes of the characters which you so helpfully encoded
> using quoted-printable over this very fine 8-bit clean medium of

^^^^^^^^^^^
> communication,

How can you know that for sure? Maybe Andreas is – for some reason – still
on a 7-bit line? (See the bottom of this message.)

> which I then quoted in followup. With a different setup, I'd be decoding
> them.

It is possible to decode characters not found in US-ASCII into US-ASCII
forms that do not leave messages garbled and unreadable. For example, QP's
`=99' for the Windows-1252 `™' can be decoded as `(TM)'. There are tools
like iconv(1) which can automate that:

$ locale
LANG=de_CH.UTF-8
LANGUAGE=
LC_CTYPE="de_CH.UTF-8"
LC_NUMERIC="de_CH.UTF-8"
LC_TIME="de_CH.UTF-8"
LC_COLLATE="de_CH.UTF-8"
LC_MONETARY="de_CH.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="de_CH.UTF-8"
LC_NAME="de_CH.UTF-8"
LC_ADDRESS="de_CH.UTF-8"
LC_TELEPHONE="de_CH.UTF-8"
LC_MEASUREMENT="de_CH.UTF-8"
LC_IDENTIFICATION="de_CH.UTF-8"
LC_ALL=

$ echo '™' | iconv -t 'US-ASCII//TRANSLIT'
(TM)

(Extra care must be taken with German umlauts, though, which iconv(1) does
not.)

That said, the default character encoding for newer (at least five-year old
and newer) Unices is UTF-8. You must be using a really old (or
configurationally aged) terminal emulation. Maybe you want to upgrade to
the 21st century?

> I don't think newsreaders expect an encoded space character in a
> delimiter, but perhaps you're right.

A trailing space such as required for a proper signature delimiter MUST be
encoded in the Quoted-Printable (QP) Content-Transfer-Encoding (CTE), and my
newsreaders (among them, KNode/4.4.11) decode that properly. See
<http://en.wikipedia.org/wiki/Quoted-printable> and RFC 2045, section 6.7,
paragraph 3.

>>> I'm not sure Google Groups doesn't screw that up, too.
>
>><http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_thread/thread/21fedb43b2bf344/>
>><https://groups.google.com/forum/?fromgroups=#!topic/comp.infosystems.www.authoring.html/Ah_ttDsr80Q>
>
> Google Groups claims those two pages are in UTF-8.

There are no "pages", there are (HTML, XHTML, XML, …) _documents_.

Google Groups is (for once, correctly) using UTF-8 by default for the
display of those messages because you should do that (in a Web application)
when the character encoding in the user's locale (thus, the typed and
submitted message) is unknown. (Of all the Unicode encodings, UTF-8 is the
most space-efficient and most widely supported.)

> You used two different Latin 1 character sets.

No, he used US-ASCII and Windows-1252; only the latter is what could be
called a "Latin 1 character set" (it is a character _encoding_, not a
character set).

It is useful (more efficient) that a newsreader would fall back to the
character encoding for the smallest character set necessary to transfer the
message without garbling its content. You will notice that Andreas used the
<“>, <”>, and <™> (trade mark) characters in some of his messages, but not
in others, which made it necessary in the former to encode them with
something other than US-ASCII, in this case Windows-1252.

KNode/4.4.11 has this feature as well. As a result, this message's body
will be encoded with UTF-8 and declared as UTF-8-encoded because I used the
Unicode representations of Windows-1252 characters here. Had I not done
that, it would probably have been US-ASCII.

So we do not need Google Groups to "screw up" anything here.

> Various people have caught mistranslation problems over the years. I'll
> have to check if the transformation is correct from these two character
> sets to UTF-8.

See above, but:

US-ASCII is a subset of UTF-8 (again, character _encodings_); Windows-1252
is not, but there are only a few code points that differ from the character
set of the ISO-8859-1 encoding and (by extension) from Unicode:

<http://en.wikipedia.org/wiki/Windows-1252#Code_page_layout>

> One thing no one's ever said is that the things that Google screws up
> don't get screwed up with the use of quoted-printable.

ISTM that they find new things to screw up with regarding Internet messages
with each passing month, though. The quality of postings injected there is
not particularly high either, so I have UDP'd Google Groups in my newsreader
in April this year.

[If only there was a real UDP threat against Google as has been
(successfully) against others, things might change for the better. Without
that, it is evident to me that Google could not care less about Usenet that
enabled their Google Groups once, lack of newbie information and spam
*prevention* included. Their primary concern appears to be that the users
of *their* groups/mailing lists are happy.]

> Has that been your experience and is that why you're using it? Can you
> give me an example of non-encoded text that Google Groups would screw up?

That would be quite off-topic here. This thread has been drifting into
off-topicness since quite a few postings ago. (Do you remember that the
original posting was about *HTML tags* in plain-text messages?)

> I'm giving you the benefit of a doubt that you're doing this with purpose.

Andreas' reasons might be just historical, or due to his newsreader's
limitations. Certainly there is nothing wrong with using QP, or CTE in
general, even these days.

[Historically, CTE was introduced so that Internet messages with characters
that required more than 8 bits to encode (so everything beyond US-ASCII)
could be transferred safely over channels that would only allow 7 bits
(probably at first, from Europe to the US, whereas for the languages spoken
in the former you need more than US-ASCII). The then zero-valued MSB of the
octets would simply have been cut off without additional measures and loss
of information. (Therefore, `Content-Transfer-Encoding: 8 Bit' can be
omitted.)]


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

[Andreas Prilop]

On Wed, 21 Nov 2012, Adam H. Kerman wrote:

> I don't think newsreaders expect an encoded space character in a delimiter,

They do; perhaps you should check one of the others/newer yourself.

>><http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_thread/thread/21fedb43b2bf344/>
>><https://groups.google.com/forum/?fromgroups=#!topic/comp.infosystems.www.authoring.html/Ah_ttDsr80Q>
>
> Google Groups claims those two pages are in UTF-8.

Google transcodes (rather: tries to transcode) to UTF-8.
Of course, it is Google’s fault when failing to transcode and
to display 8bit messages correctly.

> One thing no one's ever said is that the things that Google screws up
> don't get screwed up with the use of quoted-printable.
> Has that been your experience and is that why you're using it? Can you
> give me an example of non-encoded text that Google Groups would screw up?

I gave you the example (see above). Look carefully at the messages
of this thread at groups.google.com. The special, non-ASCII characters
are displayed correctly in my own messages. When other people write/quote
in 8bit, the special, non-ASCII characters may be screwed up by Google.

You will find many more examples in non-English newsgroups, such as
<news:de.etc.sprache.deutsch>
<http://groups.google.com/group/de.etc.sprache.deutsch/topics>
<https://groups.google.com/forum/?fromgroups#!forum/de.etc.sprache.deutsch>

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> [Historically, CTE was introduced so that Internet messages with
> [characters that required more than 8 bits to encode (so everything beyond
> US-ASCII)

Make that 7.

> could be transferred safely over channels that would only allow 7 bits
> (probably at first, from Europe to the US, whereas for the languages
> spoken in the former you need more than US-ASCII). The then zero-valued
> MSB of the octets would simply have been cut off without additional
> measures and loss of information. (Therefore, `Content-Transfer-Encoding:
> 8 Bit' can be omitted.)]

PointedEars
--

realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Adam H. Kerman]

Thomas 'PointedEars' Lahn <dci...@PointedEars.de> wrote:
>Adam H. Kerman wrote:
>>Andreas Prilop <prilo...@trashmail.net> wrote:
>>>On Tue, 20 Nov 2012, Adam H. Kerman wrote:

>>>>X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
>>>>>--=20
>>>>>Outgoing mail is certified free from defamation of Islam=99
>>>>>and insult of the Prophet=99.

>>>>I doubt that unconventional .sig delimiter shows up correctly anywhere.

>>>Using a newsreader that does not understand MIME (defined in 1993)
>>>is worse than using a web browser that does not understand CSS.

>>It understands that I want characters passed along to the terminal
>>emulation just fine, thanks for your concern.
>>I am displaying the codes of the characters which you so helpfully encoded
>>using quoted-printable over this very fine 8-bit clean medium of
> ^^^^^^^^^^^
>>communication,

>How can you know that for sure?

I can't believe someone would criticize my use of a newsreader of choice
under such circumstances in which he was forced to use 7-bit.

>>which I then quoted in followup. With a different setup, I'd be decoding
>>them.

>That said, the default character encoding for newer (at least five-year old
>and newer) Unices is UTF-8.

I'm not aware that the display in any recent Unix or linux can spot the
MIME headers for character set in use in the article.

>You must be using a really old (or configurationally aged) terminal
>emulation. Maybe you want to upgrade to the 21st century?

This particular terinal emulation wasn't written last century.

No, I simply tell the terminal emulation what the character set is and
it does what I want. It's really not the newsreader's job. I've had
discussions many times with programmers who work with character sets
about the issue of passing along the MIME headers to the terminal emulation
in some automated process who have convinced me that there are numerous
variables to consider, so for the moment, it's up to the user to tell
the terminal emulation what the character set is.

>>You used two different Latin 1 character sets.

>No, he used US-ASCII and Windows-1252; only the latter is what could be
>called a "Latin 1 character set" (it is a character _encoding_, not a
>character set).

I should have said, more precisely, that he used two different encodings
for the Latin-1 character set. I didn't followup to an article using ASCII.
One of the articles was marked ISO-8859-1.

>It is useful (more efficient) that a newsreader would fall back to the
>character encoding for the smallest character set necessary to transfer the
>message without garbling its content.

Oh, I agree with that. Others disagree, preferring to encourage more
widespread support of UTF-8.

>>Has that been your experience and is that why you're using it? Can you
>>give me an example of non-encoded text that Google Groups would screw up?

>That would be quite off-topic here. This thread has been drifting into
>off-topicness since quite a few postings ago.

I spotted what he was doing and wondered why he was doing it. I created
the thread drift. It's a Usenet feature. He still hasn't answered,
choosing instead to criticize my use of my choice of newsreader.

>>I'm giving you the benefit of a doubt that you're doing this with purpose.

>Andreas' reasons might be just historical, or due to his newsreader's
>limitations.

Can't be. He's surely using a newsreader without what he sees as my

newsreader's limitations.

>Certainly there is nothing wrong with using QP, or CTE in
>general, even these days.

>[Historically, CTE was introduced so that Internet messages with characters
>that required more than 8 bits to encode (so everything beyond US-ASCII)
>could be transferred safely over channels that would only allow 7 bits
>(probably at first, from Europe to the US, whereas for the languages spoken
>in the former you need more than US-ASCII). The then zero-valued MSB of the
>octets would simply have been cut off without additional measures and loss
>of information. (Therefore, `Content-Transfer-Encoding: 8 Bit' can be
>omitted.)]

It's my understanding that didn't apply to Usenet. After all, MIME wasn't
standardized for Usenet until somewhat recently. One inferred which
character set was in use by the language used in the newsgroup, but it
didn't always match.

I never saw QP in use till users started using certain newsreaders that
were also email clients that used default email settings when preparing
articles for Usenet.

[Adam H. Kerman]

Andreas Prilop <prilo...@trashmail.net> wrote:
>On Wed, 21 Nov 2012, Adam H. Kerman wrote:

>>I don't think newsreaders expect an encoded space character in a delimiter,

>They do; perhaps you should check one of the others/newer yourself.

I withdraw the comment.

>>><http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_thread/thread/21fedb43b2bf344/>
>>><https://groups.google.com/forum/?fromgroups=#!topic/comp.infosystems.www.authoring.html/Ah_ttDsr80Q>

>>Google Groups claims those two pages are in UTF-8.

>Google transcodes (rather: tries to transcode) to UTF-8.

Yes.

>Of course, it is Google's fault when failing to transcode and
>to display 8bit messages correctly.

Yes.

That doesn't address my initial question about why you're using
QP content transfer encoding.

>>One thing no one's ever said is that the things that Google screws up
>>don't get screwed up with the use of quoted-printable.
>>Has that been your experience and is that why you're using it? Can you
>>give me an example of non-encoded text that Google Groups would screw up?

>I gave you the example (see above). Look carefully at the messages
>of this thread at groups.google.com. The special, non-ASCII characters
>are displayed correctly in my own messages.

Yes, I saw that. Can you give me an example of one of your articles posted
to Usenet with MIME and with 8-bit characters and without QP that Google
Groups failed with?

[Thomas 'PointedEars' Lahn]

Adam H. Kerman wrote:

> Thomas 'PointedEars' Lahn <dci...@PointedEars.de> wrote:
>>Adam H. Kerman wrote:
>>>Andreas Prilop <prilo...@trashmail.net> wrote:
>>>>On Tue, 20 Nov 2012, Adam H. Kerman wrote:
>>>> Using a newsreader that does not understand MIME (defined in 1993)
>>>> is worse than using a web browser that does not understand CSS.
>>>
>>> It understands that I want characters passed along to the terminal
>>> emulation just fine, thanks for your concern.
>>> I am displaying the codes of the characters which you so helpfully
>>> encoded using quoted-printable over this very fine 8-bit clean medium of
>> ^^^^^^^^^^^
>>> communication,
>> How can you know that for sure?
>
> I can't believe someone would criticize my use of a newsreader of choice
> under such circumstances in which he was forced to use 7-bit.

Believe it or not, it is possible.

>>> which I then quoted in followup. With a different setup, I'd be decoding
>>> them.
>> That said, the default character encoding for newer (at least five-year
>> old and newer) Unices is UTF-8.
>
> I'm not aware that the display in any recent Unix or linux can spot the
> MIME headers for character set in use in the article.

You have said while your newsreader has MIME support, you are telling your
terminal emulation how it should display characters that cannot be found in
US-ASCII. If the result of that is your posting `=99' for a trade mark
character, something is very wrong with your terminal emulation or with you.

>> You must be using a really old (or configurationally aged) terminal
>> emulation. Maybe you want to upgrade to the 21st century?
>
> This particular terinal emulation wasn't written last century.
>
> No, I simply tell the terminal emulation what the character set is

What the character _encoding_ is.

> and it does what I want.

So you are deliberately misconfiguring your terminal emulation so that it
would not display characters properly?

> It's really not the newsreader's job.

Indeed, in the end it is *your* job to post readable content.

>>> You used two different Latin 1 character sets.
>>
>> No, he used US-ASCII and Windows-1252; only the latter is what could be
>> called a "Latin 1 character set" (it is a character _encoding_, not a
>> character set).
>
> I should have said, more precisely, that he used two different encodings
> for the Latin-1 character set.

He did not.

> I didn't followup to an article using ASCII. One of the articles was
> marked ISO-8859-1.

(US-)ASCII is _not_ an encoding for the Latin-1 character set.

>>> Has that been your experience and is that why you're using it? Can you
>>> give me an example of non-encoded text that Google Groups would screw
>>> up?
>> That would be quite off-topic here. This thread has been drifting into
>> off-topicness since quite a few postings ago.
>
> I spotted what he was doing and wondered why he was doing it. I created
> the thread drift. It's a Usenet feature. He still hasn't answered,
> choosing instead to criticize my use of my choice of newsreader.

Because it is irrelevant and off-topic. Send him an e-mail, or X-Post &
F'up2 where it is on-topic. That also is a feature of Usenet/NetNews.

>>> I'm giving you the benefit of a doubt that you're doing this with
>>> purpose.
>> Andreas' reasons might be just historical, or due to his newsreader's
>> limitations.
>
> Can't be. He's surely using a newsreader without what he sees as my
> newsreader's limitations.

I do not know his Pine well enough to confirm or deny that, and I do not
care to check.

>>Certainly there is nothing wrong with using QP, or CTE in
>>general, even these days.
>
>>[Historically, CTE was introduced so that Internet messages with
>>[characters
>>that required more than 8 bits to encode (so everything beyond US-ASCII)
>>could be transferred safely over channels that would only allow 7 bits
>>(probably at first, from Europe to the US, whereas for the languages
>>spoken
>>in the former you need more than US-ASCII). The then zero-valued MSB of
>>the octets would simply have been cut off without additional measures and
>>loss
>>of information. (Therefore, `Content-Transfer-Encoding: 8 Bit' can be
>>omitted.)]

Your newsreader is borken with regard to quoting as well. Please fix it or
change it.

> It's my understanding that didn't apply to Usenet. After all, MIME wasn't
> standardized for Usenet until somewhat recently.

It was not standardized at all yet; we have only a *Proposed* Standard
(RFC 5536) at this point. However, Network News messages have been Internet
messages (that is, based on RFC 5322 and predecessors) for more than two
decades now (RFC 1036, Son-of-RFC-1036), and MIME has been specified (for
use in Internet messages) in 1996 CE (RFCs 2045 to 2049). So people have
been using MIME in their Usenet postings since then.


F'up2 poster

[David Stone]

In article <timstreater-72D7...@news.individual.net>,

Tim Streater <timst...@greenbee.net> wrote:

> In article <nlsrn9-...@cfa.johnson>,

> "Chris F.A. Johnson" <cfajo...@gmail.com> wrote:
>

> > On 2012-11-20, Jukka K. Korpela wrote:
> > ...
> > > First-line indents were not commonly used in typewriting. Typewriting is
> > > one of the things that gave us ?technical paragraphs?, i.e. the
> > > presentation style where paragraphs are separated by empty lines (with
> > > no first-line indents).
> >
> > Both indents and empty lines were common in typewriting.
>

> And plenty of people still seems to treat Word and the like as glorified
> typewriters. They also press the return key a number of times at the end
> of any doc - perhaps they hope that paper will scroll out of the top of
> the display.

Don't forget using the space bar to line up columns of tabular data...

Then again, if you're feeling in a mischievous mood, there's always this:
http://www.xkcd.com/1137/

[Adam H. Kerman]

It recognizes boundaries, yes, and I'd be able to send attachments to other
applications if I really wanted to set that up. Totally irrelevant
for what you are discussing about the terminal emulation.

>you are telling your terminal emulation how it should display characters
>that cannot be found in US-ASCII. If the result of that is your posting
>`=99' for a trade mark character, something is very wrong with your
>terminal emulation or with you.

It should have been clear from the start that I deliberately quoted the
code, given that I asked about QP.

What's very wrong with me is that I've been following up to troll bait,
so I'm spitting out the hook now.

Amazingly, the question I asked was never answered.

[John W Kennedy]

On 2012-11-19 01:24:04 +0000, dorayme said:

> In article <s3via8ldhlv62nnnt...@4ax.com>,
> Joy Beeson <jbe...@invalid.net.invalid> wrote:
>
>> What brought on the current fad for pale-grey letters on sorta-white?
>
> This question has been asked many times. It has no particularly good
> answer.

Probably the same people who decreed that home sound systems should
have black letters on a black background. I'm on my second generation
of that.

--
John W Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
...you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"

[dorayme]

In article <50b19d55$0$24781$607e...@cv.net>,

John W Kennedy <jwk...@attglobal.net> wrote:

> On 2012-11-19 01:24:04 +0000, dorayme said:
>
> > In article <s3via8ldhlv62nnnt...@4ax.com>,
> > Joy Beeson <jbe...@invalid.net.invalid> wrote:
> >
> >> What brought on the current fad for pale-grey letters on sorta-white?
> >
> > This question has been asked many times. It has no particularly good
> > answer.
>
> Probably the same people who decreed that home sound systems should
> have black letters on a black background. I'm on my second generation
> of that.

It is also done on certain kitchen stoves (cookers, the buttons being
indicated by blackish dots on blackish glass top). The top of a camera
I have has a very polished silver bg and very clearly marked symbols
in black but... of no use outdoors when the sun is shining or the
light is on and needed to read them because the glare from the
reflection kills the exercise. <g>

--
dorayme

[David Stone]

In article <50b19d55$0$24781$607e...@cv.net>,
John W Kennedy <jwk...@attglobal.net> wrote:

> On 2012-11-19 01:24:04 +0000, dorayme said:
>
> > In article <s3via8ldhlv62nnnt...@4ax.com>,
> > Joy Beeson <jbe...@invalid.net.invalid> wrote:
> >
> >> What brought on the current fad for pale-grey letters on sorta-white?
> >
> > This question has been asked many times. It has no particularly good
> > answer.
>
> Probably the same people who decreed that home sound systems should
> have black letters on a black background. I'm on my second generation
> of that.

I have occasionally to deal with a large screen Samsung TV, which has
black buttons with either no or black labels (difficult to tell,
really), on a black background.

The only thing missing is the black light that lights up blackly when
you finally manage to hit the power button.

Well, that and a functioning emergency escape teleport device...

[Andreas Prilop]

On Wed, 21 Nov 2012, Adam H. Kerman wrote:

> Can you give me an example of one of your articles

No, I post in Quoted-Printable.

> posted to Usenet with MIME and with 8-bit characters
> and without QP that Google Groups failed with?

<news:ah1rng...@mid.individual.net>
<news:50addef6$0$6584$9b4e...@newsspool3.arcor-online.net>
<news:20121117193610...@mid.crommatograph.info>
<news:agpmfs...@mid.individual.net>

[Adam H. Kerman]

Andreas Prilop <prilo...@trashmail.net> wrote:
>On Wed, 21 Nov 2012, Adam H. Kerman wrote:

>>Can you give me an example of one of your articles

>No, I post in Quoted-Printable.

>>posted to Usenet with MIME and with 8-bit characters
>>and without QP that Google Groups failed with?

><news:ah1rng...@mid.individual.net>
><news:50addef6$0$6584$9b4e...@newsspool3.arcor-online.net>
><news:20121117193610...@mid.crommatograph.info>
><news:agpmfs...@mid.individual.net>

Well, new Google Groups is helpfully failing to parse your URLs as
News and presenting them as mailto instead. The news URL and plain
old Message-ID can't be searched for in the new Google Groups search
box as a Message-ID, and the Message ID lookup in old Google Groups
advanced search is broken again (because the day ends in "y").

Your point that you're attempting to accomodate failures of Google Groups
isn't made. I'll try again another time if I'm in the mood to.

btw, looking at each of these articles with the Howard Knight article
lookup tool presents no rendering errors at all in my Web browser.

[Andreas Prilop]

On Fri, 30 Nov 2012, Adam H. Kerman wrote:

>> <news:ah1rng...@mid.individual.net>
>> <news:50addef6$0$6584$9b4e...@newsspool3.arcor-online.net>
>> <news:20121117193610...@mid.crommatograph.info>
>> <news:agpmfs...@mid.individual.net>
>

> looking at each of these articles with the Howard Knight
> article lookup tool

You have "Newsgroups:",
you have "Subject:",
you have "From:",
you have "Date:".

It should be easy to find the articles in groups.google.com.

If you cannot, here is a direct link to another article:
http://groups.google.com/group/sfnet.huuhaa/msg/51fe0f85eb169aaa
http://groups.google.com/group/sfnet.huuhaa/msg/51fe0f85eb169aaa?dmode=source

> presents no rendering errors at all in my Web browser.

The articles have no error; the error is with groups.google.com.