Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

3 views
Skip to first unread message

Ivan Shmakov

unread,
Mar 24, 2013, 4:59:49 AM3/24/13
to
>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:

[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.

--
FSF associate member #7257

Ivan Shmakov

unread,
Mar 27, 2013, 4:44:12 AM3/27/13
to
>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:
>>>>> On 03/24/2013 01:59 AM, Ivan Shmakov wrote:
>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:

>> [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.

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

[...]

>>> 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.)

>> 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.)

Rob Kelk

unread,
Mar 27, 2013, 9:29:57 AM3/27/13
to
On Sun, 24 Mar 2013 08:59:49 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:

>>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:
>
> [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:

<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, co-moderator, rec.arts.anime.info
Personal address, in ROT-13: eboxryx -ng- tznvy -qbg- pbz

Rob Kelk

unread,
Mar 27, 2013, 9:31:17 AM3/27/13
to
On Wed, 27 Mar 2013 13:29:57 GMT, rob...@deadspam.com (Rob Kelk) wrote:

>On Sun, 24 Mar 2013 08:59:49 +0000, Ivan Shmakov <onei...@gmail.com>
>wrote:
>
>>>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:
>>
>> [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:
>
><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

unread,
Mar 27, 2013, 9:59:56 AM3/27/13
to
>>>>> Rob Kelk <rob...@deadspam.com> writes:
>>>>> On Sun, 24 Mar 2013 08:59:49 +0000, Ivan Shmakov wrote:
>>>>> Bobbie Sellers <bliss-...@dslextreme.com> writes:

[...]

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

[...]

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

> 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.)

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

--
FSF associate member #7257

Stainless Steel Rat

unread,
Mar 27, 2013, 11:15:26 AM3/27/13
to
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.

--
\m/ (--) \m/

Ivan Shmakov

unread,
Mar 27, 2013, 11:47:45 AM3/27/13
to
>>>>> Stainless Steel Rat <rat...@gweep.net> writes:

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

Rob Kelk

unread,
Mar 27, 2013, 12:58:48 PM3/27/13
to
On Wed, 27 Mar 2013 13:59:56 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:

<snip>

> 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>
--
Rob Kelk <http://robkelk.ottawa-anime.org/> e-mail: s/deadspam/gmail/
"I'm *not* a kid! Nyyyeaaah!" - Skuld (in "Oh My Goddess!" OAV #3)
"When I became a man, I put away childish things, including the fear
of childishness and the desire to be very grown-up." - C.S. Lewis

Stainless Steel Rat

unread,
Mar 27, 2013, 4:52:51 PM3/27/13
to
On Wed, 27 Mar 2013 15:47:45 +0000, Ivan Shmakov wrote:

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

--
\m/ (--) \m/

Ivan Shmakov

unread,
Mar 28, 2013, 5:46:10 AM3/28/13
to
>>>>> Stainless Steel Rat <rat...@gweep.net> writes:
>>>>> On Wed, 27 Mar 2013 15:47:45 +0000, Ivan Shmakov wrote:

[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

unread,
Mar 28, 2013, 5:57:22 AM3/28/13
to
>>>>> Stainless Steel Rat <rat...@gweep.net> writes:
>>>>> On Wed, 27 Mar 2013 15:47:45 +0000, Ivan Shmakov wrote:

[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.

>> 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?
0 new messages