On Fri, May 1, 2009 at 6:44 AM, Brian Schweitzer
<brian.brianschweitzer <at> gmail.com
> I give up.
> Why does the MusicBrainz style community, at least the vocal part, consider
> standard typography to be "obscure", "confusing", "difficult", etc?
> * I do know that I was taught standard typography, including the elipses,
> en-dash, em-dash, and hyphen, in school at around age 12, and didn't
> consider it difficult, hard, or confusing. (And then we covered it again,
> when I was learning French.)
> * Wikipedia does not consider it confusing, and in fact requires its use.
> * The authors of standard word processors don't consider it obscure, to such
> a point that they auto-insert it.
> * Most common wiki utilities include support for it (using --, ---, etc, to
> make insertion even easier, without having to even look up how to type an
> en-dash, etc.)
> * Guidelines for the use of correct typography are present is just about any
> English style reference book you care to look at.
> Yet, any time the suggestion is made that the en-dash, the em-dash, the
> elipses - or any other punctuation not found in the basic ASCII 127
> character set - be allowed, the same people threaten preemptive vetos,
> before an RFV is even made. Notice the emphasis on "allowed". Not
> mandated, not required, merely allowed. I even went so far as, when
> rewriting Guess Case, to make sure that it had support to allow
> auto-correcting this typography, when possible.
> Last time this was discussed, around 14 months ago, the argument was against
> it because it would have been required. A suggestion was made a few times
> that Guess Case could be made to auto-correct the typography, so users
> didn't have to type it. Both points would seem to be addressed here; the
> hyphen-minus is still allowed, just given lesser preference than the
> *correct* typographical mark, and the new Guess Case has been rewritten from
> scratch to perform, as part of its functions, exactly that suggested
> Look, MusicBrainz includes the other 100k or so characters in Unicode. So
> why, when it comes to this handful of typographical marks, is there such
> antipathy towards at least allowing those of us who care about typographical
> correctness to actually have it?
> I also don't buy this argument about people being tired of this debate. The
> argument so far, be it about the spaces or allowing the en-dash, has come
> down to "I don't like it, so I'll veto it". That's not a reasonable debate,
> that's a pissing contest, to see who can outlast whom.
> Please, those of you who oppose even *allowing* correct typography, explain
> to me why this is such a thing to allow to pass? With the exception of
> Chris, there was no comment on this RFC until it hit the end of day 6, just
> before it would have gone to RFV. Yet, look at the reasons given for
> opposition (I've tried to list all the reasons so far given):
> 1) " MBz is a collection of data, not a written work. Therefore, typography
> rules do not need to apply."
> 2) "n-dashes displayed in the couple of paragraphs above ... as question
> 3) "some mp3 players will have problems" / "it'll probably give some mp3
> players a fit"
> 4) the en-dash is "obscure typography"
> 5) "i don't believe it really reflects common practice in english"
> 6) ..."or record sleeves"
> 7) "Dash types are font dependent"
> 8) "If we add characters that don't display properly in applications people
> use, when a very close facsimile character is available, we risk alienating
> MBz contributors."
> 9) "we should be encouraging people to contribute by making it easy for them
> to do so"
> 10) "...some typographically-minded editors to spend untold hours running
> around the database and cleaning up people's dashes"
> Are any of these really arguments against allowing the use of *correct*
> 1) Data which consists of a collection of interrelated strings is not
> "written"? Also consider that that data can be, and already is,
> incorporated into text, where it then quite definitely becomes part of a
> written text. (Even if it somehow wasn't already???)
> 2) Any computer sold in at least the past decade has included support for
> any correct typography we might discuss, out of the box and by default.
> That some email (and IRC bots, I should mention... :P) servers still don't
> support UTF-8 should not be our concern...
> 3) This is entirely a tagger issue. Picard can replace the en-dash with a
> hyphen-minus (as well as replacing any other characters a user might wish to
> replace), if it is a problem. However, tagger or mp3 player issues should
> not define anything with regards to the data. Should we also forbid the use
> of any other non ACSII 127 characters, for the same reason? Of course not.
> 4) This may be more a comment on various educational systems, I don't know.
> However, the en-dash (as well as the figure dash, the em-dash, the hyphen,
> the minus symbol, the elipses, and the guillemot) has an entry in every
> English style guideline manual in my library. Speaking only for myself, it
> was part of my grammar school education on basic English language. And,
> when I studied a foreign language, those same punctuation marks were
> re-taught in the first year. So how, then, is the en-dash "obscure"? Would
> you consider, then, a semi-colon or full colon to be obscure typography?
> They are used far less often, in typographically correct English, than the
> en-dash or elipses, yet would the argument then be that, becuase they appear
> on the US keyboard layout, they're somehow not as "obscure"?
> 5) First, since when did any of our guidelines reflect usage of anything in
> common English? Capitalization Standard English definitely isn't "common
> English". This is an argument that, because "common English" doesn't really
> actually mean anything, can be made to argue for or against *anything*.
> 6) Re: record (or CD, or tape, etc) sleeves, first, PartNumberStyle mostly
> ignores that text anyhow, but second, if this argument were actually to be
> used here, it would be the first time, to my knowledge, that we allow *any*
> guideline to be determined by actually arguing that a record sleeve is
> always perfectly interpretable, especially with regards to punctuation.
> Given all the text effects that appear on sleeves, attempting to determine
> whether the character (if even present, outside of PartNumberStyle) used is
> a hyphen, en-dash, or something else... that's just a hopeless case. One
> could just as easily argue that all the characters on sleeve are en-dashes,
> em-dashes, hyphens, minuses, or figure dashes, and not hyphen-minuses.
> 7) Every character is font dependant. A correctly designed font should
> render an en-dash the width of a capital N, and an em-dash the width of a
> capital M. A hyphen-minus has no defined width, mainly because a
> hyphen-minus has *no defined meaning*. Whether or not the dashes and
> hyphens actually are distinguishable, to the human eye, for a given font,
> does not change the fact that in fonts that are correctly designed, and
> intended for readabiliy/legibility, these characters are plainly
> distinguishable. Also, whether or not they can be distinguished, regardless
> of the font, the computer still knows what character is being used, and,
> given #1 above, can then render or wrap the text properly when the
> characters are included from the database into other text.
> 8) See #3
> 9) "Allowed" or "Preferred" is not the same as "Required". Just because we
> encourage one character, the other character would not then somehow become
> wrong or incorrect. Providing the correct tools, like Guess Case, should be
> the answer here, not dumbing down the data, simply to make things "easier".
> 10) What people choose to edit is their own business. If someone wants to
> take the time to edit typography, why is this a problem? A facetious
> question, but should we also eliminate the capitalization standards, or even
> just get rid of all the guidelines entirely? That definitely would make
> data easier for new people to enter, as well as avoiding all that wasted
> time by all those editors going around using guess case (!) to fix
> capitalization and style issues... :P