On Friday, May 31, 2002, at 03:45 AM, William Overington wrote:
>> > > This discussion seems to be related to the digital divide. > > Suppose that someone has access to a PC which has Windows 95 or Windows 98 > and has Microsoft Word 97 installed. The person wishes to produce a print > out of a transcription of a piece of text from an 18th Century English > book, > by keying in a copy of the text and then printing it out. The person > finds > that the text has a ct ligature in it. How does the person produce the > desired finished result? > It depends. You're assuming that the person wants to *exactly* (or fairly closely) reproduce the contents of the book. That, however, is typically not the case. IIRC, the original Declaration of Independence uses a medial long-s, but when I transcribe it now, I'll write "Congress" and not "Congreſs". I have a 19th century book on my shelves which uses the ct ligature throughout. If I were to quote a passage from it, however, I wouldn't bother to reproduce them. If I *were* to want to reproduce something like that so accurately that I' d capture all of its ligatures, I'd also try to match the typeface. In Latin typography, as a general rule, ligatures are considered a matter of stylistic preference. Typesetting a document with, say, Courier and lots of ligatures doesn't make aesthetic sense. > My suggested solution is to try to obtain a TrueType fount which contains > a > ct ligature, add the fount into the PC, open a Word 97 document, key the > text, wherever a ct ligature is needed, use Insert | Symbol and choose the > ct ligature from the dialogue box. > This is not a good solution. It's a kludge. You have to do it on older systems, true; we all know that. The problem is that it's still a kludge. The document works visually, but other operations such as search and replace or spell checking cease to function. The fi and fl ligatures are part of MacRoman (for some reason I do not fathom) and are therefore present in all Mac fonts. I once produced a document that looked better with them than it would have without, so (in Word) I did a global replace to get them in there. Note that I didn't get any of the *other* f-ligatures, just fi and fl. Instantly, Word realized that half of the words in my document were misspelled. It was a pain. > By there existing a publicly available document which includes within it > a > pairing of ct with the code point U+E707 the possibility exists that some > people might include ct in a TrueType fount and might place it at U+E707 > within that TrueType fount. No, not really. The existence of the entire Deseret Alphabet at its ConScript code points for years on some of my Web pages (in fact, I haven' t updated them yet) hasn't made Adobe or Monotype or anybody else start adding it to their fonts. > However, if that page were saved in HTML format, the code numbers would be > passed through to the HTML page, so if the list of code points were widely > used by people, then maybe the document containing the ct ligature could > be > displayed in a web page, interested viewers needing to use a fount with a > ct > ligature available. No. Wrong, wrong, wrong. HTML is ***NOT*** designed for accurate typography. You can make ***NO*** guarantees or assumptions as to the typeface that someone will actually see when they view your Web site. This is, in fact, an argument in the direction opposite the one you want to make. You may have designed your Web page to be viewed with Arial, but I may happen to hate Arial and use something else in a larger point size in concession to my aging eyes. Making your Web page illegible unless I have a specialized font (or a set of specific uses for the PUA) is, under the circumstances, a very bad idea. People whose Web sites require specialized fonts in order to be viewed usually make it possible for people to download the specialized fonts at the same time. > Also, the very existence of the list might lead to > someone who is authoring a fount choosing to add a ct ligature and various > other ligatures into the fount. > Again, no. Adobe, of course, is decoupling ligatures from code points in its own fonts, but it's at the head of the OpenType bandwagon. Other foundries will likely follow as time progresses. > The existence of the list also hopefully makes it more likely that in the > future \uE707 drawn to the screen of a Java applet will produce a ct > ligature rather than a rectangular box. > Again, no. Again, ConScript is your counter-example. Let's face it, it's hard enough to get people to adopt new features of Unicode when they become standardized. Weird little uses of the PUA are simply ignored. > Now, if this list of ligatures were not used, how exactly, precisely would > the person produce the print out of a transcription of a piece of text > from > an 18th Century English book, by keying in a copy of the text and then > printing it out? PDF. That's what it's for. If you *must* have a precise typographic appearance for your document, you use PDF. > I am reminded of the posting some time ago in this > discussion list where someone, I cannot remember who was the author, > commented on what that author called a great tsu nami (tidal wave) of the > computing industry, whereby from the moment that a new version of a > product > is launched, businesses presume that customers are using the very latest > version. The digital divide is a different issue. People have been arguing for years that a certain character must be present in Unicode because systems won't provide support for it any other way. This is a valid point, but at the same time, it would be improper to shackle the standard to that. Let's go back a decade, shall we? Not very long ago, major programs (like Word) made the assumption that all text was displayed using one byte per character. That meant that you couldn't have versions of the program that worked for Japanese or Chinese without a lot of rewriting. Did that mean that you had to force Japanese and Chinese to be encoded using one byte per character? No, it meant that people who wanted to do Chinese and Japanese had to live with not being able to do it with all their software, and it meant that they had to live with buying specialized programs instead of the generic version. You want to put a ct ligature in your document? The answer is the same. Even if you put it in the PUA, not all software now is Unicode-savvy, and not all Unicode-savvy programs handle PUA overrides or let you input arbitrary code points. Latin doesn't *require* the ct ligature. If you absolutely *must* have it, then you're simply going to have to limit yourself to programs like InDesign that let you have it in a way that works with the existing standard. For everybody—whether it be Big Faceless Corporation, Ltd. or my mother-in-law—there is a trade-off. New machines, new OSs, new programs all give you benefits but cost money and time to learn. I know a lot of typographers who refuse to move off of the decade-old version 3 of Fontographer because they like it better than anything that's come since. My wife won't upgrade to Mac OS X because she's easily confused when her desktop changes. (*sigh*) At the same time, it's ludicrous to insist that those of us who innovate must make all our innovations absolutely backward compatible to the dawn of time. > So, I wonder what is the answer to the question of how the person wishing > to > produce the print out of a transcription of a piece of text from an 18th > Century English book, by keying in a copy of the text and then printing it > out should proceed? Is it a case of "first buy a new PC" or what? > Let's alter the question. I'm a sinologist who wants to reproduce precisely my twelfth-century copy of the Confucian Analects on my Mac Plus. You know what? I'm hosed. I'm an Egyptologist who wants to reproduce precisely my copy of the Book of the Dead in the email I'm writing my grandmother. You know what? I'm still hosed. There are limits built into technology at every stage. They're not pleasant, but they're there. Ideally, the newer is always an improvement in some way. People have to decide whether the improvement is sufficient to justify their spending money on it. That's life. > The comment has been made "You are trying to find a solution to a problem > that has already been solved in a better way, and in the process you will > create more problems for anyone who uses your solution.". > > What, exactly and precisely, is the better way that is claimed? > In Latin typography, ligature formation is usually handled by markup. If a particularly ligature is absolutely required in your document at a particular point—not because it looks nice, or because it more accurately reproduces what was originally written—you can do it by inserting zero-width joiner. Typically, however, you turn ligatures on the same way you select point size or typeface. In InDesign and other applications, I select a region of text and turn on rare ligatures in a menu. Again, think of the standard f-ligatures. I'm seeing them through this email. I type "fish," and I see an fi ligature. *You* type "fish" and I see an fi ligature. It's because my system is smart enough to know that the fi ligature is standard in Latin typography, that it's present in my font, and that my font is one where "fi" looks better written with the ligature than it would without it. If I wanted the ct ligature, I'd have to find a font in my system that had it, switch to that font and turn the ligature on. It may not come through on your end—but then, the precise font or point size I'm using wouldn't come through, either. > What, exactly and precisely, are the problems which I will allegedly > create > for other people? > Two. 1) Non-display operations won't work anymore. 2) Users would be required to manually insert the ct ligature everywhere. > These are not rhetorical questions, I really would genuinely like to know. > I am quite happy to accept that perhaps a solution to the problem has been > found, yet wonder whether that solution is, as of today, only available to > people who are on one side of a digital divide. Again, there are many digital divides. There are things that work on Windows and not on Macs. There are things that work on Macs and not on Windows. There are things that work with InDesign that don't work with Word. There are things that work with Word and not with InDesign. There are things that work with Windows XP that don't work with Windows 98, and things that work with Windows 98 that don't work with DOS 3.0. There are things that work with Mac OS X that don't work with Mac OS 9, and things that work with Mac OS 9 that don't work with Mac OS 6.8.3 of venerable memory. Don't put yourself in the position of arguing that it's wrong to innovate. Innovation in the IT industry always creates a digital divide. > If there really are > problems which my list will cause then I will be happy to add a note > stating > of the problem. Yet I am very concerned that I may be in effect being > told > here that Unicode is only really intended for people with the very latest > equipment using expensive solutions that are only realistically available > to > rich corporations. > *sigh* Unicode has from the beginning been designed with the assumption that it would require rendering engines capable of complex typesetting. We've always known that. It's taken longer to get them to market than we would have thought and liked, but they're showing up now. It's a bar we've always had to cross, however, if not for Latin ligatures, then for Arabic and Devanagari, and so on. The advantage of this is (ideally) that once you get a system capable of doing Arabic or Devanagari or Latin ligatures, you get a system capable of doing all of them. That, at least, was the goal. > My thinking is that the existence of the list, (and hopefully, the list > having been distributed in this discussion group, many people will be > aware > of its existence, and may perhaps have even filed a copy for possible > future > reference), will hopefully make the availability of such ligatures in > founts > more widespread and will also hopefully influence people who make software > packages, such as relatively inexpensive electronic book publishing > packages, to build in a feature so that such ligatures may be accessed > from > a TrueType fount. 1) People who make fonts already know about ligatures. 2) The set of ligatures appropriate for Latin typography is very much font-specific. Zapfino has dozens of Latin ligatures because it's a calligraphic font. Courier should have none because it's a monospaced font. 3) People who write book publishing packages already build in features to access Latin ligatures. Microsoft Word is not a good program to use for publishing books. > I feel that the Unicode system should be available for all, not just for > people who are on the money side of the digital divide. It's a nice goal. It isn't a realistic one, however. Now, a question on my part. You're using the term "digital divide," but you're not defining it very well. Could you tell me: a) What the "digital divide" really is from your perspective—that is, what OS is on one side and what OS on the other? b) What are the relative numbers of people with systems on both sides? If, say, your divide were to be between Mac OS 6 or earlier and Mac OS 7 or later (the point at which Apple adopted TrueType as its primary font technology), then there are likely 99.99% of all Mac users on the 7-or-later side of the divide. Do you see what I'm asking here? ========== John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
