User:Phil wink/Short schrift

From Wikipedia, the free encyclopedia

Goals[edit]

How should quantitative scansion best be presented in Wikipedia?

Ideally, the symbols used will meet all these criteria (though, as we'll see, there will in fact be trade-offs):

  1. Symbols likely to display correctly on most devices
  2. Monospaces correctly (really, a special instance of #1)
  3. Easily intelligible to readers
  4. Easy to type and edit
  5. Faithfully reflect existing scansion traditions

With respect to criterion #1, I tested all characters under discussion here in 2016 using several relatively standard and capacious fonts I happened to have on my computer (Arial Unicode, Calibri, Consolas, Courier New, DejaVu Sans, Liberation Sans, Linux Libertine G, Lucida Sans Unicode, TeXGyreScholia, Times New Roman).

Longum[edit]

There are really only 3 rational choices to indicate a long syllable:

# Symbol Unicode Description
1 - 002D hyphen
2 2013 EN-dash
3 2014 EM-dash

The hyphen, although the easiest to type, is extremely short and therefore a dubious choice when trying to symbolize long. When monospaced, 2 EM-dashes in a row tend to run into each other and look like 1 great line, whereas 2 EN-dashes are distinct. The EN-dash is also the character recommended by Brill. Therefore, the EN-dash is the soundest overall choice.

Anceps[edit]

Only 2 choices suggest themselves for anceps:

# Symbol Unicode Description
4 × 00D7 multiplication sign
5 x 0078 lowercase x

Brill (linked above) calls for the multiplication sign, an argument in its favor. Possibly since these characters are so visually similar and neither seems to present meaningful drawbacks, either should be acceptable as long as practice is consistent within an article. However, if u is used for brevis (as is recommended below), then a plain lowercase x is more fitting visually (and easier to type), and should probably be preferred.

Brevis[edit]

Typographically, brevis is the most difficult of the common symbols. It presents both the most possibilities and the most display problems.

# Symbol Unicode Description Notes
6 23D1 metrical breve In principle, this is plainly the ideal character for "breve". However, it appears in none of the fonts I've tested. Currently a specialist font (such as New Athena Unicode) is required for display. At least in the near-to-medium-term, use of this character guarantees a display failure across nearly all devices.
7 ˘ 02D8 breve This character is more or less correct, but technically represents the diacritic, not the concept "short". That is, it doesn't answer the question "how to I designate a short syllable?", but rather "what would I put above a vowel to indicate that it's short?". The result is that its tiny size and superscript position make it, visually, an unbalanced and hard-to-read glyph.
8 ̆ 0306 combining breve This is a combining character and should not be used on its own.
9 ͝ 035D combining double breve This is a combining character and should not be used on its own.
10 222A union This is a math symbol, not present in most fonts. Although it typically does display, the glyph will not match its surrounding font, but is imported from a "Math font". The worst result of this situation is that when verse scansion is set up in a monospaced font (a handy and recommended WYSIWYG practice), this glyph tends to be about 20% wider than the properly monospaced glyphs in its context, throwing the alignment of the entire scansion off.
11 u 0075 lowercase u A vanilla ASCII character, which will always display exactly as expected. The only option (along with its capital, below) which is easy to type. It monospaces correctly, and is almost small enough to look appropriate next to an en dash.
12 U 0055 capital U Same features as lowercase u above, but is visually larger, which for this purpose is a demerit.
13 υ 03C5 lowercase upsilon Displays correctly and lacks the wonky stem of the lowercase u. However, given that it is still (like "u") an asymmetrical alphabetic interloper, and that it is much harder to type, "u" should still be preferred over upsilon.

I feel a little dirty every time I see a homely lowercase u in a quantitative scansion. However, the deficits of the other options are, to me, decisive. Lowercase u is the only choice that consistently displays as expected and needed without drawbacks (other than aesthetics).

Other symbols[edit]

For foot divisions, the pipe (|) should be preferred to the slash (/). This is because slash frequently stands for ictus, accent, stress, beat, etc. in various scansion systems, and the pipe should help reduce confusion.

Similarly, for caesura, 2 pipes should be used. There is a single double-pipe glyph available in many fonts (U+2016 DOUBLE VERTICAL LINE); however, this was available in most but not all of the fonts I tested, and 2 pipes remains significantly easier to type than the double-pipe character, so I think 2 pipes should still be preferred.

These symbols (×, , u, |, ||) should accommodate the majority of Greek and Latin scansions. However, the complexity of the task should not be minimized; Brill notes no fewer than 26 symbols! A few additional suggestions are made below:

  • <u>u</u> = u (brevis in longo… underline variant)
  • ū = ū (brevis in longo… macron variant) This variant should be preferred because, lacking markup, it will align correctly when monospaced WYSISYG scansion is attempted.
  • <u>uu</u> = uu (biceps) In specialist fonts (like New Athena Unicode) this is available as a single glyph; however, since such specialist fonts are not present on the vast majority of users' machines, this markup version of the biceps is the only one that will display correctly. If used in monospaced scansion WYSIWYG editing will fail, but correct alignment can still be achieved.
  • <u>u͝u</u> = u͝u ("triceps") A little nuts, but common in Plautus and Terence; even New Athena Unicode does not appear to include this.

Other languages[edit]

Many languages beyond Greek and Latin have quantitative prosodies, and these come with their own scansion systems. However, my initial research (for the gory details, see User:Phil wink/Quantitative scansion code) suggests that broadly speaking these scansions can be translated into classical scansion without loss, whereas the reverse is not always true. Moreover, classical scansion is more likely to be understood by more readers of the English Wikipedia with briefer explanation, than are other systems. Therefore, while all prosodic systems deserve to be explained in their own terms, for individual scansions and for discussions of verse form where an in-depth remedial lesson on the language's prosody would be out of place, it is best to present quantitative scansions in classical symbols, even when this is not native practice for the verse in question. Native scansions may of course be presented along with classical scansions, where appropriate.

A note on WYSIWYG[edit]

The 2 best options for WYSIWYG editing and display of scanned verse are described at WP:POETRY#Scansion.