Left justification of SUBJECT in email output
Bruce Bates
Posts: 3,045
Hi -
I realize that few if any of the Parallax crew utilize the email output feature of this·Parallax Forum, and probably a minority of the other members as well, thus my past pleas have gone unheard <sigh>. Based on the age-old principle that "it's the squeeky wheel that gets the oil", herein my continuing request for a small change to the email output from the Parallax Forums.·It just doesn't seem that what I'm asking for·could possibly take more that 10 minutes to implement, once the proper location in the software is found. Perhaps I'm wrong.
Here is an example from the last "quick reply" that I posted. I only mention that it was a "quick reply"·because there have been other notable occasions where differences were seen between fully edited replies, and those made with the "quick reply" window - no other reason.
/code
Per se example with one blank line before, and one after, for readability:
Subject:
········Re: [noparse][[/noparse]BASIC Stamp] Code after BRANCH doesn't run?
code/
As one can see, TWO lines are used for SUBJECT when only ONE is necessary. Therein, the contents of SUBJECT are NOT left justified within the field. Unfortunately perhaps, from what I can find, SMTP guidelines don't really permit any modification or changes to the user content once the message is on its way. Everything thus defined is left on a SIC or PER SE basis.
I don't know how other email clients attempt to·handle such an email, once received, but mine makes every effort to maintain that same SIC or PER SE precept. Since the content of the SUBJECT field is so overly long, by·virtue of the·two line format, usually I only see something like this displayed:
Subject: "SIC Stamp] Code after BRANCH doesn't run?".
I suspect any email client will only maintain some finite length of SUBJECT, and I also suspect that length may vary between email clients. Were it left justified, one would have as much significant content as the email client might permit.
Sometimes the displayed content is even worse, as this example (above) is really quite short (actual and significant alphameric content) compared to others I've seen. I can offer more confusing examples if necessary.
One nice feature of my email client that I can not presently utilize properly, by virtue of the loss of significance (so to speak), is Group by Subject which is a real powerful method of locally "threading" the individual outputs of each of the Stamp Forums, since I allocate one mailbox for each of the separate Stamp Forums (Stamps, SIC, Projects, etc).
Thanks for looking into this, when you get the chance.
Regards,
Bruce Bates
I realize that few if any of the Parallax crew utilize the email output feature of this·Parallax Forum, and probably a minority of the other members as well, thus my past pleas have gone unheard <sigh>. Based on the age-old principle that "it's the squeeky wheel that gets the oil", herein my continuing request for a small change to the email output from the Parallax Forums.·It just doesn't seem that what I'm asking for·could possibly take more that 10 minutes to implement, once the proper location in the software is found. Perhaps I'm wrong.
Here is an example from the last "quick reply" that I posted. I only mention that it was a "quick reply"·because there have been other notable occasions where differences were seen between fully edited replies, and those made with the "quick reply" window - no other reason.
/code
Per se example with one blank line before, and one after, for readability:
Subject:
········Re: [noparse][[/noparse]BASIC Stamp] Code after BRANCH doesn't run?
code/
As one can see, TWO lines are used for SUBJECT when only ONE is necessary. Therein, the contents of SUBJECT are NOT left justified within the field. Unfortunately perhaps, from what I can find, SMTP guidelines don't really permit any modification or changes to the user content once the message is on its way. Everything thus defined is left on a SIC or PER SE basis.
I don't know how other email clients attempt to·handle such an email, once received, but mine makes every effort to maintain that same SIC or PER SE precept. Since the content of the SUBJECT field is so overly long, by·virtue of the·two line format, usually I only see something like this displayed:
Subject: "SIC Stamp] Code after BRANCH doesn't run?".
I suspect any email client will only maintain some finite length of SUBJECT, and I also suspect that length may vary between email clients. Were it left justified, one would have as much significant content as the email client might permit.
Sometimes the displayed content is even worse, as this example (above) is really quite short (actual and significant alphameric content) compared to others I've seen. I can offer more confusing examples if necessary.
One nice feature of my email client that I can not presently utilize properly, by virtue of the loss of significance (so to speak), is Group by Subject which is a real powerful method of locally "threading" the individual outputs of each of the Stamp Forums, since I allocate one mailbox for each of the separate Stamp Forums (Stamps, SIC, Projects, etc).
Thanks for looking into this, when you get the chance.
Regards,
Bruce Bates
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim
Parallax IT Dept.
I use Eudora, and it has happened with 5.x, 6.x· and now with 7.0 so it's not going away soon I'd say. I DO have a BIG CLUE for you.
In the email output of my original post, the example·- the subject header I offered, within the body of·my message, was reflected back to me (by the DotNetBB program) with a real quirk within it. The beauty of the quirk is that it's obvious in the body of the message, as there it·isn't treated as a true Subject: header by my email client, or by anything else.·Back to the specific quirk in a second. I just want to make sure we're ... well grounded here.
If that didn't make sense, try this. Sometimes it's better to look at something odd or quirky OUT of context, than IN context. Out of context, it may be plain as day, while IN context,·the program processes may hide such a quirk.
Right before the significant (aka printed) characters which appear in the sample Subject: header offered as an example, is the following HTML sequence:
/x-tab x-tab/
but WITH additional unprinted characters between the two commands. Those·empty characters may or may not be blank spaces. They may or may not be significant to that command.·I don't speak HTML very well :-)
Since that HTML sequence above may unfortunately get "eaten" (processed instead of being printed) somewhere along the way, here it is again, phonetically!:
slash ex dash tab· ex dash tab slash
My guess is that it's that (probably unnecessary) sequence that's being ignored by (say)·Outlook, and other email clients, but is being respected by Eudora, and thus causing the strange Subject: header text spacing.
There is a very valid reason for that to be, but I'll not include it here, as it will just add more confusion to this problem. I'll be happy to tell you why in a separate email, just ask.
Thanks for your assistance.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim
Parallax IT Dept.