Avoiding those long lines of text we struggle to read!
Locked
Avoiding those long lines of text we struggle to read!
 
|
Quite a few of those posting to the Reflector have lines of text that
exceed the page width. The simple way to avoid that happening is to use "Body Text", or equivalent, in your e-mail client, highlighting any copied text first if that exceeds the page width. That way we can all read the message without scrolling sideways. Happy new year Dave, G4AON _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
CONTENTS DELETED
The author has deleted this message.
|
RE: Avoiding those long lines of text we struggle to read!
|
|
On Tue, 2007-12-25 at 11:45 -0800, Ron D'Eau Claire wrote:
> Interesting Dave. Are my lines over-length? No, yours are wrapped. > I use MS Outlook, and don't get over-length lines requiring scrolling from > anyone, either in ASCII as we see here on the reflector or in HTML in direct > messages. Outlook automatically wraps text at the edge of the window as > needed for proper display. Email clients will usually wrap text on outgoing messages to a certain line length (normally less than 80 characters), but some clients do not. The standard is for text to be wrapped. Unwrapped text has traditionally been considered poor practice and made emails difficult or impossible to read, depending on the email client used by the recipient. Unwrapped email displayed as-is on a text-only console (no scroll bars!) is impossible to read. In days past, this would often get the sender a nasty email in response! These days most email programs will wrap text on received messages if they have not been wrapped by the sender, but again some clients will not, and will display entire paragraphs as single lines if the sender did not wrap them. It is still considered good practice for email clients to wrap text in outgoing email to less than 80 characters. If you want to read the email format standards, you can find them here: http://www.lemis.com/email/email-rfc.html RFC 2822 is the original standard for plain ASCII (non-MIME email). RFC 2646 covers the text/plain MIME type. > What is your e-mail program? >From his email headers: Thunderbird 2.0.0.9 (Windows/20071031) _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
Re: Avoiding those long lines of text we struggle to read!
|
|
On Tuesday 25 December 2007 17:24:21 Brian Mury wrote:
> It is still considered good practice for email clients to wrap text in > outgoing email to less than 80 characters. That makes it break the common long URIs for a particular product or article. It also wraps a reply, causing alternate long lines with a word or two on the next line when the original has been formatted correctly with linefeeds embedded. I haven't read RFC2822 in over six years at least: I'm pretty sure it doesn't recommend setting automatic line wrap on an editor, at least for the reasons I mentioned above. I remember that it sets a limit on how long a line should be - under manual control using the "return" key every so often. Ian, G4ICV, AB2GR, K2 #4962 -- _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
Re: Avoiding those long lines of text we struggle to read!
|
|
>> It is still considered good practice for email clients to wrap text in >> outgoing email to less than 80 characters. >> > > That makes it break the common long URIs for a particular > product or article. It also wraps a reply, causing alternate > long lines with a word or two on the next line when the original > has been formatted correctly with linefeeds embedded. > I haven't read RFC2822 in over six years at least: I'm > pretty sure it doesn't recommend setting automatic line wrap on > an editor, at least for the reasons I mentioned above. I remember > that it sets a limit on how long a line should be - under manual > control using the "return" key every so often. > > Ian, G4ICV, AB2GR, K2 #4962 > paragraph and is hitting return to add a blank line before the next paragraph then one shouldn't put a linefeed in their message in my opinion. Also, anyone posting a URL in a message should go to www.tinyurl.com and convert it before inputting it. There's no excuse to have a long URL in a message anymore. -- 73 K5LDB ---------- Support the entire Constitution, not just the parts you like. _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
An alternative is to embed the long URL in the "<" & ">" character.
Most email clients then treat the long string of enclosed characters as a single token. Example: <http://www.elecraft.com/K2_Manual_Download_Page.htm#K2> IMHO I'd rather see the whole URL in an email. Safety first, I want to know what site I going to...etc. -- 73 Rod, Ai7NN ~*~*~Happy Holidays~*~*~ On Dec 26, 2007 7:03 AM, Leo Bricker K5LDB <[hidden email]> wrote: > ... Also, anyone posting a URL in a message should go to > www.tinyurl.com and convert it before inputting it. There's no excuse to > have a long URL in a message anymore. _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
|
|
The TinyURL service now has a "preview" feature
that allows you to see the expanded URL _before_ going there. So, I believe this addresses your concern. -- Scott (NE1RD)
|
Re: Avoiding those long lines of text we struggle to read!
|
|
In reply to this post by texasexpediter
On Wed, 26 Dec 2007 09:03:30 -0600, Leo Bricker K5LDB wrote:
> Unless one is typing on a manual typewriter or has reached the > end of a paragraph and is hitting return to add a blank line > before the next paragraph then one shouldn't put a linefeed in > their message in my opinion. That is all well and good if the e-mail sending program wraps (i.e. automatically inserts LF/CR) each line in your above- described "stream of consciousness" type text - what my wordprocessor calls "MS-ASCII Text"- not only on the text presented to the composer but also in the outgoing message. My e-mail program allows me to use a full-screen text editor which wraps at 70 characters per line and spell-checks each message prior to accepting it for sending. Not all e-mail programs will do the wrap on received text. Mine, for instance, is very polite -- if you send me a message with 300 characters in a row it will display all 300 characters in a single line if there are no LF/CRs in it. I get around that by hitting the delete key. I spend most of each day reading and answering professional and personal e-mail and usenet messages, and won't waste my time and emotions reformatting a message that the sender could have but failed to format before sending. I'd rather spend my time working 40 meters..... -- 73 de K2ASP - Phil Kane Elecraft K2/100 s/n 5402 From a Clearing in the Silicon Forest Beaverton (Washington County) Oregon _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
Re: Avoiding those long lines of text we struggle to read!
|
|
In reply to this post by texasexpediter
>> Unless one is typing on a manual typewriter or has reached the >> end of a paragraph and is hitting return to add a blank line >> before the next paragraph then one shouldn't put a linefeed in >> their message in my opinion. >> > > That is all well and good if the e-mail sending program wraps > I am unaware of any mainstream program that doesn't format correctly although I am not familiar with a large number of programs. I'm presuming good behavior on the part of the program. Perhaps that's too much to expect out of software though. -- 73 K5LDB ---------- Support the entire Constitution, not just the parts you like. _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
Re: Avoiding those long lines of text we struggle to read!
|
|
In reply to this post by Brian Mury-3
Brian Mury wrote:
> On Tue, 2007-12-25 at 11:45 -0800, Ron D'Eau Claire wrote: > >> I use MS Outlook, and don't get over-length lines requiring scrolling from Outlook doesn't, as far as I know, have options to display plain text email according to standards, so you will probably never see the problem if you only use that client. For thunderbird, setting the advanced option "mail.wrap_long_lines" to false ought to reveal problem articles. > > Email clients will usually wrap text on outgoing messages to a certain > line length (normally less than 80 characters), but some clients do not. It's part of the basic netiquette guidelines. > The standard is for text to be wrapped. Unwrapped text has traditionally > been considered poor practice and made emails difficult or impossible to Unwrapped text should be displayed as close as possible to unwrapped. On a GUI client that should mean as a single line with a scroll bar. On a fixed width display, that is with breaks between characters at the screen width. Unfortunately early GUI email clients treated text like notepad in wrap mode, and thus broke the email standards. Unfortunately, people using such broken clients don't see the problem, so it is an unrealistic expectation that people, brought up exclusively on GUI clients, should generate correct email in this respect. In case anyone is going to throw in the progress argument, really up to date email clients use some conventions that allow compatible email clients to re-wrap text, without sending a whole paragraph on one line. > > It is still considered good practice for email clients to wrap text in > outgoing email to less than 80 characters. The guideline is somewhat less than this, to allow for a few levels of quoting. > RFC 2822 is the original standard for plain ASCII (non-MIME email). > RFC 2646 covers the text/plain MIME type. See my signature, for the netiquette RFC that covers this sort of thing, but, as noted above, in reality all you can do is use the problem as a newbie detector, as complaining here is unlikely to change many people's ways. -- David Woolley Emails are not formal business letters, whatever businesses may want. RFC1855 says there should be an address here, but, in a world of spam, that is no longer good advice, as archive address hiding may not work. _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
«
Return to Elecraft
|
1 view|%1 views
| Free forum by Nabble | Edit this page |