Re: English versus German

In article
<b90de218-898c-4f41-8e2c-99d8c8065699@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Peter T. Daniels" <grammatim@xxxxxxxxxxx> wrote:

On Jul 2, 8:15 pm, Nathan Sanders <nsand...@xxxxxxxxxxxx> wrote:
In article
<3598a0f9-7f6d-43ac-9e3b-12d991b6b...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
 "Peter T. Daniels" <gramma...@xxxxxxxxxxx> wrote:
On Jul 2, 5:00 pm, Nathan Sanders <nsand...@xxxxxxxxxxxx> wrote:

No ligatures for fi, fl, ff, ffi, or ffl.

A point gone unrebutted.

Kerning is terrible.  "Table" has the wrong spacing between T and a,
and tall italics characters inside parentheses bump into the
right-hand parenthesis.

Another point gone unrebutted.

Multiple accent marks on the same character (e.g., acute over
macron).

Possible in any system that supports Unicode.

TeX was able to handle this easily before Unicode.  

Uh, so what? This is 2009.

The point is that the way TeX does it doesn't require Unicode, doesn't
require the Combining Diacritical Marks range, doesn't require
assigning keyboard shortcuts, or any of that other fancy stuff.  It
works and has always worked directly "out of box", in a simple
straightforward manner.

Except that it's utterly incompatible with any user who doesn't happen
to have TeX.

You clearly don't understand what "plain text" means.

Yes, there are markup commands in the file, but the vast majority of
TeX source is just plain ordinary legible text.

A text in Unicode can be read in any current word processor (except
yours).

I have the latest version of Word.

It still handles
it easily: \'\=a puts an acute over a macron over "a".  I know how to
get an acute accent over "a" in Word, and I've modified my keyboard to
allow me to get a macron (this is not an out-of-the-box ability!), but
I don't know of a simple way to get both accents on the same character
in Word.

Have you not discovered the Insert Symbol button?

What's the keyboard shortcut for that?

Because it can be added to the QAT (Quick Access Toolbar), you can
assign any shortcut you want to it. I've seen no reason to do so
because it's a GUI, so the mouse is involved anyway.

Ah, yes, taking the hands off the keyboard is a highly efficient way
to work!

Presumably you could also assign a keyboard shortcut to it in Word2003
as well, but I'm not about to wake 2003 up to check.

Of course not. Waking up any version of Word is a chore!

And if you haven't even discovered the Combining Diacritical Marks
range of Unicode, you have very, very little business criticizing its
linguistic abilities.

Oh, I know where it is.  Unfortunately, they don't all combine
properly in Word.  I just tried "a" + combining macron + combining
acute and got a misaligned macron and a misaligned acute superimposed
on each other (rather than stacked and properly centered, as occurs in
TeX).

That's not Word's fault, it's the font's fault. Times New Roman has
never failed me in adding a diacritic to a letter (it even knows to
raise them above caps and tall letters.)

I tried it with Times New Roman, too. Word failed even worse! The
combining macron shows up as a square block (indicating a missing
symbol). The combining acute looks fine on "a", but looks terrible on
"m": it's too high, and off-center.

I just put an acute accent over an "m" in Word, and it changed the
font from Cambria to MS Reference Sans Serif, and now, everything I
type after that is in the new font!

Then you should learn how to use Word properly.

Praytell, how do you prevent the font from switching when the accented
character try to type doesn't exist in the font?  How do you know, a
proiri, whether any particular accent+character combination is missing?

You could look in Character Map. (Or, of course, in Insert Symbol.)
That shortcoming has nothing to do with Word.

Of course it does. If the combined character doesn't exist in the
font, but is easily created (e.g., by taking an acute accent and
placing it in the correct position over an "m"), then the proper
behavior is to create the character, not change the font for the rest
of the document!

If you don't like Times New Roman, you could try the Lucida family,
which was designed by Chuck Bigelow in consultation with Bill Bright.

Lucida Bright was the worst of all! Both of the combining diacritics
showed up as "missing character" squares.

Lucida Grande puts the acute on "a" correctly, and at least gets the
right height for the acute on "m", but it's still off-center. And
when trying to combine macron with acute, I still get superposition,
not stacking.

When TeX can't find the combination, it creates it from scratch, and
the result looks like it belongs with the rest of the text.  When Word
can't find it, it changes the font.

Considering Knuth's talent for typography, I think we can consider
that yet another win for Word. It's its way of telling you you need a
better-supplied font. But it only does that for precomposed characters
(i.e. with Unicode assignment) that are missing from the font in
question.

