Horrible; if you are going to set a dash open and use it for the purpose of an em-dash, use an en-dash.
Setting an em-dash open is ugly as hell.
> I prefer to ASCII-encode my em dashes with three hyphens.
Two-hyphens is conventional for an en-dash. Since a set-open en-dash serves the same purposes as an em-dash, a lot of people just use that instead of the three-hyphen conventional encoding of an em-dash.
Some people use set-open hyphens on ASCII in place of dashes, which is actually probably the best thing in a monospace presentation but ugly in proportional fonts.
> Horrible;
I strongly disagree. A closed em-dash—like this—looks jarringly like the words either side of it are closely related, as if by an extra-long hyphen. For example, in t previous sentence, “this—looks” visually appears to me to be a single compound entity, which is ironic considering that the intention was to make them appear especially separated. The ideal spacing is a thin space on each side, but I find a full space totally acceptable.
Of course, worst of all is asymmetric spacing, like this— yuk.
Edit: I just realised a closed em-dash doesn't look too bad in these comments because there is a very slight space either side of it, but I still stand by the above. A closed em-dash is much worse in documents typeset in TeX, where the dash without manual spacing practically touches the letters either side of it.
While it was meticulously designed for on-screen legibility, these days higher resolution screens and anti-aliasing, etc. are a better solution than meddling with the letter shapes e.g., taller x-heights, bigger openings, etc.
One detractor did allow for Verdana when rendering fine-print/legalese at very small font sizes--as long as it was unlikely to be printed.
On most screens these days, you are probably better off, if using a font of Verdana’s vintage or older, using one optimized for print legibility.
It's best to use an open en-dash in the open case – which is standard in the UK (except for Oxford).
(This is taken from the Oxford Style Guide.)
> Some people prefer the way a ‘space-en-dash-space’ looks. Sometimes when you use the em-dash people say, “What is that? I don’t like that big long dash thing.” Some technical writers think the n-dash is the only one to use.
> It’s not a big deal. I usually use ‘space-n-dash-space’ instead of the m-dash – just to keep everyone happy. You can see this ‘wrong-n’ method used in countless websites, magazines and papers as a replacement for the m-dash. If you use the ‘wrong-n’ method and use it consistently, it works fine and seems to keep the greatest number of people happy.
http://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-d...
Example with a normal space:
The quick brown fox jumps over — and, sometimes, under — the lazy dog.
Example with a thin space:
The quick brown fox jumps over — and, sometimes, under — the lazy dog.
This Smashing Magazine article discusses spaces in more detail. At the bottom of the article is a list of different spaces and their corresponding HTML entities:
I'm using the default Verdana font. Here's a screenshot of what the post looks like on my computer (Firefox on Windows).
I guess I should have added a disclaimer to say that the thin space may not always appear correctly depending on the browser/platform/setup etc. :-)
This is because hackernews has font-family: Verdana, Geneva, sans-serif and I have neither of the named fonts installed.
On my system, hackernews is rendered using Dejavu Sans. This is presumably a default for Firefox on linux which I never realised until today.
¹ https://www.flickr.com/photos/mwichary/albums/page1
² https://www.google.com/doodles/30th-anniversary-of-pac-man
EDIT: Fixed now.
I don't know enough about punctuation to know whether he actually meant "em" when he wrote "en" in several places, but I'm going to assume he actually meant to refer to em-dashes some places, and en-dashes others.
Er, yeah.
That was just ugly.
I fixed (hopefully all of) those.
I never realised up until today (I am ashamed to admit) that the convention is for no spaces. I always offset señor em-dash.
However, I think my reasoning went thus. I put a space after ‘,’ unless the comma precedes a quotation mark. I similarly would never ever not put a space after ‘.’, nor ‘;’, nor finally monsieur ‘:’. Also to contrast with the way-one-uses-hyphens.
But an unbalanced em-dash, like so– would look preposterous so left open – is how I came to use it over time. But now that it has been brought to my I find that this– is not so preposterous and in a mono font this – does appear to be swimming in space. I may have to train myself–thus–though it may take some time.
These conventions are rarely very strict but they do help communicate your ideas. Understanding them and understanding the impact of not using them is an important set of knowledge if you want to be clear and well understood in your writing.
It is similar to good typography in that it isn't required but that it will often make the reader enjoy or understand the work more when reading.
Obviously there have been many great writers who knew how and why they were breaking those conventions. E. E. Cummings was a notable example.
You are free to break whatever convention you like. It will just effect your communication clarity.
Understanding that (and how and why too) will help you be more effective.
It’s no different to saying “you can program it that way if you want but understanding the conventions & methods other people use may help you have more readable and efficient code”.
This is not a hard concept to grasp.
I personally wrap them in thin spaces (U+2009), except in fixed‐width fonts, where I use an en dash with full spaces instead.
METHOD No periods separating sentence-structures already arbitrarily riddled by false colons and timid usually needless commas-but the vigorous space dash separating rhetorical breathing (as jazz musician drawing breath between outblown phrases)--"measured pauses which are the essentials of our speech"--"divisions of the sounds we hear"-"time and how to note it down." (William Carlos Williams)
---
http://www.writing.upenn.edu/~afilreis/88/kerouac-spontaneou...
---
edit: I kid, but those notes never left my adult mind and come to play to a lesser degree in my consideration in structuring letters, comments, and larger writings. I think the style has its place.
This space is not needed.
Your post is difficult to read because the em dash looks the same as the hyphen later in the post.
The argument that clinches it for me is editing. If you use an em dash with most word processing programs, you will consistently run into problems with the dash and surrounding text being treated as single words. You could reprogram things to recognize em dashes in those scenarios, but the standard behavior exists because of the way the vast majority of people perceive text.
Personally, I think the solution is a thin space, or to drop em dashes in favor of en dashes or something.
I use em dashes frequently, and these issues are frustrating to me. It's also frustrating translating them to plain text.
(Android users — try long pressing the - key in the punctuation menu.)
[1] https://en.oxforddictionaries.com/grammar/dash-and-em-dash
From some books and a magazine on my table: https://imgur.com/a/GNl2p
Rgds
Damon
Here are some alternatives:
* English: from 1 to 3
* Some programming languages: 1..3
* Math: [1, 3)
I guess this also the main purpose of the en-dash* : http://www.thepunctuationguide.com/en-dash.html . The problem there is that en-dashes can be inaccessible as in my case--typing on a phone.
* I actually originally missed your point because you forgot the hyphen between 'en' and 'dash'.
While we're on this subject, wide spacing between sentence-ending periods and the next sentence is the Right Way (tm). In ASCII that's two spaces. We're not animals. Let's behave accordingly.
You can see the original discussion, on the www-talk mailing list in July 1993 [1]. In the thread "Space after Periods," Terry Allen (an editor at O'Reilly) advocated for rendering more space after a period that closes a sentence than after a period that marks an abbreviation (in keeping with TeX and troff conventions).
I proposed that, "A WWW document (which uses proportional fonts) should have the same space between sentences as between words" and cited as authority "Words into Type" and the "Chicago Manual of Style." in 1993, "WIT" and "Chicago" set standards for publishing much like RFCs do for the Internet.
Terry Allen and I engaged in some snarky backbiting, then Ken Chang of NCSA Publications said he preferred "'one space fits all' as writers of HTML really shouldn't need to know the fineries of typography" and finally Guido van Rossum complained that, "extra space after a sentence... is mostly propaganda by Knuth and Kernighan (TeX and troff)" and implored, "Let's keep HTML simple!"
If you don't like the way that browsers collapse spaces between sentences, you can blame me (and Ken Chang plus Guido van Rossum who clearly had issues with whitespace beyond Python).
[1] http://1997.webhistory.org/www.lists/www-talk.1993q3/index.h...
This convention started with typewriters, and typesetters (e.g. my parents) will tell you that it is only considered correct in monospace fonts. This is also why HTML takes the liberty of reducing whitespace down to a single space character unless you go out of your way to use an .
People like to say that but it's never been explained to my satisfaction. Spaces are twice as wide in a monospace font. Why would you use more spaces when and only when you have a longer space?
I've also wondered this. Referring to this mock-up[1], I have the same monospace text with single vs double spaces after sentences, and proportional font with single vs double. The usual argument is that #2 is better than #1 (for mono), but #3 is better than #4 (for proportional). It feels like an inconsistency in the preference, and (as you pointed out) the reasoning doesn't make sense.
No, an em-width space between sentences with either half-em or third-em width space between words was typesettig convention for a long time before typewriters, and is where the triple (later double) spacing in typewritten manuscript convention came from.
Typesetting convention evolved to narrower and eventually mostly settled on equal-to-interword spacing after that typewriter convention evolved from earlier typesetting convention.
In short, wider sentence spacing goes back to the first English standards of the eighteenth century – including the first nine editions of the Chicago Manual of Style, and even the tenth still had it as an en-space – and only really started falling out of favour in the twenties. Typewriters had limited effect, but the automated typesetters that suceeded them were actually what killed it off, to simplify the programming.
I typically do still type a single space, but I take full advantage of my preferred TeX flavour's (ConTeXt) automatic conversion to wider spaces. One successful, post-education convert here!
EDIT: For completeness, here is that same text with an extra space: "I live in the U.S. I am happy." -- see how much easier that is to read? Sure, it's not that big a deal, but it's definitely kind to the reader.
I live in the U.S. I am happy.
I live in the U.S. I am happy.Full stops aren't generally used in abbreviations here, Mx Cryptonector.
Though there's a more recent trend to write "Nato" rather than NATO, which annoys me for the inconsistency that arises. Plenty of people pronounce VAT as one word, or PAYE, but these are usually left in capitals.
[0] https://www.theguardian.com/guardian-observer-style-guide-a
https://forlang.wsu.edu/help-pages/help-pages-keyboards-os-x...
The newer system is simply holding down keys to see accented variants which feels very natural on touchscreen devices but is slower than keyboard shortcuts if you know them.
(XKB manages to be both over-complicated and under-capable.)
It's fairly common for a lot of computer software to standardize on American English and American conventions, yet several of these are unique to under 1% of the world's population. This morning, a new installation of Microsoft Outlook asked for a location and timezone, yet still showed the weather for Washington DC in Fahrenheit above the calendar. The weather location was easily changed, but not the units. A well-known messaging app I installed last week shows my location as "K%©benhavn", for someone in Russia no character in the location is intelligible. A receipt from a restaurant in Europe has only about a 95% chance of correctly showing €, and maybe a 1/50 chance of showing the date in the wrong order. On an international flight between two non-English places, it's fairly common for the in-flight display to show miles and Fahrenheit with English, which I don't understand, and kilometres and Celsius with (say) Arabic, which I can't understand either — along with the other 99% of non-American connecting passengers.
I have no issue with the minor spelling differences and changes of idiom.
So yes, we mostly understand the Americans, except their measuring units and paper sizes.
> The same should go the other way around.
But it often doesn't.
> setxkbmap -option compose:menu
For example. There will be a dialog somewhere too.
In Ubuntu Unity and — I think — Gnome Shell:
Keyboard settings » Shortcuts » Typing » Compose key
Even specially enabling it is a real barrier in many ways.
Once you discover the em dash, it is hard to restrain yourself. But I'm trying to come back to the comma. It does its work without fanfare, almost invisibly. The mature writer realizes his job is to tell the reader something without getting in the way.
I land on the side favoring a space on each side of the dash. Unconventionally, I prefer to ASCII-encode my em dashes with three hyphens. The traditional two aren't long enough. But two is better than one. I always have to reread sentences by someone who thinks the hyphen and the dash are the same thing.