[OT] forwards from right-stuf-press at lists.rightstuf.com

[Ivan Shmakov]

[Cross-posting to news:news.misc.]

Subject: Fwd: NEWS RELEASE: Nozomi Ent. Announces Value-Priced Re-Release
of THE IRRESPONSIBLE CAPTAIN TYLOR TV Series on DVD for July 2013

Given that the newsreaders currently in use usually truncate the
Subject: while presenting a list of messages to the reader,
could this please be re-formatted to mention the most important
thing first? Like:

Subject: Fwd: THE IRRESPONSIBLE CAPTAIN TYLOR, Nozomi Ent. Announces
Value-Priced Re-Release of the TV Series on DVD for July 2013
(NEWS RELEASE)

I understand that it may prove to be unfeasible to perform this
re-formatting while forwarding messages. If that's the case,
could this request please be forwarded to the rightstuf.com's
list maintainers, so that the issue could be fixed "up-feed"?

RIGHT STUF\303\242\302\200\302\231S NOZOMI ENTERTAINMENT Announces

This line looks exactly like it was transcoded from proper UTF-8
to UTF-8, /as if/ the source was ISO-8859-1 (which it's not.)
Could this please be fixed?

TIA.

[Ivan Shmakov]

Post by Ivan Shmakov
[Cross-posting to news:news.misc.]

I hope that will do you some good.

? It surely doesn't hurt to keep all such discussions available
from a single place.

Post by Ivan Shmakov

Subject: Fwd: NEWS RELEASE: Nozomi Ent. Announces Value-Priced Re-Release
of THE IRRESPONSIBLE CAPTAIN TYLOR TV Series on DVD for July 2013

Given that the newsreaders currently in use usually truncate the
Subject: while presenting a list of messages to the reader, could
this please be re-formatted to mention the most important thing
first?

Move to a better news reader.
Thunderbird does not truncate the subject lines.

... They say that these days, one has no chance of arguing one's
point, until and unless he or she posts an image explaining it
somewhere on the Web. So here it is, the image, showing where
Thunderbird /does/ truncate Subject:'s:

http://efye.am-1.org/~ivan/doc-files/jd1kn7jicjt1qfqu4s7mjempaf.svg

[...]

Post by Ivan Shmakov

RIGHT STUF\303\242\302\200\302\231S NOZOMI ENTERTAINMENT Announces

This line looks exactly like it was transcoded from proper UTF-8 to
UTF-8, /as if/ the source was ISO-8859-1 (which it's not.)

(Naturally, it should read "RIGHT STUF'S", where ' is U+2019,
RIGHT SINGLE QUOTATION MARK.)

Post by Ivan Shmakov
Could this please be fixed?

The image above also shows where the forwards have the encoding
screwed up.

I sincerely hope that these issues could be rectified in the
foreseeable future. (I'm mostly concerned over the latter,
though.)

TIA.

[Rob Kelk]

Post by Ivan Shmakov
[Cross-posting to news:news.misc.]

Subject: Fwd: NEWS RELEASE: Nozomi Ent. Announces Value-Priced Re-Release
of THE IRRESPONSIBLE CAPTAIN TYLOR TV Series on DVD for July 2013

Given that the newsreaders currently in use usually truncate the
Subject: while presenting a list of messages to the reader,
could this please be re-formatted to mention the most important

<snip>

Posts to rec.arts.anime.info are approved based on content, not on form.

We get few enough submissions as it is - we're not going to throw any
away because the submitter used the wrong encoding, as long as the
encoding allows the text to be read.

If this displeases you, then submit enough on-topic, well-formed posts
to rec.arts.anime.misc that we have the option to reject based on form.

[Rob Kelk]

Post by Rob Kelk

Post by Ivan Shmakov
[Cross-posting to news:news.misc.]

Subject: Fwd: NEWS RELEASE: Nozomi Ent. Announces Value-Priced Re-Release
of THE IRRESPONSIBLE CAPTAIN TYLOR TV Series on DVD for July 2013

Given that the newsreaders currently in use usually truncate the
Subject: while presenting a list of messages to the reader,
could this please be re-formatted to mention the most important

<snip>
Posts to rec.arts.anime.info are approved based on content, not on form.
We get few enough submissions as it is - we're not going to throw any
away because the submitter used the wrong encoding, as long as the
encoding allows the text to be read.
If this displeases you, then submit enough on-topic, well-formed posts
to rec.arts.anime.misc that we have the option to reject based on form.

Sorry, that should be r.a.a.info, not r.a.a.misc

[Ivan Shmakov]

[...]

Post by Rob Kelk

Post by Ivan Shmakov

Subject: Fwd: NEWS RELEASE: Nozomi Ent. Announces Value-Priced
Re-Release of THE IRRESPONSIBLE CAPTAIN TYLOR TV Series on DVD for
July 2013

Given that the newsreaders currently in use usually truncate the
Subject: while presenting a list of messages to the reader, could
this please be re-formatted to mention the most important thing
first?

[...]

Post by Rob Kelk
Posts to rec.arts.anime.info are approved based on content, not on form.

FWIW, the "Subject:" issue quoted above was merely a suggestion,
not an attempt to, say, take over the moderation.

Post by Rob Kelk
We get few enough submissions as it is - we're not going to throw any
away because the submitter used the wrong encoding, as long as the
encoding allows the text to be read.

Now that I'm reminded that the newsgroup in question is indeed
moderated, it makes me wonder if it's the moderator's software
that screws up the encoding? Not that I'm familiar with the
approval process itself, but I readily note that the message I'm
replying to lacks the Content-Type: header, which typically
signifies the newsreader's lack of support for multiple
encodings.

(A test forward to an unmoderated newsgroup, such as, e. g.,
news:alt.testing, may help to troubleshoot this issue further.)

Post by Rob Kelk
If this displeases you, then submit enough on-topic, well-formed
posts to rec.arts.anime.misc that we have the option to reject based
on form.

[Stainless Steel Rat]

Ivan,

Your first problem is that you're using Gnus. This is not a problem in and
of itself but it means that you're using GNU Emacs. This *is* a problem.
GNU Emacs' multi-byte character handling (MULE) is atrocious. It's broken,
it's stupid, it will corrupt messages, and it can't be turned off. The
only person in the world who can fix it is RMS and he adamantly refuses to
acknowledge that it is a problem.

Your second problem is actually your own problem. Not the groups, not the
moderators, and not RightStuf's. Okay, maybe RightStuf's since the
postings are copied verbatim from their mailings. If you don't like that
the client you're using doesn't have a wide enough Subject column in the
summary list then make the column wider. Or use a client that lets you do
that. Simple.

Heck, you're using Gnus. Write a hook that collapses Subject fields the
way you like.

[Ivan Shmakov]

Ivan, Your first problem is that you're using Gnus. This is not a
problem in and of itself but it means that you're using GNU Emacs.
This *is* a problem. GNU Emacs' multi-byte character handling (MULE)
is atrocious. It's broken, it's stupid, it will corrupt messages,
and it can't be turned off. The only person in the world who can fix
it is RMS and he adamantly refuses to acknowledge that it is a
problem.

First of all, I've never experienced an encoding-related issue
with Emacs ever since I've switched to Emacs 23. (Or was it
Emacs 22? Other than a few spurious crashes, that is.)
However, cross-posting to news:comp.emacs, should I indeed be
mistaken regarding the state of Unicode support in GNU Emacs.

Second, the issue manifests itself with Thunderbird (as I've
already mentioned), /and/ with Google Groups (as I do now.)
Consider, for instance:

http://groups.google.com/group/rec.arts.anime.info/msg/278594a283bf56ff

(Look for the apostrophes; e. g., in "Right Stuf's".)

Third, I /can/ decode UTF-8 from a hexdump. Please be sure that
I /did/ the relevant checks before "accusing" the other party of
making "wrongly-encoded" postings.

Your second problem is actually your own problem. Not the groups,
not the moderators, and not RightStuf's. Okay, maybe RightStuf's
since the postings are copied verbatim from their mailings. If you
don't like that the client you're using doesn't have a wide enough
Subject column in the summary list then make the column wider.

Whatever is the width of the single-line field, there's a way to
exceed it. (Unless it's Twitter, that is.) That's why the rule
of the thumb is to try to order the information from the most
important to the least: whether it's netnews or email Subject:,
HTML's <title />, or something else. (Yes, there're still Web
fora which format titles as: "Our new very kewl forum + The Foo
topic + The Bar thread." Instead of doing it in the reverse.)

I surely don't want to argue on this (minor) point any further.
It's an issue of good taste, and as such, it has no RFCs for one
to violate. (While for the encodings, there are.)

Or use a client that lets you do that. Simple.
Heck, you're using Gnus. Write a hook that collapses Subject fields
the way you like.

Indeed, that may be a sensible solution.

[Stainless Steel Rat]

First of all, I've never experienced an encoding-related issue with
Emacs ever since I've switched to Emacs 23. (Or was it Emacs 22?
Other than a few spurious crashes, that is.) However, cross-

Then you've been fortunate. An Emacs buffer can have only one file coding
system at a time. If the wrong coding system is selected, or a file
contains multi-byte characters from two or more different coding systems,
then the buffer contents are corrupted.

RightStuf sends out announcements as HTML-encoded UTF-8. Usenet does not
officially acknowledge UTF-8 encodings. The multi-byte munging could
happen at any NNTP server along the path between poster and Google or
whatever NNTP servers you use.

Whatever is the width of the single-line field, there's a way to exceed
it. (Unless it's Twitter, that is.) That's why the rule of the thumb

RFC 1036 (Usenet message format) inherits from RFC 822 (Internet mail
message format). RFC 822 explicitly does not impose limits on header field
lengths. RFC 822 discourages field folding in section 3.4.8. There is no
limit to exceed beyond the cosmetic capabilities of your Usenet client.

[Ivan Shmakov]

[Setting Followup-To: news:comp.emacs, for the encoding support
in Emacs is irrelevant to either anime or netnews.]

First of all, I've never experienced an encoding-related issue with
Emacs ever since I've switched to Emacs 23. (Or was it Emacs 22?
Other than a few spurious crashes, that is.) However, cross-posting
to news:comp.emacs, should I indeed be mistaken regarding the state
of Unicode support in GNU Emacs.

Then you've been fortunate. An Emacs buffer can have only one file
coding system at a time.

Frankly, I can't readily recall of /any/ text editor that would
allow for multiple encodings for a single file. Could you
please name one?

If the wrong coding system is selected, or a file contains multi-byte
characters from two or more different coding systems, then the buffer
contents are corrupted.

As with virtually all the other editors I ever encountered.

Still, it's possible to read a file using the "raw" encoding,
and decode it explicitly later, either as a whole, or
piece-wise, with M-x decode-coding-region.

[...]

PS. Kvankam mi estas laca pro tio diskuto.

[Ivan Shmakov]

[Dropping news:comp.emacs from Followup-To:.]

[...]

RightStuf sends out announcements as HTML-encoded UTF-8. Usenet does
not officially acknowledge UTF-8 encodings.

That would seem to suggest that such forwards "violate" the
established Usenet conventions, wouldn't it?

The multi-byte munging could happen at any NNTP server along the path
between poster and Google or whatever NNTP servers you use.

These days, I tend to assume that Usenet transports are
"8-bit clean." Moreover, section 3.6 of RFC 5537 explicitly
prohibits such munging:

--cut: urn:ietf:rfc:5537 --
Relaying agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT
modify the body of articles in any way. If an article is not
acceptable as is, the article MUST be rejected rather than modified.
--cut: urn:ietf:rfc:5537 --

(But feel free to provide any examples to prove me mistaken on
that.)

Alternatively, I'd suggest to use the quoted-printable encoding
for the forwards. (Now that I know that the messages are
rendered into plain text from HTML, such re-encoding doesn't
seem all that infeasible, and perhaps only a checkbox away for a
Thunderbird user.)

Or perhaps it may make sense to ASCII-fy the forwards
altogether.

Post by Ivan Shmakov
Whatever is the width of the single-line field, there's a way to
exceed it. (Unless it's Twitter, that is.)

[...]

There is no limit to
exceed beyond the
cosmetic capabilities
of your Usenet
client.

Yes. And you
aren't going to
read netnews
without one, are
you?

[Rob Kelk]

On Wed, 27 Mar 2013 13:59:56 +0000, Ivan Shmakov <***@gmail.com>
wrote:

<snip>

Post by Ivan Shmakov
Now that I'm reminded that the newsgroup in question is indeed
moderated, it makes me wonder if it's the moderator's software
that screws up the encoding?

I;m reasonably sure that the software written by Herr Bartolich (may he
rest in peace) is not the source of the issue.

<snip>