I don't see how on earth you can think this is a win for Word!

\'m in TeX produces "m" (in the same font as everything else) with an
acute accent at the correct height, perfectly centered over the "m".

Neither "option+e m" or "m + combining acute" work properly in Word
for any of the expected fonts (default, Times New Roman, various
Lucidas).

TeX's behavior is far more desirable.

Not to people who care what their output looks like.

I definitely care that my acute accents are properly centered!

If the accented character is not a pre-composed character in the font
(as acute-m is not in Cambria), TeX will compose the accented
character on the fly.  There is no font change for either that
character or the following ones.

Just like Word!

Nonsense.  I just say the font-changing behavior in Word.

If m-acute is a Unicode character, then it's telling you you can't
have that character in that font.

A shame. Apparently with Word, I can't have that character in any
font!

Fortunately, TeX let's me have it with any font I want!

Can you send a Word file to a colleague who doesn't own the same
version of Word as you (or no version at all!), and/or is working on a
a different OS than you (Mac versus PC... god forbid he's on Linux!),
and he'll be able to open your file and it will look the same as on
your machine?  As recently as last year, that wasn't true for me when
I was collaborating with a colleague.  Random symbols were missing,
pagination was different, and even the fonts weren't consistent.

If the same fonts were installed on both computers, the fonts were not
a problem. If the document was assigned to the same printer driver on
the different computers, there would be no formatting problem.

We had the same fonts.  The "Insert symbol" function is/was broken.  
If the inserted symbol was done on a PC, it showed up as a box on a
Mac.

You failed to mention that you were using obsolete, pre-Unicode fonts.

I was using the standard fonts that come with the latest version of
Word, and the font in question was Times New Roman.

None of these are problems with TeX, because TeX source files are all
plain text files, the most basic text file you can possibly have, free
and common to every computer system, every operating system, and every
time period.

And therefore consuming lots of extra computing power every time
they're opened.

?!?!  Plain text files are the easiest files for a computer to open!

But they will be gibberish anywhere else, since they have all those
thousands of coding characters (sort of like WordPerfect in its pre-
WYSIWYG days, but with much more code).

Apparently you don't know what "plain text" means. Here are some
sample paragraphs from my handout from this year's LSA, written in
LaTeX:


\textbf{Argument 3:} There seems to be a relationship between number
of vowels and extremity of articulation. For example, our preliminary
statistics on the absence of the ``corner'' vowels \ipa{[i]},
\ipa{[a]}, \ipa{[u]} in relationship to system size show a general
downward trend (as well as an interesting asymmetry among the three
vowels, with \ipa{[u]} missing more frequently and \ipa{[a]} missing
less frequently):

From pilot simulations with different values of $\gamma$ (the relative
weight of the articulatory energy) and different maximum values of $L$
and $B$ (the individual energies due to lip rounding and tongue
backness), we found that the results were improved when $\gamma$ was
lower for higher values of $N$. Thus, we propose that instead of
having \E{A} be the \textsl{sum} of the articulatory energies in a
vowel system, it should be the \textsl{average}. This seems
intuitively correct: a Spanish speaker isn't necessarily using more
articulatory effort to speak than an Arabic speaker, simply because
Spanish has more vowels.\footnote{In fact, the same argument could
apply to focalization. We plan to explore this idea in future work.}

Furthermore, we found that we still weren't getting quite as many
systems with central vowels as we would expect based on UPSID, so we
increased the maximum cost of $L$ and $B$ (though they were still kept
less than the maximum value of $H$, which was held stable at 1.0).

The most promising settings here occur when $\gamma=0.24$, not only
because of the higher number of matching systems with UPSID, but also
because the desirable system \ipa{[i~a~u]} is directly predicted (it
is only a near-hit at best when $\gamma=0.27$).


Now compare that to what happens when I open up a Word file in a
purely plain text editor. The first line looks like this:


PK^C^D^T^@^F^@^H^@^@^@!^@??^_????}^A^@^@T^E^@


I know that the word "testing" was in the Word document, but searching
the file for "testing" produces no results. The original text, no
matter how simple it is, is not encoded as plain text.

*THAT* is gibberish.

I wish you hadn't been making me defend Word so much (I'd much prefer
to be able to continue with FrameMaker), but from everything you've
said, it is considerably superior to (La)TeX.

If that's what you think, then you have the reading comprehension of a
pumpkin.

I rebutted every one of your points.

No, you clearly have not.

Nathan

--
Nathan Sanders
Linguistics Program
Williams College
http://wso.williams.edu/~nsanders/
.