Mailing/posting programs containing "="
John H Meyers
I have noticed that when I view newsgroup postings
of my short programs containing equal signs, e.g. X == Y,
then even in the archived "original format" post at Google,
each "=" character has been replaced by "=3D",
e.g. the above text now says: X =3D=3D Y
Needless to say, anyone trying to copy and use the posted programs
subsequently reports that they do not work!
The same thing is seen if you view my post in Opera,
using "View all headers and message," even though
my post is in pure ascii plain text,
and ISO-8859-1 (the selected character set for my account)
includes the ascii-defined "=" character.
Yes, an ascii "equals" symbol has the hex value 0x3D,
but I can see no more reason to convert that unique character
to a hexadecimal "exploded" value
than to convert every period to the exploded value
"=2E" just because its hex value happens to be 0x2E.
Why are my "equals" signs (and *only* my "equals" signs)
being everywhere converted to "exploded" hexadecimal values?
Thanks for any help.
-[ ]-
John H Meyers
"outgoing default encoding" to "us-ascii"
in my M2 news account configuration.
One "equals" sign is =
Two consecutive "equals" signs are ==
[End]
John H Meyers
[having posted again with "default character set" changed to "us-ascii"]
> One "equals" sign is =3D
>
> Two consecutive "equals" signs are =3D=3D
The above is what I got from viewing my previous post
with "View all headers and message" ticked,
and just those lines selected before clicking "Reply"
There is no such "exploding" of "equals" signs
in the "Subject" header line, however!
Still puzzled...
-[ ]-
Rijk van Geijtenbeek
<jhme...@nomail.invalid>:
Search for 'Quoted-Printable' and you will be enlightened :)
--
Rijk
Opera Software ASA
QA etc
Whiskers
> Using 9.02.8585 (Win32):
>
> I have noticed that when I view newsgroup postings
> of my short programs containing equal signs, e.g. X == Y,
> then even in the archived "original format" post at Google,
> each "=" character has been replaced by "=3D",
> e.g. the above text now says: X =3D=3D Y
What I see is what you you intended, ie two equals signs in succession.
> Needless to say, anyone trying to copy and use the posted programs
> subsequently reports that they do not work!
I can remember this phenomenon having arisen before, in a non-Opera
group. Just something else that Google manage to get wrong with usenet.
> The same thing is seen if you view my post in Opera,
> using "View all headers and message," even though
> my post is in pure ascii plain text,
> and ISO-8859-1 (the selected character set for my account)
> includes the ascii-defined "=" character.
That's disappointing.
> Yes, an ascii "equals" symbol has the hex value 0x3D,
> but I can see no more reason to convert that unique character
> to a hexadecimal "exploded" value
> than to convert every period to the exploded value
> "=2E" just because its hex value happens to be 0x2E.
>
> Why are my "equals" signs (and *only* my "equals" signs)
> being everywhere converted to "exploded" hexadecimal values?
>
> Thanks for any help.
>
> -[ ]-
I suppose it comes from trying to use HTML to display something (eg
usenet) that has no business getting anywhere near HTML.
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Ivan Magerle
Hmm, everything is working here. ;)
--
M4gi
David W. Hodgins
> I have noticed that when I view newsgroup postings
> of my short programs containing equal signs, e.g. X == Y,
> then even in the archived "original format" post at Google,
> each "=" character has been replaced by "=3D",
> e.g. the above text now says: X =3D=3D Y
In google, instead of using the "show original" like
http://groups.google.com/group/opera.mail+news/msg/27034a5790317d9b?dmode=source
use the "view parsed" like
http://groups.google.com/group/opera.mail+news/msg/27034a5790317d9b?
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
John H Meyers
> In google, instead of using the "show original"
> use the "view parsed"
"View parsed" inserts undesired line breaks
and leading spaces (also may split up a large post),
interprets links, sometimes overlaps ads with text, etc.,
and thus is frequently unusable,
which is why I rely on "show original" for faithful reproduction
(but in this case it also fails).
Nice of Rijk to say:
"Search for 'Quoted-Printable' and you will be enlightened :)"
but that doesn't quite tell me what to specify to fix it
(Eudora has an option, though of course it isn't for newsgroups,
but there is no related option in any of the "account properties"
of my news posting account in M2, for example, certainly not
in the [Outgoing] "default encoding" or anywhere else, so what next?)
Can Opera M2 straighten this out, or not?
How about attempting to insert <pre> before == </pre> ... wluk.
-[ ]-
John H Meyers
these are in my outgoing headers made by M2:
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: Quoted-Printable
What M2 labels in Account properties [of news account]
as the Outgoing "Default *encoding*"
(and also in the composition window as View > "Encoding")
is really the "charset."
Searching opera:config for "encod" is also not enlightening me.
What actually sets the Content-Transfer-*ENCODING* ?
-[ ]-
Whiskers
Opera can (we can hope) straighten out the way M2 displays
correctly-composed plain text newsgroup articles. Perhaps Google can do
the same for their interface. Nothing anyone can do at the 'sending'
stage can force either M2 or G2 to use 'plain text' to display 'plain
text' in their not-plain-at-all displays.
I seem to recall that M2 has a 'view source' option for newsgroup
articles, which actually does display in plain text without any 'parsing'
or other treatment. G2's 'show original' option doesn't show the original
at all; it shows their 'parsed' version, parsed-again-to-look-ugly in a
fixed-width font and with all the headers intact (apart from their usual
lame attempt at munging the email addresses).
John H Meyers
> I seem to recall that M2 has a 'view source' option for newsgroup
> articles, which actually does display in plain text without any 'parsing'
> or other treatment.
Try "view source" with 9.02 -- nothing useful, not even the article itself.
> G[oogle]'s 'show original' option doesn't show the original
> at all; it shows their 'parsed' version, parsed-again-to-look-ugly
> in a fixed-width font and with all the headers intact (apart from their usual
> lame attempt at munging the email addresses).
Except for the "equals" signs, it would be exactly what I sent.
By the way, there are now links on Google groups by means of which
you can view any complete email addresses within postings.
I gather that there is no way to persuade M2 not to declare
"Content-Transfer-Encoding: Quoted-Printable"
-[ ]-
Whiskers
> On Thu, 12 Oct 2006 17:10:36 -0500, Whiskers wrote:
>
>> I seem to recall that M2 has a 'view source' option for newsgroup
>> articles, which actually does display in plain text without any 'parsing'
>> or other treatment.
>
> Try "view source" with 9.02 -- nothing useful, not even the article itself.
>
>> G[oogle]'s 'show original' option doesn't show the original
>> at all; it shows their 'parsed' version, parsed-again-to-look-ugly
>> in a fixed-width font and with all the headers intact (apart from their usual
>> lame attempt at munging the email addresses).
>
> Except for the "equals" signs, it would be exactly what I sent.
>
> By the way, there are now links on Google groups by means of which
> you can view any complete email addresses within postings.
That's been possible ever since the new interface started to muck them up.
> I gather that there is no way to persuade M2 not to declare
> "Content-Transfer-Encoding: Quoted-Printable"
>
> -[ ]-
That isn't good.
John H Meyers
One "equals": =
Two "Equals": ==
Does this post have a header:
"Content-Transfer-Encoding: 7bit"
Next I'll see what Google thinks of it...
John H Meyers
sending it to the same place as go emailed copies of all my posts,
it arrives in my other email reader with this header:
Content-Transfer-Encoding: 7bit
But when I send it also to a newsgroup,
the copy I receive in *email*
does *not* have any "Content-Transfer-Encoding" header!
When the posted version is read back by M2
and displayed with "View all headers and message,"
now it says:
Content-Transfer-Encoding: Quoted-Printable
Likewise, at
http://groups.google.com/group/opera.mail+news/msg/8bd24d24e473a06e?dmode=source&output=gplain
it also says:
Content-Transfer-Encoding: Quoted-Printable
[and is mangled as "=3D=3D"]
Where did this change occur, from the "7-bit" encoding sent in ordinary mail
to the "Quoted-Printable" found in the re-read message from the news server
(as interpreted by M2,) and the Google copy as well?
Is there any way that M2 could help fix this by sending a
"Content-Transfer-Encoding" header on the outgoing message and post?
[why did M2 *not* send that header, even in a directly emailed copy,
when a composed message was also posted, although I get that header
whenever a composed message is *not* also posted to a newsgroup?]
Thanks for any further enlightenment.
-[ ]-
Whiskers
> Path: uni-berlin.de!individual.net!not-for-mail
> Message-ID: <op.thkfl...@w2kjhm.ia.mum.edu>
> From: "John H Meyers" <jhme...@nomail.invalid>
> Newsgroups: opera.mail+news
> Subject: Re: Mailing/posting programs containing "="
> Date: Tue, 17 Oct 2006 07:28:43 -0500
> References: <op.thaks...@w2kjhm.ia.mum.edu> <op.thbrxrw...@hodgins.homeip.net> <op.thbty...@w2kjhm.ia.mum.edu> <s3r204-...@ID-107770.user.individual.net>
> Lines: 11
> Organization: (real domain is miu.edu)
> Mime-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: Quoted-Printable
> User-Agent: Opera Mail/9.02 (Win32)
> Xref: ID-107770.user.individual.net opera.mail+news:4099
>
> Here are some more "equals" signs:
>
> One "equals": =
That's what I can see.
> Two "Equals": ==
I can see two, next to each other.
> Does this post have a header:
>
> "Content-Transfer-Encoding: 7bit"
No; see above, where I've quoted all the headers I can see.
> Next I'll see what Google thinks of it...
The 'old' version of Google's new interface (G2) looks like this, to me
(the "view in Groups Beta New!" version is very similar) - the equals
signs are exactly as I see them in my own news-reader:
---------------xxxxxxxxxxxxxxxxxxxxx------------------
From: John H Meyers - view profile
Date: Tues, Oct 17 2006 8:28 am
Email: "John H Meyers" <jhmey...@nomail.invalid>
Groups: opera.mail+news
Not yet rated
Reply | Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse | Find messages by this author
Reply
---------------xxxxxxxxxxxxxxxxxxxxx------------------
Whereas what Google displays for "Show original" is mangled:
---------------xxxxxxxxxxxxxxxxxxxxx------------------
Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "John H Meyers" <jhmey...@nomail.invalid>
Newsgroups: opera.mail+news
Subject: Re: Mailing/posting programs containing "="
Date: Tue, 17 Oct 2006 07:28:43 -0500
Organization: (real domain is miu.edu)
Lines: 11
Message-ID: <op.thkfl...@w2kjhm.ia.mum.edu>
References: <op.thaks...@w2kjhm.ia.mum.edu> <op.thbrxrw...@hodgins.homeip.net> <op.thbty...@w2kjhm.ia.mum.edu> <s3r204-...@ID-107770.user.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: Quoted-Printable
X-Trace: individual.net tdqjFvPyQi14fOV0Y0ksIQ9RavwKxOJCfsa6CQWQ+i07CwJBus
User-Agent: Opera Mail/9.02 (Win32)
Here are some more "equals" signs:
One "equals": =3D
Two "Equals": =3D=3D
Does this post have a header:
"Content-Transfer-Encoding: 7bit"
Next I'll see what Google thinks of it...
---------------xxxxxxxxxxxxxxxxxxxxx------------------
Of course, anyone looking at this article (the one I'm typing now) using
Google, will see the same errors as Google introduced into their
renditions of the article I'm responding to. I don't know what Opera's M2
will make of it.
Whiskers
snip
> Where did this change occur, from the "7-bit" encoding sent in ordinary mail
> to the "Quoted-Printable" found in the re-read message from the news server
> (as interpreted by M2,) and the Google copy as well?
>
> Is there any way that M2 could help fix this by sending a
> "Content-Transfer-Encoding" header on the outgoing message and post?
> [why did M2 *not* send that header, even in a directly emailed copy,
> when a composed message was also posted, although I get that header
> whenever a composed message is *not* also posted to a newsgroup?]
>
> Thanks for any further enlightenment.
>
> -[ ]-
Clearly, Opera is treating newsgroup articles differently from emails. So
far, so good; the two things /are/ different - but Opera doesn't seem to
know quite what the differences really are. (Google get it even more
wrong).
The nearest thing there is to an official "Standard for Interchange of
USENET Messages" is set out in RFC 1036 (dated 1987) which can be found in
various places on the internet, eg
<http://www.w3.org/Protocols/rfc1036/rfc1036.html>. This 'standard' sets
out two categories of 'header' for newsgroup articles: "Required" and
"Optional".
The "Required" headers are:
From
Date
Newsgroups
Subject
Message-ID
Path
The "Optional" headers mentioned are:
Reply-To
Sender
Followup-To
Expires
References
Control
Distribution
Organization
Keywords
Summary
Approved
Lines
Xref
The more recent RFC 2980 (dated 2000) adds these further optional headers:
NNTP-Posting-Host
X-Newsreader and others
Any headers not specified there, are likely to be ignored, as they have no
official meaning or purpose. Usenet is a 'plain text ASCII' beast, ie '7
bit' characters only and no HTML. Some newsreaders can recognise and act
upon certain other headers, such as a specified character set or encoding,
but no-one can expect that to happen for all the people or systems reading
the article, or for the treatment given to be what the sender hoped or
expected.
Google, and it would seem Opera too, try to display an embellished version
of the plain text of the actual messages, by applying their own formatting
(involving, presumably, HTML and CSS). It sounds, from what you say, as
though Opera's display gets confused by the presence in the plain text
article of character sequences that could have a particular meaning in
some other context. Google manage to avoid that pitfall, but when their
"parsed" version of the article is further processed by their software to
produce what they describe as "Display original" (but which clearly is
nothing of the sort) then they too get confused by the same character
sequences as Opera does.
Having Opera add further non-standard headers seems unlikely to have any
effect.
The problem seems to come from getting irrelevant HTML or CSS operations
involved in a medium in which they have no place. Opera actually /sends/
perfectly acceptable plain text newsgroup articles; but somehow it manages
not to display them correctly - not even the ones sent using Opera. That
is the issue that Opera could usefully address - as could Google, of
course, for their apparently similar shortcoming.
Other RFCs can be found from here <http://www.faqs.org/rfcs/np.html> or
<http://www.faqs.org/rfcs/index.html>.
Rijk van Geijtenbeek
<catwh...@operamail.com>:
> Google, and it would seem Opera too, try to display an embellished
> version of the plain text of the actual messages, by applying their own
> formatting (involving, presumably, HTML and CSS).
That is not the case. Opera tries to displays what it gets in a clear and
present matter. It doesn't add or embellish anything. Of coursed we apply
some formatting, you don't want to look at raw messages - especially not
when they are using something else than 7 bits ASCII encoding. But this
uses only data already present in the received newsgroup posting, using
the well defined MIME headers.
> It sounds, from what you say, as though Opera's display gets confused by
> the presence in the plain text article of character sequences that could
> have a particular meaning in some other context. Google manage to avoid
> that pitfall, but when their "parsed" version of the article is further
> processed by their software to produce what they describe as "Display
> original" (but which clearly is nothing of the sort) then they too get
> confused by the same character sequences as Opera does.
>
> Having Opera add further non-standard headers seems unlikely to have any
> effect.
Seven bits (and those bits representing ASCII only) is not enough for
everyone. Actually, it is not enough for most people at this planet. So we
often need 8 bit encodings. And this would work perfectly alright, if only
we didn't have to take into accoutn some ancient newsservers that only
want to handle 7 bits transport. So, in comes QP, an 7 bits encoding
designed specifically to transport more than 126 characters - but in such
a way, that the result will be quite readable for client only supporting
ASCII. Hence the use of all those = characters. These are only visible
when looking at the raw message, or when using very old newsgroup readers.
For sending binary data in seven bits, the BASE64 encoding is used. Not
really efficient, it causes binary mail attachments to grow by about 30%
for example.
Opera does not normally send a message as QP-encoded. A test message for
example shows these MIME headers:
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
I don't know when exactly what triggers QP encoding. IIRC, at least when
responding to QP-encoded messages, but I'm not sure about that.
Whiskers
> Op Tue, 17 Oct 2006 21:11:10 +0200 schreef Whiskers
> <catwh...@operamail.com>:
>
>> Google, and it would seem Opera too, try to display an embellished
>> version of the plain text of the actual messages, by applying their own
>> formatting (involving, presumably, HTML and CSS).
>
> That is not the case. Opera tries to displays what it gets in a clear and
> present matter. It doesn't add or embellish anything. Of coursed we apply
> some formatting, you don't want to look at raw messages - especially not
> when they are using something else than 7 bits ASCII encoding. But this
> uses only data already present in the received newsgroup posting, using
> the well defined MIME headers.
Nevertheless, if you read the original article in this thread (Message-ID:
<op.thaks...@w2kjhm.ia.mum.edu>) using M2 and 'right click' on it
and select 'View all headers and message', then you can see the line
of my short programs containing equal signs, e.g. X =3D=3D Y,
which is not what was sent, and is not what my newsreader (slrn) displays.
Somewhere in its workings, Opera is changing the content of the article.
By coincidence, Google's G2 demonstrates what looks like the same
phenomenon.
That article includes these headers:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: Quoted-Printable
Now here's a thing; using M2 to read my own recent article in this thread
Message-ID: <mqhf04-...@ID-107770.user.individual.net>, sent using
slrn and not having any 'Mime' or 'Content' headers, Opera's 'View all
headers and message' display does /not/ replace the double equals sign
with the spurious "=3D=3D".
>> It sounds, from what you say, as though Opera's display gets confused by
>> the presence in the plain text article of character sequences that could
>> have a particular meaning in some other context. Google manage to avoid
>> that pitfall, but when their "parsed" version of the article is further
>> processed by their software to produce what they describe as "Display
>> original" (but which clearly is nothing of the sort) then they too get
>> confused by the same character sequences as Opera does.
>>
>> Having Opera add further non-standard headers seems unlikely to have any
>> effect.
>
> Seven bits (and those bits representing ASCII only) is not enough for
> everyone. Actually, it is not enough for most people at this planet.
Perfectly true. However, usenet is ASCII, and there are as far as I can
discover, no 'official' standards (yet) for extensions to usenet to
accommodate non-ASCII characters in either the article bodies or the
headers. I know that people do try to use 'Quoted Printable' in newsgroups
and that some newsreader programs can handle it well enough; some can
handle UTF-8, HTML, and Base64 too. That doesn't change the fact that such
things are non-standard and not universally or consistently accommodated (and
will get flamed in some newsgroups).
There is a strong (irresistible) case for extending the 'standards' for
newsgroups to accommodate languages other than American English. Sadly,
the IETF (The Internet Engineering Task Force) moves slowly and erratically
(see <http://www.ietf.org/ids.by.wg/nntpext.html> for anyone interested in
where NNTP progress is currently 'lapsed' - Section 10 of "Network News
Transfer Protocol", Clive Feather, 9-Jun-05, is relevant to this thread).
None of which explains why Opera (and as it happens, Google) seems
sometimes to impose inappropriate 'coding' or 'parsing' on articles
intended by the authors to be rendered as ASCII 'plain text'.
> So we
> often need 8 bit encodings. And this would work perfectly alright, if only
> we didn't have to take into accoutn some ancient newsservers that only
> want to handle 7 bits transport. So, in comes QP, an 7 bits encoding
> designed specifically to transport more than 126 characters - but in such
> a way, that the result will be quite readable for client only supporting
> ASCII. Hence the use of all those = characters.
An = character (or two) does not signify 'Quoted Printable' though, and
should not be treated as if it did.
> These are only visible
> when looking at the raw message, or when using very old newsgroup readers.
Newsreaders that comply with the present standards accepted as governing
newsgroups, do not need to display anything other than the 'raw message' -
indeed, should not, beyond allowing the user to choose colours and "fonts"
to suit their personal preferences.
No program should assume or impose a coding different from that intended
by the author.
> For sending binary data in seven bits, the BASE64 encoding is used. Not
> really efficient, it causes binary mail attachments to grow by about 30%
> for example.
Newsgroups are not email.
'Binary' newsgroups are an abomination, in my opinion - and those who use
them tend to use quite different software from those who use text-only
groups.
> Opera does not normally send a message as QP-encoded. A test message for
> example shows these MIME headers:
>
> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
> Content-Transfer-Encoding: 7bit
>
> I don't know when exactly what triggers QP encoding. IIRC, at least when
> responding to QP-encoded messages, but I'm not sure about that.
This looks like the trail that needs to be followed.
In my opinion, the newsreader program should not impose any encoding when
sending an article - at least, not without the author deliberately
specifying it. In the context of usenet as it is (rather than as one might
like it to be), any 'MIME' or 'Content' header is non-standard and could
have unintended consequences.
Whiskers
> <catwh...@operamail.com>:
>
>> Google, and it would seem Opera too, try to display an embellished
>> version of the plain text of the actual messages, by applying their own
>> formatting (involving, presumably, HTML and CSS).
>
> That is not the case. Opera tries to displays what it gets in a clear and
> present matter. It doesn't add or embellish anything. Of coursed we apply
> some formatting, you don't want to look at raw messages - especially not
> when they are using something else than 7 bits ASCII encoding.
snip
I find that seeing the 'raw message' is usually preferable. Here's
something like what I see in a newsgroup
<http://i11.tinypic.com/3yxg8aq.png>.
Rijk van Geijtenbeek
<catwh...@operamail.com>:
> On 2006-10-17, Rijk van Geijtenbeek <ri...@opera.removethiz.com> wrote:
>> Op Tue, 17 Oct 2006 21:11:10 +0200 schreef Whiskers
>> <catwh...@operamail.com>:
>>
>>> Google, and it would seem Opera too, try to display an embellished
>>> version of the plain text of the actual messages, by applying their own
>>> formatting (involving, presumably, HTML and CSS).
>>
>> That is not the case. Opera tries to displays what it gets in a clear
>> and present matter. It doesn't add or embellish anything. Of coursed we
>> apply some formatting, you don't want to look at raw messages -
>> especially not when they are using something else than 7 bits ASCII
>> encoding.
>
> snip
>
> I find that seeing the 'raw message' is usually preferable. Here's
> something like what I see in a newsgroup
> <http://i11.tinypic.com/3yxg8aq.png>.
As my message was also send as QP, you are abviously not looking at the
raw message, but the decoded message. Luckily slrn is not above
understanding such things... It even adds colors for the quoted texts,
while the raw message doesn't have any color information.
John H Meyers
>> One "equals": =
> That's what I can see.
In the *interpreted* message,
or in the "raw" original, exactly as received from NNTP server?
That's what I've been trying to find out all along,
although if I search my message store's raw files,
perhaps I can find out my own answer
(unless Opera doesn't even store exactly
what it sends or receives, either).
> I've quoted all the headers I can see [including:]
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: Quoted-Printable
I've been trying to find out exactly where the "QP" header
(and the encoded "equals" signs) got created,
but thus far I still haven't found out.
>> Next I'll see what Google thinks of it...
>
> The 'old' version of Google's new interface (G2) looks like this,
> (the "view in Groups Beta New!" version is very similar)
It seems to me that the GG "new beta" is exactly the same
as GG "current non-beta," except only for a "style sheet"
(to use the term very loosely); all actual content
looks the same to me (which seems rather sensible,
as no doubt there's a huge investment in the
underlying system to be preserved and re-used).
Has GG seemed to be down all day today,
to anyone besides us? -- we get "404 not found"
to everything, even to main URL groups.google.com,
which always gives us "302 Moved...
The document has moved here:
http://www.google.com/sorry/?continue=http://groups.google.com/"
...which in turn produces a tab title "404 Not Found"
and text message "The requested URL
/sorry/?continue=http://groups.google.com/
was not found on this server."
> the equals signs are exactly as I see them in my own news-reader
Thanks for showing the "interpreted" version,
but we know that all "interpreted" versions look right;
it's the "raw" data (what goes out to the news server
when I send it, or comes back from any news server
to anyone else's news reader from a news server
when they read it), which I'm trying to pin down, to see
whether there is any process to get source programs posted
reliably, that can be guaranteed to re-compile properly
when read by other people, without manual intervention,
without being messed up by re-wrapping,
by changed character encoding, or by anything else.
These source programs aren't very large,
but I am keenly interested in being able
to post them so that some newsgroup archive
(I had hoped Google's) could be relied upon,
so that I can post a URL and say
"just copy and paste from there,
and it will work for everyone"
> Whereas what Google displays for "Show original" is mangled:
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: Quoted-Printable
> One "equals": =3D
"Aye, there's the rub"
http://www.davidpbrown.co.uk/poetry/william-shakespeare-3.html
It all comes down to "where's that QP header
(and accompanying undesired encoding of equals signs)
coming from, and is there any way to prevent it?"
Which I still haven't grokked, but I'll keep looking;
by the way, I told Opera to use charset "Windows-1252,"
so there's been another change which I didn't set,
even though it makes no practical difference,
given that my postings are pure ascii "7-bit"
Thanks, Whiskers and Rijk.
-[ ]-
John H Meyers
I thought I'd mention that Opera crashed again,
as it typically does at least once or twice a day,
right after I clicked "Send" for the previous post;
after starting up again, I find that both the NNTP server
and the SMTP server each received their copy of the message,
so most every M2 crash occurs just after sending is complete
(but before any "1 message sent" yellow note can appear).
Is this a common report,
and is any stability improvement on the way?
Thanks.
-[ ]-
John H Meyers
> although if I search my message store's raw files,
> perhaps I can find out my own answer
> (unless Opera doesn't even store exactly
> what it sends or receives, either).
I have searched my entire store of messages,
and I offer as a typical example
the stored M2 file for the very same original *outgoing* post
to which I am now replying:
File name: 37474.mbs
From jhme...@nomail.invalid Thu Oct 19 02:40:28 2006
X-Opera-Status: 0400000000000092624536e59c00001434001000110000101a0000008400000001000000e700000000000000b4000000000000000000000000
Date: Wed, 18 Oct 2006 21:40:28 -0500
Subject: Re: Mailing/posting programs containing "="
From: "John H Meyers" <jhme...@nomail.invalid>
Organization: (real domain is miu.edu)
Content-Type: text/plain; charset=iso-8859-1
MIME-Version: 1.0
Bcc: [addresses expunged for privacy]
Newsgroups: opera.mail+news
References: <op.thaks...@w2kjhm.ia.mum.edu> <op.thbrxrw...@hodgins.homeip.net> <op.thbty...@w2kjhm.ia.mum.edu> <s3r204-...@ID-107770.user.individual.net> <op.thkfl...@w2kjhm.ia.mum.edu> <mqhf04-...@ID-107770.user.individual.net>
Content-Transfer-Encoding: Quoted-Printable
Message-ID: <op.thndp...@w2kjhm.ia.mum.edu>
User-Agent: Opera Mail/9.02 (Win32)
On Tue, 17 Oct 2006 12:51:50 -0500, Whiskers wrote:
>> One "equals": =3D
> That's what I can see.
****** That's enough!
Now look above at "Content-Transfer-Encoding" -- what do you see?
Does this not indicate that it is OPERA's M2 which has decided
to insert a "QP" content header into the *outgoing* message,
and that it is OPERA's M2 which has *already*changed*
each "equals" sign into "=3D" ???
If not, what's the explanation for why it's already this way,
before it's even been sent?
On the other hand, here is another, slightly earlier outgoing post:
File name: 36633.mbs
From jhme...@nomail.invalid Mon Oct 16 16:45:54 2006
X-Opera-Status: 040000000000008f194533b742000007aa001000110000060e0000008400000001000000e700000000000000b4000000000000000000000000
Date: Mon, 16 Oct 2006 11:45:54 -0500
Subject: Re: Mailing/posting programs containing "="
From: "John H Meyers" <jhme...@nomail.invalid>
Organization: (real domain is miu.edu)
Content-Type: text/plain; charset=iso-8859-1
MIME-Version: 1.0
Bcc: [addresses expunged for privacy]
Newsgroups: opera.mail+news
References: <op.thaks...@w2kjhm.ia.mum.edu> <op.thbrxrw...@hodgins.homeip.net> <op.thbty...@w2kjhm.ia.mum.edu> <s3r204-...@ID-107770.user.individual.net>
Content-Transfer-Encoding: 7bit
Message-ID: <op.thiwu...@w2kjhm.ia.mum.edu>
User-Agent: Opera Mail/9.02 (Win32)
On Thu, 12 Oct 2006 17:10:36 -0500, Whiskers wrote:
****** remainder deleted
This time, it's "Content-Transfer-Encoding: 7bit" !!!
But the one single different characteristic of this message body
is that there were no "equals" characters within this message body
(I examined it thoroughly before deleting it for brevity),
although there *is* an "equals" character in the header anyway
(in the "Subject," which is part of this same thread).
When I look at the same message as read *back* from the news server
and stored *again* by Opera, with "View all headers and message,"
it's still the same "Content-Transfer-Encoding: 7bit",
yet there's no problem displaying the "=" in the "Subject" line,
so any QP encoding of the body must be equally unnecessary.
Headers copied from viewed message:
Path: uni-berlin.de!individual.net!not-for-mail
From: "John H Meyers" <jhme...@nomail.invalid>
Newsgroups: opera.mail+news
Subject: Re: Mailing/posting programs containing "="
Date: Mon, 16 Oct 2006 11:45:53 -0500
Organization: (real domain is miu.edu)
Lines: 22
Message-ID: <op.thiwu...@w2kjhm.ia.mum.edu>
References: <op.thaks...@w2kjhm.ia.mum.edu> <op.thbrxrw...@hodgins.homeip.net> <op.thbty...@w2kjhm.ia.mum.edu> <s3r204-...@ID-107770.user.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net zypOBHrmq/roRgrEkixgtglLs60u7JOdqFglaYAO5nJkj3m+dq
User-Agent: Opera Mail/9.02 (Win32)
Xref: uni-berlin.de opera.mail+news:15808
[stopping after headers]
So OPERAs M2 is deciding to override the normal "Content-Transfer-Encoding"
(if even specified at all)
when there are "equals" characters in the message body,
apparently even on *outgoing* messages,
although as far as I am aware this is entirely unnecessary,
given that the "7-bit" charset includes the "equals" sign.
Even if that's not what Opera is actually sending out to the
NNTP and SMTP servers, this persistent doctoring of stored files
prevents most any simple program listing from being correctly stored,
even in the original outgoing message file.
Was there some other original problem
for which there was no other solution than this behavior?
How about inserting the alternative "Content-Transfer-Encoding: 7bit"
whenever it can apply, and keeping hands off the text instead?
-[ ]-
John H Meyers
> Opera tries to displays what it gets in a clear and
> present matter. It doesn't add or embellish anything. Of coursed we apply
> some formatting, you don't want to look at raw messages - especially not
> when they are using something else than 7 bits ASCII encoding. But this
> uses only data already present in the received newsgroup posting, using
> the well defined MIME headers.
Opera's addition of coloring/highlighting/etc. need not change the original
message text, any more than source program editors which provide
"syntax highlighting" need to change the *original* text to display it;
they need only format a web page in *memory* (or cache) for display,
which in turn produces a display on which a "copy to clipboard"
will copy the exact same original text; inserting "view all headers"
above that need not change the result either.
W:
>> Having Opera add further non-standard headers seems unlikely
>> to have any effect.
I think you're right.
Rijk:
> Opera does not normally send a message as QP-encoded.
> A test message for example shows these MIME headers:
>
> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
> Content-Transfer-Encoding: 7bit
Flowed? That would also be unkind to program listings :)
> I don't know when exactly what triggers QP encoding.
> IIRC, at least when responding to QP-encoded messages,
> but I'm not sure about that.
In my message store on disk, any message having any "=" in its body,
whether an incoming or even an outgoing message,
got a QP header (plus encoding of any equals signs in body),
while others were declared "7-bit" (IIRC, one old message got "8-bit"
but might that have been due to a different Opera setting?)
Yet Opera manages to display the non-encoded equals signs
which may appear in headers, so why was QP necessary?
This might be unrelated, but Eudora (which handles only email,
not NNTP) has a default option and a depressable tool button
on each message composition window, labeled
"May use quoted-printable," and its "help" text says:
"Quoted-Printable Encoding:
If this is on, quoted-printable (QP) encoding
MAY be used when sending messages
that contain long lines of text or special characters.
When on, it is used for all attachments.
It is recommended that this button always be on."
Despite my enabling this option, however,
when I send a message containing programs with equals signs
using Eudora, the message does NOT go out with a QP header,
nor do any of the equals signs get QP-encoded;
even the "Show original" at Gmail does not indicate QP,
and does not show equals signs as encoded, e.g.:
X-Gmail-Received: 18749c219f5605aca342454bf15285b86b13cb32
Message-Id: <200610190704....@is1.mum.edu>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Oct 2006 02:04:39 -0500
To: Recipient list suppressed:;
From: John H Meyers <jhme...@nomail.invalid>
Subject: QP test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Equals = == ===
[End of message]
So I take Eudora's phrase "MAY use QP" literally;
it seems to use it only when it *has*to*,
which might be good to emulate if possible.
-[ ]-
Whiskers
> Op Wed, 18 Oct 2006 18:03:10 +0200 schreef Whiskers
> <catwh...@operamail.com>:
>
>> On 2006-10-17, Rijk van Geijtenbeek <ri...@opera.removethiz.com> wrote:
>>> Op Tue, 17 Oct 2006 21:11:10 +0200 schreef Whiskers
>>> <catwh...@operamail.com>:
>>>
>>>> Google, and it would seem Opera too, try to display an embellished
>>>> version of the plain text of the actual messages, by applying their own
>>>
>>> That is not the case. Opera tries to displays what it gets in a clear
>>> and present matter. It doesn't add or embellish anything. Of coursed we
>>> apply some formatting, you don't want to look at raw messages -
>>> especially not when they are using something else than 7 bits ASCII
>>> encoding.
>>
>> snip
>>
>> I find that seeing the 'raw message' is usually preferable. Here's
>> something like what I see in a newsgroup
>> <http://i11.tinypic.com/3yxg8aq.png>.
>
> As my message was also send as QP, you are abviously not looking at the
> raw message, but the decoded message. Luckily slrn is not above
> understanding such things...
Was that encoding chosen automatically by Opera? You were replying to my
article, which had no 'Content' or 'MIME' headers and was sent as 'plain
text' ASCII, so that would not seem to be a trigger for Opera to choose
something different for the reply.
You don't seem to have used any characters that needed more than 7 bits.
Slrn has certainly managed to ignore the redundant "3D 0A" (equal sign
newline) combinations Opera inserted.
> It even adds colors for the quoted texts,
> while the raw message doesn't have any color information.
Any good newsreader can be configured by the user to apply fonts and
colours to aid legibility according to the display characteristics and
user preference; none of the characters in your article has been
replaced by another, nor have any additional characters been inserted.
Whiskers
> On Tue, 17 Oct 2006 12:51:50 -0500, Whiskers wrote:
>
>>> One "equals": =
>> That's what I can see.
>
> In the *interpreted* message,
> or in the "raw" original, exactly as received from NNTP server?
In the article as displayed by my newsreader, slrn.
I could email you the 'completely un-processed raw file' as received from
my news-server, if you like; clearly, trying to display or describe things
here is not very clear - particularly as none of us can be sure what the
others are actually going to see as we aren't all using 'plain text'
software.
Here is an ASCII (fixed-width font) version of the 'thread display' I have
for this thread at present, scrunched up to fit within conventional
margins and edited to include the local 'article number' in my spool so
that I can find each one again; let me know which ones you'd like to see
(my email address works). I run my own private 'news-server' so I get
exactly what each person sends, without any intermediate processing or
'parsing'.
Newsgroups: opera.mail+news
Subject: Mailing/posting programs containing "="
1 4075 [John H Mey]: Mailing/posting programs co [Wed, 11 Oct 2006 ]
2 4076 [John H Mey]: +-> [Wed, 11 Oct 2006 ]
3 4077 [John H Mey]: | +-> [Wed, 11 Oct 2006 ]
4 4078 [Rijk van G]: | | +-> [Thu, 12 Oct 2006 ]
5 4080 [Ivan Mager]: | +-> [Thu, 12 Oct 2006 ]
6 4079 [Whiskers ]: +-> [Thu, 12 Oct 2006 ]
7 4081 [David W. H]: +-> [Thu, 12 Oct 2006 ]
8 4082 [John H Mey]: +-> [Thu, 12 Oct 2006 ]
9 4083 [John H Mey]: +-> [Thu, 12 Oct 2006 ]
10 4084 [Whiskers ]: +-> [Thu, 12 Oct 2006 ]
11 4094 [John H Mey]: +-> [Mon, 16 Oct 2006 ]
12 4095 [Whiskers ]: | +-> [Mon, 16 Oct 2006 ]
13 4099 [John H Mey]: +-> [Tue, 17 Oct 2006 ]
14 4100 [John H Mey]: +-> [Tue, 17 Oct 2006 ]
15 4105 [Whiskers ]: | +-> [Tue, 17 Oct 2006 ]
16 4106 [Rijk van G]: | +-> [Tue, 17 Oct 2006 ]
17 4108 [Whiskers ]: | +-> [Wed, 18 Oct 2006 ]
18 4109 [Whiskers ]: | +-> [Wed, 18 Oct 2006 ]
19 4111 [Rijk van G]: | | +-> [Wed, 18 Oct 2006 ]
20 4117 [Whiskers ]: | | +-> [Thu, 19 Oct 2006 ]
21 4116 [John H Mey]: | +-> [Thu, 19 Oct 2006 ]
22 4104 [Whiskers ]: +-> [Tue, 17 Oct 2006 ]
23 4113 [John H Mey]: +-> [Wed, 18 Oct 2006 ]
24 4114 [John H Mey]: +-> [Wed, 18 Oct 2006 ]
25 4115 [John H Mey]: +-> [Thu, 19 Oct 2006 ]
> That's what I've been trying to find out all along,
> although if I search my message store's raw files,
> perhaps I can find out my own answer
> (unless Opera doesn't even store exactly
> what it sends or receives, either).
>
>> I've quoted all the headers I can see [including:]
>
>> Content-Type: text/plain; charset=iso-8859-1
>> Content-Transfer-Encoding: Quoted-Printable
>
> I've been trying to find out exactly where the "QP" header
> (and the encoded "equals" signs) got created,
> but thus far I still haven't found out.
That does seem to be a bit of a mystery.
snip
> Has GG seemed to be down all day today,
> to anyone besides us? -- we get "404 not found"
snip
No problem from here at present.
John H Meyers
> I could email you the 'completely un-processed raw file' as received from
> my news-server, if you like; clearly, trying to display or describe things
> here is not very clear - particularly as none of us can be sure what the
> others are actually going to see as we aren't all using 'plain text'
> software.
Yes, it's been confusing :)
> Here is an ASCII (fixed-width font) version of the 'thread display'...
That's very kind of you; let's see whether we can sort it out
without needing to email the messages over a "private channel"
[which others can't see] to avoid the confusion introduced over NNTP
(as well as by using M2 at either end for either news or mail :)
Here's what becomes of my own news posts (and emails):
My Opera -a-> My NNTP -b-> Other NNTP (and Google)
My Opera -c-> SMTP (emailed copies) -d-> My Eudora
My NNTP -e-> My Opera [reading posts]
Other NNTP -f-> other readers
Conveniently enough, you and I apparently use the same NNTP server,
which eliminates some wondering about paths -b-> and -f->
When *you* post with "slrn," with "=" in body:
Looking at: Your/My NNTP -e-> My Opera,
My Opera file 38244.mbs [headers only] has no C-T-E header
(which it turns out is always so, apparently
because I'm not downloading message bodies anyway).
My "View all headers and message," however,
also shows *no* C-T-E header and *no* encoding!
Even Google "show original" has *no* C-T-E header, *no* encoding in body:
http://groups.google.com/group/opera.mail+news/msg/dfba0d955ecf2ece?dmode=source
When *I* post with M2, however, with "=" in body:
My Opera stores local file 37748.mbs with C-T-E:QP and "=3D" in body
-c-> (SMTP) has the very same C-T-E:QP header and "=3D" in body.
Google "show original" gets the same C-T-E:QP header and "=3D" in body:
http://groups.google.com/group/opera.mail+news/msg/24d201fe3d62b857?dmode=source
Looking again at: My/My NNTP -e-> My Opera,
My Opera file 37761.mbs [headers only] has no C-T-E header of course, but:
My "View all headers and message" shows C-T-E:QP and "=3D" in body,
so I expect that this must be because it was received back from
the news server that way, only because the news server
supplies exactly what it was originally sent.
Comparing what happens when Whiskers posts a messsage with "=" via "slrn"
against what happens when *I* post a message with "=" in body via M2,
when we apparently post to the same news server (news.individual.net),
is there any way not to find Opera at fault in the second case,
for the eventual appearance of QP encoding both in Opera
(when reading post back from same news server)
and even as Google eventually displays it in "Show original"?
Mr. "Whiskers," can you now find the "raw" messages which you get
directly downloaded from the news server in each of the above cases
(using "slrn") and see whether an opera-independent comparison
verifies the same thing, and that Google's "original" version
is also just exactly the same as the news server's version?
I did not have this trouble when I used to post using Mozilla either;
for example here is another (old) "Show original" at Google:
http://groups.google.com/group/comp.lang.awk/msg/6ac75ab5c76dedd8?dmode=source
No C-T-E:QP, no "=3D", right?
How about even when I was using Opera M2/7.54 (Win32, build 3865):
http://groups.google.com/group/comp.sys.hp48/msg/44aba3368b047910?dmode=source
There we have C-T-E:8bit and *no* "=3D"
even though the body contains the formula: a+b=c+d
is that not so?
I would therefore have to opine that Opera 9 must be doing wrong,
sending headers and encodings to news servers
such that even if the RFC says otherwise,
the news server must be obeying and passing onwards.
Does this qualify as a bug yet?
-[ ]-
John H Meyers
I've just emailed myself (with Bcc:)
two brief messages using M2.
I didn't tell Opera to change any encoding whatsosver
between sending one and then the other.
This is what the recipient (at Gmail) got in each case:
----- Longer message (ignore "filler" content) -----
Date: Fri, 20 Oct 2006 04:24:23 -0500
Subject: Equals in body test
From: "John H Meyers" <jhme...@nomail.invalid>
Organization: (real domain is miu.edu)
Content-Type: text/plain; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Message-ID: <op.thpq2...@w2kjhm.ia.mum.edu>
User-Agent: Opera Mail/9.02 (Win32)
Opera's addition of coloring/highlighting/etc.
need not change the original
message text, any more than source program editors which provide
"syntax highlighting" need to change the *original* text to display it;
they need only format a web page in *memory* (or cache) for display,
which in turn produces a display on which a "copy to clipboard"
will copy the exact same original text; inserting "view all headers"
above that need not change the result either.
Equals =3D =3D=3D =3D=3D=3D
-[ ]-
----- Shorter message (actually sent first) -----
Date: Fri, 20 Oct 2006 04:21:55 -0500
Subject: Equals in body test
From: "John H Meyers" <jhme...@nomail.invalid>
Organization: (real domain is miu.edu)
Content-Type: text/plain; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: Base64
Message-ID: <op.thpqy...@w2kjhm.ia.mum.edu>
User-Agent: Opera Mail/9.02 (Win32)
RXF1YWxzID0gPT0gPT09DQoNCi1bIF0t
----- End of message -----
Why Base64?
The actual content of that shorter message
is just the very tail end of the longer message:
Equals = == ===
-[ ]-
When I sent the identical message from Eudora, however,
I got:
Message-Id: <200610200920....@is1.mum.edu>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 20 Oct 2006 04:20:37 -0500
To: Recipient list suppressed:;
From: John H Meyers <jhme...@nomail.invalid>
Subject: Equals in body test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Equals = == ===
-[ ]-
Am I seeing things, or does M2 make somewhat arbitrary decisions
on what C-T-E to use for each message (never in fact omitting C-T-E),
and uses those very same decisions even
when it comes to sending posts to NNTP news servers,
which someone has just asserted may not even be supposed
to support the same range of encoding options?
(But how do "binary" newsgroups function if not?)
Things seem to have been fine in Opera 7.54,
and are not fine at all in 9.02;
I don't know just where the transition occurred,
but I certainly don't like it as it is now.
Thanks for having waded through all this testing with me;
I think I'll quit while I still have a head :)
-[ ]-
Whiskers
> Additional surprises:
snip
> (But how do "binary" newsgroups function if not?)
Very badly; I'd rather they didn't exist - they make usenet look like a
very costly service for an ISP to support (so they are increasingly not
supporting it at all), generate endless complaints, and clog up internet
bandwidth by using grossly inefficient 'coding' to convert binary files
into the ASCII characters that can be carried by the NNTP protocol.
At least P2P and FTP transfers use relatively efficient methods for moving
all those pirated tunes and movies.
snip
> Thanks for having waded through all this testing with me;
> I think I'll quit while I still have a head :)
>
> -[ ]-
I'll return to this thread when I can concentrate again.
Tim Altman
<jhme...@nomail.invalid> wrote:
>Using 9.02.8585 (Win32):
>
>I have noticed that when I view newsgroup postings
>of my short programs containing equal signs, e.g. X == Y,
>then even in the archived "original format" post at Google,
>each "=" character has been replaced by "=3D",
>e.g. the above text now says: X =3D=3D Y
This is caused by using the quoted-printable (QP) transfer encoding.
>Needless to say, anyone trying to copy and use the posted programs
>subsequently reports that they do not work!
>
>The same thing is seen if you view my post in Opera,
>using "View all headers and message," even though
>my post is in pure ascii plain text,
>and ISO-8859-1 (the selected character set for my account)
>includes the ascii-defined "=" character.
Correct. Opera will not decode QP or base64 encoded text when viewing
the message body. This is by design.
Now, to address other issues brought up in this thread. I apologize
for replying in bulk, but it's a lot easier then trying to reply to
the ideal messages in the thread. Anyway....
What you're seeing is a bug. As you've figured out, whenever a
message body contains a "=", the message is sent QP-encoded. I've
filed a bug report.
Additionally, it appears that replying to a QP-encoded message (even
with the "=" removed), uses the QP encoding. That is most likely a
bug that I'll file later today.
Please let me know if I've missed any other bugs in the process of
skimming this thread. Thank you.
Some background on QP: The Content-Transfer-Encoding header and QP are
defined in RFC 2045. We try to use 7bit encoding for US-ASCII
messages and 8bit otherwise. QP is a fallback, mostly because it
makes reading messages difficult.
--
Tim Altman
Core QA
Opera Software
Remove NO SPAM from e-mail address to reply
Tim Altman
<jhme...@nomail.invalid> wrote:
>Additional surprises:
>
>I've just emailed myself (with Bcc:)
>two brief messages using M2.
>
>I didn't tell Opera to change any encoding whatsosver
>between sending one and then the other.
>
>This is what the recipient (at Gmail) got in each case:
[...]
>Date: Fri, 20 Oct 2006 04:21:55 -0500
>Subject: Equals in body test
>From: "John H Meyers" <jhme...@nomail.invalid>
>Organization: (real domain is miu.edu)
>Content-Type: text/plain; charset=iso-8859-1
>MIME-Version: 1.0
>Content-Transfer-Encoding: Base64
>Message-ID: <op.thpqy...@w2kjhm.ia.mum.edu>
>User-Agent: Opera Mail/9.02 (Win32)
>
>RXF1YWxzID0gPT0gPT09DQoNCi1bIF0t
>
>----- End of message -----
>
>
>Why Base64?
>
>The actual content of that shorter message
>is just the very tail end of the longer message:
>
>Equals = == ===
>
>-[ ]-
It's possible that the bug preventing Opera from sending that message
as 7bit or 8bit also causes problems with multiple =s, causing Opera
to send as base64.
Some notes:
- Opera will *always* use a Content-Transfer-Encoding header. It's
not required by clients (I can't recall if it's required by RFC 2045),
but it's good behavior. Likewise with the Content-Type header, which
also gives the message encoding.
- Opera should prefer CTEs in this order 7bit > 8bit > QP > base64.
- You can see the CTE Opera will use by saving a draft of the message
and viewing the raw draft. The CTE header should be in the message
already.
John H Meyers
> What you're seeing is a bug. As you've figured out, whenever
> a message body contains a "=", the message is sent QP-encoded.
> I've filed a bug report.
>
> Additionally, it appears that replying to a QP-encoded message
> (even with the "=" removed), uses the QP encoding.
> That is most likely a bug that I'll file later today.
> Please let me know if I've missed any other bugs
> in the process of skimming this thread.
Your next post catches the last one :)
> Some background on QP: The Content-Transfer-Encoding header and QP
> are defined in RFC 2045. We try to use 7bit encoding for US-ASCII
> messages and 8bit otherwise. QP is a fallback, mostly because
> it makes reading messages difficult.
There was probably no way to anticipate that web-based mail and news
providers (like Google) would also end up so reformatting messages
for display on web pages (with other columns and ads)
that the only way for a consumer
to get the original in proper format would be to
display the "raw" message ("Show original" at Google and Gmail),
and that this, just like Opera's similar "new" mode,
would continue to be incorrect if QP had been unnecessarily applied.
Thank you very much for your effective summary of the entire matter,
and for filing bug reports on our behalf; this is very exceptional
support for a product that is given away for free use,
and you are a very exceptional and polite person,
as well as very generous of your time,
in the face of all that comes your way in these newsgroups :)
-[ ]-
John H Meyers
> It's possible that the bug preventing Opera from sending that message
> as 7bit or 8bit also causes problems with multiple =s,
> causing Opera to send as base64.
It's surprising that simply stuffing
more 7-bit text into the same message
(still containing the original multiple =s)
relieves the need to use base64,
but unfortunately then resorts to QP instead
(so the issue is indeed about the inconsistency
and unpredictability of the current encoding decision).
> Opera will *always* use a Content-Transfer-Encoding header. It's
> not required by clients (I can't recall if it's required by RFC 2045),
> but it's good behavior. Likewise with the Content-Type header,
> which also gives the message encoding...
...Which I call "character set"
No objection to being explicit about C-T-E, just about the type chosen :)
> Opera should prefer CTEs in this order 7bit > 8bit > QP > base64.
Yes, indeed it should.
The encounter with a posting I had made using O7
seemed to suggest that this might once have been the case,
but that it veered off some time since,
without it having before now come to my attention,
as I search for and post references to some archived programs,
then find that there is no web view which can be correctly copied
to produce compilable or correct results.
> You can see the CTE Opera will use by
> saving a draft of the message and viewing the raw draft.
> The CTE header should be in the message already.
Does "viewing raw draft" require finding the stored ".mbs" file?
(I don't find any "view headers and message" option for a draft,
although perhaps that would be useful, since finding the stored file
is somewhat tedious, starting with guessing the correct account
to begin with at the top level of that nest of folders :)
[how about a menu option to display the file path?]
But if I do find the stored file, and if I'm finished editing
and ready to send, or even if I want to complete the editing
outside of Opera, can I edit the unsent file to correct QP,
and then send it from "Drafts" without further editing?
BTW, I don't worry about searching or indexing -- all I do
with M2 (besides read newsfeeds) is "post and mail it,"
then forget it, because it's on the web that all my stuff
gets ultimately archived, displayed, and searched.
Thanks again for your thorough and patient follow up;
I assume that OS knows what a great resource it has
in its members who spend extra time addressing the public here.
-[ ]-
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Fri, 20 Oct 2006 15:50:23 -0500, Tim Altman wrote:
>
>> It's possible that the bug preventing Opera from sending that message
>> as 7bit or 8bit also causes problems with multiple =s,
>> causing Opera to send as base64.
>
>It's surprising that simply stuffing
>more 7-bit text into the same message
>(still containing the original multiple =s)
>relieves the need to use base64,
>but unfortunately then resorts to QP instead
>(so the issue is indeed about the inconsistency
>and unpredictability of the current encoding decision).
Yngve informed me that Opera will switch to base64 if QP encoding
increases the size of the message to much. Because of the "=" bug,
each "=" would be three encoded characters. Base64 is much more
efficient.
>> Opera will *always* use a Content-Transfer-Encoding header. It's
>> not required by clients (I can't recall if it's required by RFC 2045),
>> but it's good behavior. Likewise with the Content-Type header,
>> which also gives the message encoding...
>
>...Which I call "character set"
>
>No objection to being explicit about C-T-E, just about the type chosen :)
>
>> Opera should prefer CTEs in this order 7bit > 8bit > QP > base64.
>
>Yes, indeed it should.
>
>The encounter with a posting I had made using O7
>seemed to suggest that this might once have been the case,
>but that it veered off some time since,
Yes, it is most likely a bug introduced in Opera 9. We did some work
on CTEs, specifically for Japanese text. It had some unfortunate
side-effects that we caught early. This may be a side-effect we
missed.
>> You can see the CTE Opera will use by
>> saving a draft of the message and viewing the raw draft.
>> The CTE header should be in the message already.
>
>Does "viewing raw draft" require finding the stored ".mbs" file?
No, just right click on the displayed message. For a draft, you'd
want to go to the Drafts view.
>But if I do find the stored file, and if I'm finished editing
>and ready to send, or even if I want to complete the editing
>outside of Opera, can I edit the unsent file to correct QP,
>and then send it from "Drafts" without further editing?
I have no idea. The draft should be in an .mbs file.
[...]
>Thanks again for your thorough and patient follow up;
>I assume that OS knows what a great resource it has
>in its members who spend extra time addressing the public here.
You're welcome. :)
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Fri, 20 Oct 2006 15:08:15 -0500, Tim Altman wrote:
>
>> What you're seeing is a bug. As you've figured out, whenever
>> a message body contains a "=", the message is sent QP-encoded.
>> I've filed a bug report.
>>
>> Additionally, it appears that replying to a QP-encoded message
>> (even with the "=" removed), uses the QP encoding.
>> That is most likely a bug that I'll file later today.
>
>> Please let me know if I've missed any other bugs
>> in the process of skimming this thread.
>
>Your next post catches the last one :)
I don't follow....
[...]
>Thank you very much for your effective summary of the entire matter,
>and for filing bug reports on our behalf; this is very exceptional
>support for a product that is given away for free use,
>and you are a very exceptional and polite person,
>as well as very generous of your time,
>in the face of all that comes your way in these newsgroups :)
You made me blush. You're welcome. I received the same treatment
from Rijk and Sue (who is no longer with Opera) when I first happened
across these newsgroups. I'm glad that I've been given the
opportunity to return the favor.
John H Meyers
> Yngve informed me that Opera will switch to base64 if QP encoding
> increases the size of the message too much. Because of the "=" bug,
> each "=" would be three encoded characters. Base64 is much more
> efficient.
On a very short message like the example (one line),
any "saving" would be so insignificant that it might be as well
to apply this rule only above some threshold size;
I suspect that this would fix the unreadability
(to a person trying to read the raw ".mbs" file)
in most any case of plain ascii text message,
even with QP applied.
Base64 can *never* really be more efficient anyway
for pure "7bit" ascii text, so the main problem
is still that QP ever gets used for such text,
and a secondary problem from that is that
for some tiny message with a few "=" signs,
the QP mistake propagates into a second mistake,
which is to disguise 7bit ascii into complete unreadability :)
> You can see the CTE Opera will use by
> saving a draft of the message and viewing the raw draft.
> The CTE header should be in the message already.
>> Does "viewing raw draft" require finding the stored ".mbs" file?
> No, just right click on the displayed message. For a draft,
> you'd want to go to the Drafts view.
I'm not getting the point somehow; if I right click
what I'm composing here, I don't see how to view the C-T-E header,
and if instead I right-click on the entry in the "Drafts"
message list and check "View all headers and message,"
nothing at all happens except leaving the check mark
checked off in the menu (so I still don't see headers),
and if I leave that "View..." checked in the menu
and then open the message,
there is still no C-T-E header visible,
just the same editable "outgoing headers" as usual.
I have spotted a recent phenomenon, however, where perhaps
the very first time I tried to open a saved draft
(after a crash, perhaps), it would show as if it were
an incoming message, scaring me into thinking that
I had lost the saved composition, much as used to happen
when there was a bug caused by any time in its editing history
that the message had ever been saved with an empty body --
but in the current version, a re-opening of the message
brings up once again the "compose" headers and the
message body in editable form, giving me great relief
(except that I can't seem to get back to where I can
ever see this message again in the form you hint to exist).
Is there anything I've missed in the recipe?
Thanks again.
-[ ]-
John H Meyers
TA:
> Please let me know if I've missed any other bugs
> in the process of skimming this thread.
JM:
> Your next post catches the last one :)
TA:
> I don't follow....
You had already posted a follow-up which completed
the discussion of all issues.
Now there's nothing left to do but wait for an update
that happens to rectify the apparently acknowledged
(and fully understood) "QP bug(s)" :)
Thanks again.
-[ ]-
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Sun, 22 Oct 2006 17:20:47 -0500, Tim Altman wrote:
>
>> Yngve informed me that Opera will switch to base64 if QP encoding
>> increases the size of the message too much. Because of the "=" bug,
>> each "=" would be three encoded characters. Base64 is much more
>> efficient.
>
>On a very short message like the example (one line),
>any "saving" would be so insignificant that it might be as well
>to apply this rule only above some threshold size;
>I suspect that this would fix the unreadability
>(to a person trying to read the raw ".mbs" file)
>in most any case of plain ascii text message,
>even with QP applied.
Perhaps.
>Base64 can *never* really be more efficient anyway
>for pure "7bit" ascii text,
Indeed.
>so the main problem
>is still that QP ever gets used for such text,
True.
>and a secondary problem from that is that
>for some tiny message with a few "=" signs,
>the QP mistake propagates into a second mistake,
>which is to disguise 7bit ascii into complete unreadability :)
Perhaps.
>> You can see the CTE Opera will use by
>> saving a draft of the message and viewing the raw draft.
>> The CTE header should be in the message already.
>
>>> Does "viewing raw draft" require finding the stored ".mbs" file?
>
>> No, just right click on the displayed message. For a draft,
>> you'd want to go to the Drafts view.
>
>I'm not getting the point somehow; if I right click
>what I'm composing here, I don't see how to view the C-T-E header,
>and if instead I right-click on the entry in the "Drafts"
>message list and check "View all headers and message,"
>nothing at all happens except leaving the check mark
>checked off in the menu (so I still don't see headers),
>and if I leave that "View..." checked in the menu
>and then open the message,
>there is still no C-T-E header visible,
>just the same editable "outgoing headers" as usual.
Once you save the message, you should be able to right-click the entry
in the Drafts view. That's what I did....
John H Meyers
> Once you save the message, you should be able to right-click
> the entry in the Drafts view. That's what I did....
This as yet unsent message is in my "Drafts" view.
If I right-click it in the message list,
a menu appears, and if I check
the "View all headers and message" option,
the check mark persists (still there upon re-display
of right-click menu), but the message does *not* open,
and I can see neither headers nor message.
If I then open the message (press Enter),
there are no headers other than those
which normally appear during "compose,"
in still-editable form,
and a right-click anywhere in this message
does not show the "View all headers and message" option,
so I'm still unenlightened.
This is all exactly as I said last time,
but now I set out to try all sorts of other things
that have not yet been suggested, and finally:
Apparently I have to *change* the *view* of my message list,
to display "List *and* message" (or "Message only,"
after selecting the desired message) --
then, at long last, I can see its stored headers
(although I can *not* then continue editing it!)
This is a bit awkward (and only took a week to figure out :)
although once the secret combination has been discovered
(and practiced several times to make sure),
I suppose I'll be able to do it again sometime,
and hopefully I'll also remember how to get back
to where I can again continue *editing* the draft,
after discovering how to only *view* it :)
Thanks as always for your help and your comments.
-[ ]-
John H Meyers
the "i" key also can be used to toggle the view,
so that what some might call the "message preview pane"
becomes visible, and shows what's been stored.
However, to continue editing, one must select the message
from the "message list" view and press Enter
(or choose "Edit" from the right-click menu),
which opens a "compose" window, unrelated to
the combination "message list and preview" view.
At every "save" while composing,
my simultaneously open "preview" tab
updates to show the newly saved content,
which enables me to report that:
Thus far it's in:
Content-Transfer-Encoding: 7bit
But now that I've typed a single "=" character, it's:
Content-Transfer-Encoding: Quoted-Printable
[with "3D" inserted after that one character]
So we've caught it in the very act of its bug!
What I'm next going to do is to find the stored ".mbs" file,
which is 41423.mbs (after eliminating feeds
which came in even after the last save :)
and I'm going to *edit* that,
just before pressing "send,"
to see whether I can *change* QP back to 7bit
Oops, file 41423.mbs is locked;
I will have to close all tabs first,
then edit the file in Notepad, say,
then I guess I have to re-open it in a "compose" window,
which is the only place that a "send" button appears.
Actually, I had to close Op
John H Meyers
> Actually, I had to close Op
As might be guessed from the abrupt termination above,
the message I had continued to edit using notepad
(after Opera closed) was *truncated* when Opera was re-opened
(after I had to close Opera completely, because closing tabs
wasn't sufficient to unlock the file to allow storing
from Notepad).
Perhaps it contained a "content-length," perhaps disguised
in the "Opera status" line in the saved file.
It also changed itself right back, before sending, to:
Content-Transfer-Encoding: Quoted-Printable
And the embedded "equals" symbol again had "3D" appended to it.
So it appears impossible to get around this bug
by editing the stored ".mbs" file with another editor,
while Opera is asleep, which was my last hope
for being able to post programs using Opera
that wouldn't have compile failures when copied
from "original format" posts saved elsewhere,
such as at Google.
I do hope that this bug is scheduled for resolution
somewhere in the near future, thanks.
-[ ]-
Tim Altman
<jhme...@nomail.invalid> wrote:
>Okay, when viewing Drafts,
>the "i" key also can be used to toggle the view,
>so that what some might call the "message preview pane"
>becomes visible, and shows what's been stored.
>
>However, to continue editing, one must select the message
> from the "message list" view and press Enter
>(or choose "Edit" from the right-click menu),
>which opens a "compose" window, unrelated to
>the combination "message list and preview" view.
Do you think you could formulate the above and your previous post into
a bug report, please? :)
John H Meyers
[my quoted stuff cut]
> Do you think you could formulate
> "the above" and your "previous post"
> into a bug report?
Which/what bug do you mean?
Those posts are about chasing down the QP bug,
also about confusion getting the multi-purpose
"M2 Window" to be what we need, when we need it,
so I'm actually not sure what you are looking
for me to file as a bug?
The former (QP) seems to be a bug,
the latter a gap in documentation, tutorial, or help,
given that now I can produce all the effects needed
upon demand, having re-stumbled
onto the numerous secret recipies :)
I'm stumped what to file.
-[ ]-
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Thu, 02 Nov 2006 16:55:21 -0600, Tim Altman wrote:
>
>[my quoted stuff cut]
>
>> Do you think you could formulate
>> "the above" and your "previous post"
>> into a bug report?
>
>Which/what bug do you mean?
>
>Those posts are about chasing down the QP bug,
>also about confusion getting the multi-purpose
>"M2 Window" to be what we need, when we need it,
>so I'm actually not sure what you are looking
>for me to file as a bug?
It seemed that you were running into problems getting the raw message
view working with Drafts....
John H Meyers
> It seemed that you were running into problems
> getting the raw message view working with Drafts....
Yes, because when a message
was selected in the "Drafts" message list and
"View all headers and message" was turned on,
as you suggested, nothing whatsoever happened,
as far as could be visually seen, while
if Enter was then pressed to "open" the message,
a "compose" window appeared, in which
the requested headers still did not appear.
Eventually I divined that this was because
of the combination of all these factors:
(a) The "View" type of the "Drafts" list was "List only."
(b) Nothing automatically opens when I request to see more info.
(c) Whereas the "Enter" key opens a *reading* view
for messages in other lists (e.g. newsgroups),
it opens an "editing" view for messages in the "Drafts" list.
(d) The only way, then, to open a *reading* view for a Draft
is to change the "View" type of what is now a message list,
so that the message can be read in the *same* window;
i.e. it is not possible to open a Draft for *reading* in a
separate window, as I always can (and do) everywhere else.
Should I suggest that turning on "View all headers
and message" should automatically change the "View" type
of the current window, if it's currently "list only,"
so that a non-expert won't think that every avenue has
been explored, yet the desired info can't be found?
The UI is ingenious, but it can also be confusing,
until after a lot of trial and error, the user can
come to know how to "psych it out" to find the path
out of an apparent "dead end street."
Is that enough of a "bug report," or do you still suggest
a regular filing? (I had assumed that UI discussion
falls into a different category).
Thanks again for your devotion to solving problems
and supporting users through this forum.
-[ ]-
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Fri, 03 Nov 2006 10:26:45 -0600, Tim Altman wrote:
>
>> It seemed that you were running into problems
>> getting the raw message view working with Drafts....
>
>Yes, because when a message
>was selected in the "Drafts" message list and
>"View all headers and message" was turned on,
>as you suggested, nothing whatsoever happened
[...]
>Should I suggest that turning on "View all headers
>and message" should automatically change the "View" type
>of the current window, if it's currently "list only,"
>so that a non-expert won't think that every avenue has
>been explored, yet the desired info can't be found?
Yes, that sounds like a good work-around. In any case, I'd consider
it a bug that nothing happens when you do "View all headers and
message".
[...]
>Thanks again for your devotion to solving problems
>and supporting users through this forum.
You're welcome. :)