Re: Codes for codes for codes for... (RE: Chromatic font research)
On Wed, 10 Jul 2002, Roozbeh Pournader wrote: > On Thu, 27 Jun 2002, Marco Cimarosti wrote: > > > Encoding the navy's flag alphabet or the Morse code would be exactly doing > > this: assigning a code to a code which represents a letter. > > BTW, which characters should be used to encode the dot and dash of Morse > in a typographically correct way? > > roozbeh > Wednesday, July 10, 2002 Well, assigning codes to Braille which Unicode does seems similar to me, but maybe it's to represent the visual image of the 8-bit Braille code. Regards, Jim Agenbroad ( [EMAIL PROTECTED] ) The above are purely personal opinions, not necessarily the official views of any government or any agency of any. Addresses: Office: Phone: 202 707-9612; Fax: 202 707-0955; US mail: I.T.S. Sys.Dev.Gp.4, Library of Congress, 101 Independence Ave. SE, Washington, D.C. 20540-9334 U.S.A. Home: Phone: 301 946-7326; US mail: Box 291, Garrett Park, MD 20896.
Re: Codes for codes for codes for... (RE: Chromatic font research)
At 20:18 +0430 2002-07-10, Roozbeh Pournader wrote: >On Thu, 27 Jun 2002, Marco Cimarosti wrote: > >> Encoding the navy's flag alphabet or the Morse code would be exactly doing >> this: assigning a code to a code which represents a letter. > >BTW, which characters should be used to encode the dot and dash of Morse >in a typographically correct way? Depends on your font. Middle dot and hyphen possibly. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Codes for codes for codes for... (RE: Chromatic font research)
On Thu, 27 Jun 2002, Marco Cimarosti wrote: > Encoding the navy's flag alphabet or the Morse code would be exactly doing > this: assigning a code to a code which represents a letter. BTW, which characters should be used to encode the dot and dash of Morse in a typographically correct way? roozbeh
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
On Saturday, July 6, 2002, at 03:42 AM, James Kass wrote: > > We certainly agree that ligature use is a choice. I think we diverge > on just what kind of choice is involved. You consider that ligature > use is generally similar to bold or italic choices. I consider use of > ligatures to be more akin to differences in spelling. If you're > quoting from a source which used the word "fount", it is wrong to > change it to "font". And, if you're quoting from a source which > used "hæmoglobin", anything other than "hæmoglobin" is incorrect. > If the source used "&c.", it should never be changed to "etc.". > So, if the source used the "ct" ligature... > > I see your point, but I think we're to the stage where we'll just have to agree to disagree. We *do* agree that ligation is a choice, but you're quite accurate in your assessment of where precisely we diverge. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
At 08:06 PM 7/4/02 +0300, John Hudson wrote: >>But ligature prohibition is a quite regular feature of German orthography >>and any Unicode-based system that intends to provide generic support for >>Latin script use, should be able to support it. As the prohibition is on >>a case-by-case and word-by-word basis, it has to be marked in the text. > >The specific requirements of some languages with ligature restrictions, >e.g. Turkish, are supported in the OpenType 'language system' model, which >enables different layout behaviour to be associated with different >orthographic systems. Unfortunately, the German rules really require >dictionary support to be properly implemented, since the rules for >word-internal ligature use/prohibition are intimately linked to spelling >and cannot be algorithmically arrived at. Once you support prohibited ligatures via ZWNJ, you can then extend the ligaturing model to (somehwat more) historical documents, by using Fraktur fonts that provide more ligatures. Similar prohibition rules that are spelling based apply there. This is still a far cry from trying to capture irregular printed editions or manuscripts. I would be in favor of using markup for such (academic) cases, since it is for a specialized need, not for standard redition of a text in a given font and writing system. A./
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
All your other good points noted: At 02:57 PM 7/1/02 -0600, John H. Jenkins wrote: >>Therefore, I would be much happier if the discussion of the 'standard' >>case wasn't as anglo-centric and allowed more directly for the fact that >>while fonts are in control of what ligatures are provided, layout engines >>may be in control of what and how many optional ligatures to use, the >>text (!) must be in control of where ligatures are mandatory or prohibited. > >Which is what Unicode 3.2 says. (You said it very nicely here, though.) > >(The standard case, BTW, seems to be Anglo-centric largely because this is >an English-speaking list and people always seem to start out with the "ct" > ligature they'd like to put in words like "respectfully." Sorry about > that.) I guess I'm just trying to hold the list up to a higher standard. A./
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
Kenneth Whistler wrote, > > > Another problem with TR28 is that its date is earlier than the date > > on TR27. This suggests that TR27 is more current. > > I don't understand this claim. > After misreading the dates and writing the letter last Monday, the internet connection was lost here for four days! I stand corrected (or, at least, better informed) on several items and am thankful to those who contributed to this thread. Best regards, James Kass.
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
John H. Jenkins wrote, > > There's another level of problem here, too. What if it isn't the author's > intent, but an artifact of the particular typesetter? When making an electronic reproduction of a specific text, a purist will even duplicate any typographical errors found in the source. >>... However, options should be preserved >> for the user. Ligature selection is a task for the author/typesetter >> at the fundamental level; it should not be completely left to the >> rendering system. >> > > Er, James. I've never said it should. The rendering system should have > the ability to do default ligation. The user should be able to override > that behavior. That's what happens on systems I see. If they do ligation > at *all*, they have a default behavior which can be overridden. Sorry to have misunderstood you. IMO, ligation should be off by default, and users should be able to enable it. I expect my browser to display the "fi" ligature whenever the string "f+ZWJ+i" is encountered. If the presentation form is used, naturally the ligature should display. However, if the original author simply entered "f+i", the string would be expected. This is because it isn't the browser's job to guess which orthographic rules apply. And, it isn't acceptable for a computer to alter a person's input without permission, even for display purposes. > I'll repeat a point that I've made over and over and over. > > The "ct" ligature does not exist in and of itself. It is a part of a > typeface. It doesn't make sense in general to ask for the formation of a > "ct" ligature without any reference to the typeface you're using. > Sorry, I'm still missing it here. Is this like saying the ligature "&" does not exist in and of itself; it is a part of a typeface? Or, like stating that it doesn't make sense to ask for Hindi text without any reference to the font? > The implication of what you're saying is that Latin typefaces should be > *required* to have a "ct" ligature on the off chance that the author of > text determines that it's "required" in a particular context. That gives > most type designers the heebie jeebies. It's bad enough that Adobe and > Apple are making them stick useless "fi" and "fl" ligatures in their fonts. Doug Ewell already answered this. > In any event, if an author determines that a "ct" ligature is honestly and > absolutely *required* in a particular context (as opposed to being > desirable), then the ZWJ mechanism exists. And, if an author determines that the browser or mark-up of choice doesn't have global ligature options, the ZWJ mechanism still exists? >>> To be frank, turning on an optional "ct" ligature throughout a document >>> by >>> means of inserting ZWJ everywhere you want it to take place makes as much >>> sense in that model—the model that Western typography uses for languages >>> such as English—as having the user insert a pair around every >>> letter they want in italics. >> >> Not at all. This is apples and oranges. The italic tags operate upon >> every character in the enclosed string equally. Using a similar ligature >> tag would be expected to make ligatures wherever possible within the >> enclosed string according the the user system's ability to render >> ligatures... irrespective of the author's intent. Depending upon the >> system, the same run of text could be expressed with no ligatures >> at all in a monospaced font or as scripto continuo in a handwriting >> font. >> > Er, you've just made my point, haven't you? The typeface makes a > difference. If you're ever in a situation where the typeface of the > originator may be different from the typeface of the receiver, you've lost > the ability to say whether or not ligatures should be used in a particular > context. Or do you want a "ct" ligature in Courier? I'd never disagree that the typeface makes a difference. On the contrary, I'm wondering if you haven't just made my point. If the ZWJ mechanism is used, then the ability to say whether or not ligatures should be used is directly encoded in the text and can't possibly be lost. > If I want to reproduce, say, my reproduction of the 1611 KJV, it's equally > incorrect to use a sans-serif typeface. Actually, technically, my > reproduction is already doing something very naughty by this standard, > since the *real* 1611 KJV was in blackletter. If a font isn't specified by the author, the author may be assured that somebody someplace is reading KJ in a Bazooka Joe typeface. If I were to post an HTML version of the 1611 KJV, in my intro would appear a note advising that if the reader wanted to see the display in the same flavor as the source, they should download and install a specific font or fonts along with links. > The precise reproduction of the appearance of a text is *NOT* possible in > plain text. It is *NOT* the intention of Unicode to make it possible. This is understood without plain text italic shouting. That's what HTML is for (e
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
- Original Message - From: "Asmus Freytag" <[EMAIL PROTECTED]> Sent: Monday, July 01, 2002 1:08 PM > Therefore, I would be much happier if the discussion of the > 'standard' case wasn't as anglo-centric and allowed more directly > for the fact that while fonts are in control of what ligatures > are provided, layout engines may be in control of what and how > many optional ligatures to use, the text (!) must be in control of > where ligatures are mandatory or prohibited. Well stated. Perhaps the best 'higher level protocol' is the mentation of the author. Best regards, James Kass.
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
At 19:53 +0300 2002-07-04, John Hudson wrote: >Well, we need and have (in OpenType and AAT) a general purpose >mechanism for typesetting texts employing ligatures as deemed fit by >the professional typographer. The expectation of such a mechanism is >that layout is applied to 'normal' text to render that text >according to the norms of particular typographic traditions, >publishing house styles, etc.. It should not be necessary to edit >the text, inserting ZWJ all over the place, in order to achieve this >result. It *is* necessary for some ligatures in some scripts. Let's say that there is in the entire corpus of Ogham three ligatures of RUIS RUIS. We don't want to encode that as a separate character, and we don't want it to be on by default since there could be numerous other examples of RUIS side-by-side with RUIS. But a disgustingly complete font could take the ZWJ into account for the ligature, which could be used by people wanting to typeset the non-standard but extant ligature. ZWJ forces unusual ligatures if the font supports them, and ZWNJ breaks them where not. >There are, however, kinds of documents in which the presence or >absence of ligatures is best determined by the author of the >document, and for that reason the ZWJ provides a means for the >author to specify ligation in plain text. As I have said. >But it seems to me that such documents are the exception rather than the norm This is certainly true. That's why ZWJ should not be preferred for non-exceptional kinds of ligation. But some scripts like Hungarian Runic and Germanic Runic have a fairly large set which are used from time to time and irregularly. >(a particular set of ligatures involving the lowercase f have been a >normative aspect of European typography for more than 500 years; in >my profession they are not considered optional or discretionary in >the setting of running text at typical sizes). Except for Turkish and Azerbaijani of course. :-) >Documents using ZWJ can only be reliably rendered in particular fonts. Well, the same holds true for all ligatures. >For example, there is no reason why I should not include the >sequence 'p ZWJ q' in a document, but unless I have a font >containing a pq ligature I will not be able to render the sequence >as intended by the author. But if you were changing the font, it would be available for those fonts which had it, and ignored for those fonts which didn't. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: [unicode] Re: Chromatic font research
Daniel, Is there a possibility to get an image what a red/black text looks like? Or do you know a website that has an image and more information? I like what you say at the end of your reply: "My thought at the time was that it was just a natural adjustment that one makes when going from ink and paper to computer typography, the goal being that we try to improve upon what the hand can do without losing the essence of it." It makes a lot of sense, especially now that color monitors and color printers are normal in our computer life. Why do we have to stick to monochrome characters and fonts and glyphs? A lot of the existing symbols in Unicode would look better in color, too. But reading your description on how the red markup is performed I could imagine it being done with a markup command changing color and returning to a character and applying the red markup character over it. Or what about a ZWJ with color change command? Dave --- Daniel Yacob <[EMAIL PROTECTED]> wrote: > > In the handwritten form, could you please say whether the adding of > the red > > increases the width of the area needed to represent the character? > > yes, absolutely, at least by the width of two dots. > > > > Also, when handwritten, does the scribe have a black pen in one > hand and a > > red pen in the other so that colouring takes place on a character > by > > character basis as writing proceeds, or does the scribe put down > one pen and > > pick up another, and, if so, is that on a character by character > basis or is > > that on the basis of producing a number of characters in black and > then > > adding the red afterwards. This would seem to be possibly > significant due > > to the possible need to allow for the greater width of the area > used for a > > character that is later to receive red flourishes. > > my oh my, these are wonderfully interesting questions :) I would > think the > use of tools would be highly sensitive to the experience, training, > and > learned habits of the writer. I haven't witnessed a great enough > number to > sensibly say what a norm would be. I certainly haven't seen a person > hold > two pens at once though. The scribes I've seen (maybe 4 I watched > closely) > were pragmatic in their writing, when a red word occurred they would > put down > the black brush and pick up the red and write the word. While the > utensil > was still in hand they would go back and add red dots or strokes > where they > thought it was needed. If no red words occurred (usually one every > sentence > or two depending upon the material) they would continue writing in > black > until the end of a sentence or section and stop there to change pens > to go > back and update punctuation or tonal marks. Again, I wouldn't draw > any > significant conclusions from this. > > I don't believe extra space is considered for adding red marks later, > the > red is allowed to bleed over the black. Trying to reproduce the > practice > with fonts though I have used an enlarged version of 1362 because the > result > looked much clearer. The original intention was lost when keeping > the original > proportions. My thought at the time was that it was just a natural > adjustment > that one makes when going from ink and paper to computer typography, > the > goal being that we try to improve upon what the hand can do without > losing > the essence of it. > > /Daniel > > Resending this email because for some reason my membership in the Unicode list got deleted. = Dave Possin Globalization Consultant www.Welocalize.com http://groups.yahoo.com/group/locales/ __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
John Hudson wrote: > Documents using ZWJ can only be reliably rendered in particular > fonts. For example, there is no reason why I should not include the > sequence 'p ZWJ q' in a document, but unless I have a font containing > a pq ligature I will not be able to render the sequence as intended > by the author. But the whole point of including ZWJ is to make the sequence "as connected as possible," which implies "and no more so." If you code the sequence "f ZWJ l" that should tell the renderer to use an fl ligature *if* one exists in the font, and to just use f l if it doesn't. Some fonts will be able to display the ligature, others won't. For "p ZWJ q" every font will just display p q. That's completely consistent with both the wording and the intent of ligation-by-ZWJ. There's nothing about using ZWJ to form ligatures that requires every font to contain all possible ligatures, nor anything that requires the renderer to switch fonts in mid-word and hunt around for a font that contains the requested ligature. If it's not there, it's not there. -Doug Ewell Fullerton, California
Re: (long) Re: Chromatic font research
At 19:36 +0300 2002-07-04, John Hudson wrote: >This is not Mac-only behaviour. So far I have yet to see a single >OpenType font that uses the ZWJ to produce ligatures: they all >proceed on the basis of applying a layout feature to regular text >and affecting any sequence (e.g. f i) found in the feature coverage >table in the font. Ironically, inserting a ZWJ in such a sequence is >more likely to break a ligature than it is to form one. A Runic OT font will want to use ZWJ and not another protocol. I confess that when typesetting books for publication I do replace fi with the hardcoded Mac Roman ligature because Quark doesn't seem to do the replacement itself even if the option is turned on. This in itself wrecks searching operations. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
At 23:08 7/1/2002, Asmus Freytag wrote: >Remember also that the simplistic model you present already breaks down >for German, since the same character pair may or may not allow ligation >depending on the content and meaning of the text - features that in the >Unicode model are relegated to *plain* text. > >Therefore, I would be much happier if the discussion of the 'standard' >case wasn't as anglo-centric and allowed more directly for the fact that >while fonts are in control of what ligatures are provided, layout engines >may be in control of what and how many optional ligatures to use, the text >(!) must be in control of where ligatures are mandatory or prohibited. > >I don't know of a case where a mandatory ligature of two characters is >sometimes prohibited, which means that for all practical cases, mandatory >ligatures, like LAM-ALIF tend to also be handled by the layout engine. But >ligature prohibition is a quite regular feature of German orthography and >any Unicode-based system that intends to provide generic support for Latin >script use, should be able to support it. As the prohibition is on a >case-by-case and word-by-word basis, it has to be marked in the text. The specific requirements of some languages with ligature restrictions, e.g. Turkish, are supported in the OpenType 'language system' model, which enables different layout behaviour to be associated with different orthographic systems. Unfortunately, the German rules really require dictionary support to be properly implemented, since the rules for word-internal ligature use/prohibition are intimately linked to spelling and cannot be algorithmically arrived at. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] Language must belong to the Other -- to my linguistic community as a whole -- before it can belong to me, so that the self comes to its unique articulation in a medium which is always at some level indifferent to it. - Terry Eagleton
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
At 14:31 6/30/2002, James Kass wrote: >Sounds like a giant step backwards from Unicode 3.0.1 (March 2002) >http://www.unicode.org/unicode/standard/versions/Unicode3.0.1.html >(see section "Controlling Ligatures") > >This page clearly states that ZWJ is proper for controlling the >formation of Latin ligatures and even uses f+ZWJ+i as an example. > >Unicode 3.1 (May 2002) uses the same examples: >http://www.unicode.org/unicode/reports/tr27/index.html > >Can you please point me to a URL for Unicode 3.2 ligature control? >This link (March 2002): >http://www.unicode.org/unicode/reports/tr28/ >...glosses over Latin ligatures suggesting that mark-up should be >used in some cases and ZWJ in others. > >Becuase of the reasons cited in that last link, IMHO ligature control >is best performed by the author of a document and ZWJ still seems >to be the most straightforward method. Well, we need and have (in OpenType and AAT) a general purpose mechanism for typesetting texts employing ligatures as deemed fit by the professional typographer. The expectation of such a mechanism is that layout is applied to 'normal' text to render that text according to the norms of particular typographic traditions, publishing house styles, etc.. It should not be necessary to edit the text, inserting ZWJ all over the place, in order to achieve this result. There are, however, kinds of documents in which the presence or absence of ligatures is best determined by the author of the document, and for that reason the ZWJ provides a means for the author to specify ligation in plain text. But it seems to me that such documents are the exception rather than the norm (a particular set of ligatures involving the lowercase f have been a normative aspect of European typography for more than 500 years; in my profession they are not considered optional or discretionary in the setting of running text at typical sizes). Documents using ZWJ can only be reliably rendered in particular fonts. For example, there is no reason why I should not include the sequence 'p ZWJ q' in a document, but unless I have a font containing a pq ligature I will not be able to render the sequence as intended by the author. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] Language must belong to the Other -- to my linguistic community as a whole -- before it can belong to me, so that the self comes to its unique articulation in a medium which is always at some level indifferent to it. - Terry Eagleton
Re: (long) Re: Chromatic font research
At 18:20 6/29/2002, Doug Ewell wrote: >Font designers regularly include a glyph for U+FB01 LATIN SMALL LIGATURE >FI. It has always been known, and obvious, that a user could access >this glyph directly by encoding U+FB01. With the advent of OpenType and >a smart-enough rendering system, the user could alternatively encode the >sequence U+0066 U+200D U+0069 (f ZWJ i) and get the same glyph. (Or, as >John Jenkins points out, if you have a Mac you can see this glyph simply >by encoding "fi," without the need for the ZWJ hint.) This is not Mac-only behaviour. So far I have yet to see a single OpenType font that uses the ZWJ to produce ligatures: they all proceed on the basis of applying a layout feature to regular text and affecting any sequence (e.g. f i) found in the feature coverage table in the font. Ironically, inserting a ZWJ in such a sequence is more likely to break a ligature than it is to form one. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] Language must belong to the Other -- to my linguistic community as a whole -- before it can belong to me, so that the self comes to its unique articulation in a medium which is always at some level indifferent to it. - Terry Eagleton
Serifs (Was: Chromatic font research)
At 05:41 6/27/2002, Wm Seán Glen wrote: >Serifs came about through experimentation because carving in stone tended >to crack unless it was done that way. Something about relieving the >stresses in the material, I think. I think this theory has been pretty thoroughly debunked. In the first place, the majority of archaic and classical Greek inscriptions have no serifs, and there is no evidence that this practice caused any kind of structural problems in the stone. I have just returned from the Thessaloniki, where I saw many such inscriptions in the archaeological museum and the royal tombs at Vergina. Fr Edward Catich, in _The Origin of the Serif_ (1968), provides a convincing argument that the development of serifs in classical Roman epigraphy derived from the practice of painting the letters on the stone prior to cutting them. They are an artifact of brush lettering, not stone cutting. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] Language must belong to the Other -- to my linguistic community as a whole -- before it can belong to me, so that the self comes to its unique articulation in a medium which is always at some level indifferent to it. - Terry Eagleton
Re: Chromatic font research
David Possin wrote about chromatic font research. Thank you for your interest. You and some other readers might like to know that I published some Private Use Area code point allocations which include some codes about these very topics on 2 July 2002. http://www.users.globalnet.co.uk/~ngo/courtfor.htm http://www.users.globalnet.co.uk/~ngo/courtcol.htm http://www.users.globalnet.co.uk/~ngo/court000.htm http://www.users.globalnet.co.uk/~ngo/golden.htm http://www.users.globalnet.co.uk/~ngo William Overington 4 July 2002
Re: (long) Re: Chromatic font research
[*groans in the audience*] I know, I know -- another contribution in the endless thread... In re: > The Respectfully Experiment > I used it as evidence that ideas about what should not be > included in Unicode can change over a period of time as new scientific > evidence is discovered. Having been intimately involved in nearly all the decisions made about what was included in Unicode over the last 13 years, and also being formally trained as a scientist, I think I may be qualified to dispute this conclusion. Most of the change in ideas about what can be included in Unicode have been the result of two types of influence: A. The encountering of legacy practice in preexisting character encodings which had to be accomodated for interoperability reasons. This accounts for many, if not all of the hinky little edge cases where Unicode appears to depart from its general principles for how to encode characters. B. The development of new processing requirements that required special kinds of encoded characters. This accounted for strange animals such as the bidi format controls, the BOM, the object replacement character, and the like. There is a very narrow window of opportunity for *scientific* evidence contributing to this -- namely, the result of graphological analysis of previously poorly studied ancient or minority scripts, which conceivably could turn up some obscure new principle of writing systems that would require Unicode to consider adding a new type of character to accomodate it. But at this point, with Unicode having managed to encode everything from Arabic to Mongolian to Han to Khmer..., I consider it rather unlikely that scientific graphological study is going to turn up many new fundamental principles here. As a scientific *hypothesis* I think this surmise is proving to hold up rather well, as our premier encoder of historic and minority scripts, Michael Everson, has managed to successfully pull together encoding proposals, based on current principles in Unicode, for dozens more scripts, with little difficulty except for that inherent in extracting information about rather poorly documented writing systems. > it just seems to me that some > extra ligature characters in the U+FB.. block would be useful. Best practice, and near unanimous consensus in the Unicode Technical Committee and among the correspondents on this list, would be aligned with exactly the opposite opinion. > In the > light of this new evidence, I am wondering whether the decision not to > encode any new ligatures in regular Unicode could possibly be looked at > again. As others have pointed out, "The Respectfully Experiment" did not constitute new *evidence* of anything in this regard. In any case, the UTC is quite unlikely to look at that decision again. The exception that the UTC *has* considered recently was the Arabic bismillah ligature, and the reason for doing so again was the result of considering legacy practice. This thing exists in implemented character encodings as a single encoded character. And furthermore, it is used as a unitary symbol, in such a way that substituting out an actual (long) string of Arabic letters and expecting the software to ligate it correctly precisely in the contexts where it was being used as a symbol, would place an unnecessary burden on both users and on software implementations. That is *quite* different from the position that claims that one, two, or dozens more Latin ligatures of two letters need to be given standard Unicode encodings. >if it cannot be done or would cause great anguish and > arguments, well, that is that, forget it. Good idea. --Ken
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
James Kass said: > One problem with TR28 is that it is worded so that it appears to > be "in addition" to earlier guidelines. It is. The way this works is as follows: The original decision about the ZWJ as request for ligation was documented in the Unicode 3.0.1 update notice. That documentation was rolled forward into UAX #27 (Unicode 3.1), where it was explicitly cast as text to replace the Unicode 3.0 text on p. 318 re Controlling Ligatures, including an update of the example table. The additional text in UAX #28 is just that -- an *addition* to the Unicode 3.1 text, not a replacement for it. This will all become more apparent when we can finally publish Unicode 4.0, which will roll all of the textual additions, once again, into a single published document. > This implies that the examples > used in TR27, for one, are still valid. They are. > In TR27, font developers are > urged to add things like "f+ZWJ+i" to existing tables where "f+i" > is already present. That recommendation still stands -- and, as John pointed out, is being implemented by vendors. > Another problem with TR28 is that its date is earlier than the date > on TR27. This suggests that TR27 is more current. I don't understand this claim. The date on UAX #27 is: 2001-05-16 The date on UAX #28 is: 2002-03-07 Please check that you are referring to the most recent (and only valid) versions of each. Otherwise, regarding the substance of this thread, I find myself in violent agreement with John, who it seems to me is quite ably stating the case for the current treatment as decided by the UTC. --Ken
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
On Monday, July 1, 2002, at 02:08 PM, Asmus Freytag wrote: > At 11:34 AM 6/30/02 -0600, John H. Jenkins wrote: >> Remember, Unicode is aiming at encoding *plain text*. For the bulk of >> Latin-based languages, ligation control is simply not a matter of *plain >> text*that is, the message is still perfectly correct whether ligatures >> are on or off. There are some exceptional cases. The ZWJ/ZWNJ is >> available for such exceptional cases. > > Remember also that the simplistic model you present already breaks down > for German, since the same character pair may or may not allow ligation > depending on the content and meaning of the text - features that in the > Unicode model are relegated to *plain* text. > *sigh* I'm clearly not expressing myself well here. I'm trying to state the general rule. Each time I do, I say there are exceptions. German is an excellent example of an exception. Michael's exceptional cases are exceptional cases. We put ZWJ/ZWNJ in charge of plain-text ligature formation to handle these cases. I'm fine with that. Turkish is another exception, BTW, where the typical "fi" ligature of Latin typography should not be formed. The issue -- as I see it -- is not whether or not *any* ligature control belongs in plain text, or whether or not manditory/prohibited ligation points should be marked in plain text. I'm not aware of anyone who is arguing against that position. We started out with a discussion of whether or not we should add more Latin ligatures (whether in the PUA or elsewhere) so that people can, in essence, create a plain-text representation of an older book where such were more common. (And, as always, if my memory is inaccurate please feel free to correct me here.) This is not an appropriate use of plain text IMHO. I do not believe, moreover, that the ZWJ/ZWNJ mechanism is appropriate for this sort of thing. This is rich text, and other ligation controls should be used. > Therefore, I would be much happier if the discussion of the 'standard' > case wasn't as anglo-centric and allowed more directly for the fact that > while fonts are in control of what ligatures are provided, layout engines > may be in control of what and how many optional ligatures to use, the > text (!) must be in control of where ligatures are mandatory or > prohibited. > Which is what Unicode 3.2 says. (You said it very nicely here, though.) (The standard case, BTW, seems to be Anglo-centric largely because this is an English-speaking list and people always seem to start out with the "ct" ligature they'd like to put in words like "respectfully." Sorry about that.) == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
At 11:34 AM 6/30/02 -0600, John H. Jenkins wrote: >Remember, Unicode is aiming at encoding *plain text*. For the bulk of >Latin-based languages, ligation control is simply not a matter of *plain >text*that is, the message is still perfectly correct whether ligatures >are on or off. There are some exceptional cases. The ZWJ/ZWNJ is >available for such exceptional cases. Remember also that the simplistic model you present already breaks down for German, since the same character pair may or may not allow ligation depending on the content and meaning of the text - features that in the Unicode model are relegated to *plain* text. Therefore, I would be much happier if the discussion of the 'standard' case wasn't as anglo-centric and allowed more directly for the fact that while fonts are in control of what ligatures are provided, layout engines may be in control of what and how many optional ligatures to use, the text (!) must be in control of where ligatures are mandatory or prohibited. I don't know of a case where a mandatory ligature of two characters is sometimes prohibited, which means that for all practical cases, mandatory ligatures, like LAM-ALIF tend to also be handled by the layout engine. But ligature prohibition is a quite regular feature of German orthography and any Unicode-based system that intends to provide generic support for Latin script use, should be able to support it. As the prohibition is on a case-by-case and word-by-word basis, it has to be marked in the text. A./
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
On Monday, July 1, 2002, at 06:28 AM, James Kass wrote: > > John H. Jenkins wrote: > >> That seems pretty clear to me. If you want a "ct" ligature in your >> document because you think it "looks cool," then you use some >> higher-level >> protocol. The "looks cool" factor simply doesn't apply unless you know >> what font you're dealing with, because "ct" "looks cool" in some fonts, >> but not others. > > It's enough that an author would want a "ct" ligature to appear in text, > the motivation for the desire isn't relevant. Authors who want to > specify a certain ligature know about font selection. > Au contraire, because of the italic analog. I may *want* a particular word to be in italics, but that doesn't mean that the italics belong in plain text. It is not the goal of Unicode to allow the complete representation of an author's intent in plain text. I can't typeset "Alice in Wonderland" in plain text. I'm sorry, but the Mouse's tail would simply get in the way. There's another level of problem here, too. What if it isn't the author's intent, but an artifact of the particular typesetter? > One problem with TR28 is that it is worded so that it appears to > be "in addition" to earlier guidelines. This implies that the examples > used in TR27, for one, are still valid. In TR27, font developers are > urged to add things like "f+ZWJ+i" to existing tables where "f+i" > is already present. > And for the record, Apple is doing that. > Another problem with TR28 is that its date is earlier than the date > on TR27. This suggests that TR27 is more current. > This may be a point for clarification in TR28. > Another issue is that a search of the Unicode site for "controlling > ligatures" gives TR27 as a hit, but not TR28. > > Having slept on this, I concur that it might be "cool" to be able to > turn on or turn off ligatures over a range of text or an entire file > using a higher level protocol. However, options should be preserved > for the user. Ligature selection is a task for the author/typesetter > at the fundamental level; it should not be completely left to the > rendering system. > Er, James. I've never said it should. The rendering system should have the ability to do default ligation. The user should be able to override that behavior. That's what happens on systems I see. If they do ligation at *all*, they have a default behavior which can be overridden. >> The programs that provide ligature control do so by means of having the >> user select a range of text and then changing the level of ligation. The >> type formats like OpenType or AAT support this by allowing the type >> designer to categorize ligatures as "common," "rare," "required," and so >> on. Thus, if I'm typesetting a document in Adobe InDesign, I'll select >> text, and turn "rare" ligatures on and thus see the "ct" ligature, if it >> exists in the font and if the type designer has designated it a "rare" >> ligature. > > That's a lot of ifs and it leaves too much to chance. When an author > determines that, for instance, a "ct" ligature is required, there needs > to be a method to encode it which is unambiguous. ZWJ fits the bill. > I'll repeat a point that I've made over and over and over. The "ct" ligature does not exist in and of itself. It is a part of a typeface. It doesn't make sense in general to ask for the formation of a "ct" ligature without any reference to the typeface you're using. The implication of what you're saying is that Latin typefaces should be *required* to have a "ct" ligature on the off chance that the author of text determines that it's "required" in a particular context. That gives most type designers the heebie jeebies. It's bad enough that Adobe and Apple are making them stick useless "fi" and "fl" ligatures in their fonts. In any event, if an author determines that a "ct" ligature is honestly and absolutely *required* in a particular context (as opposed to being desirable), then the ZWJ mechanism exists. >> To be frank, turning on an optional "ct" ligature throughout a document >> by >> means of inserting ZWJ everywhere you want it to take place makes as much >> sense in that modelthe model that Western typography uses for languages >> such as Englishas having the user insert a pair around every >> letter they want in italics. > > Not at all. This is apples and oranges. The italic tags operate upon > every character in the enclosed string equally. Using a similar ligature > tag would be expected to make ligatures wherever possible within the > enclosed string according the the user system's ability to render > ligatures... irrespective of the author's intent. Depending upon the > system, the same run of text could be expressed with no ligatures > at all in a monospaced font or as scripto continuo in a handwriting > font. > Er, you've just made my point, haven't you? The typeface makes a difference. If you're ever in a situation where the typeface
Re: (long) Re: Chromatic font research
On Monday, July 1, 2002, at 05:31 AM, Michael Everson wrote: >> I must point out that for English (and a lot of other languages), the >> use of ZWJ to control ligation is considered improper. The ZWJ >> technique for requesting ligatures is intended to be limited to cases >> where the word is spelled incorrectly if *not* ligated > > What! No! Look at my paper and the examples of Runic and Old Hungarian > and Irish. There are examples where ligation is used on a nonce-basis, > not having anything to do with global ligation or "correctness". > Michael, I was very careful to say "English (and a lot of other languages) ." And, by and large, the software which supports ligation doesn't compel global on-or-off, so that nonce-bases are supported. What's frustrating for me about this never-ending discussion is that it always seems to come down to the stupid ct-ligature in English. I have a book that uses it *everywhere* and it gets *really* annoying. :-( I have sitting in front of me a reprint of a nineteenth century reproduction of the 1611 King James Version of the Bible. It uses the "ct" ligature in the headers, but not in the text. (It also uses the long-s, by the way.) But if someone were to come to me and ask how you would use plain text to reproduce this text, I'd tell them you can't, or shouldn'tt rying to reproduce precisely the visual appearance of a text isn't a job for plain text. Period. I also have a font on my machine based on the handwriting of Herman Zapf. It's a gorgeous font with a huge, idiosyncratic set of ligatures. It doesn't make sense to have the user (or software) insert ZWJ all over the place on the off-chance that the text will end up being set with Zapfino to make sure that these ligatures form correctly. Our system fonts are set, moreover, to do fi- and fl-ligature formation automatically (well, most of them are). That's because it's the appropriate default behavior for most Latin-based languages. (Not all. I know that.) Where this behavior is *not* appropriate, there are mechanisms, including the ZWJ/ZWNJ one, which can override the default behavior. This means that file names, menus, dialog boxes, email, and so on all do the most-nearly-correct thing without having to be told to. >> (and similarly ZWNJ is intended to prevent ligature formation where that >> would make the word spelled incorrectly). The kind and degree of >> ligation in English is generally considered a sylistic issue and is best >> left to higher-level protocols. Thus saith Unicode 3.2. > > It doesn't go so far as to say what you did. Maybe Book needs to check > the text some on this point. We should have consensus. > No, the bit about spelling is simply my attempt to state informally the idea that Unicode 3.2 is attempting to convey. Let's just have a quick survey here to see if there's consensus: 1) In Latin typography, ligature formation is generally a stylistic choice. There are exceptions, and these exceptions are more or less common depending on the precise language being represented. 2) Where ligature formation *is* a stylistic choice, it should not be controlled in plain text but by some sort of higher-level mechanism. Such a mechanism should allow the default formation of ligatures with the ability for the user to override the default behavior. 3) Where ligature formation is *not* a stylistic choice, the ZWJ/ZWNJ mechanism is an appropriate one to provide ligation control. 4) The precise set of ligatures in a Latin typeface is design-specific. A typeface should not be required to include a set of ligatures which do not make aesthetic sense for the overall design. This last point, by the way, is the one which is the big sticking point for the large type foundries that I've spoken to. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
RE: Chromatic font research
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Suzanne, there's always a risk in making facecious comments > that someone > else will think you were serious and run with it. I suppose you are going to say that Mark Davis' Mr. Potato head concept was facetious as well??? ;^)
RE: Chromatic font research
> -Original Message- > From: William Overington [mailto:[EMAIL PROTECTED]] > It seems to me that various people have contributed various > good ideas as to > how chromatic fonts could be produced and applied and the way > that they > could also contain items such as text to help a speech synthesiser and > software subroutines which could be obeyed. I wonder if the > topic could now > move forward with a view to defining a format for these and any other > features so that hopefully an advanced font format which can > encompass them > all can arise. What is the correct, polite way to proceed > please? Is there > a committee that would need to be approached or what? Does > anyone know please? I nominate Tex to head this endeavor, given his insightful input to the topic. ;^P
Re: (long) Re: Chromatic font research
[I see the encoding in my response got botched -- trying again.] On 06/29/2002 08:34:44 PM "John H. Jenkins" wrote: >> OK, now I know the cha of events that he was referrg to, and I'm def >> itely cled to agree that it was complete cocidence. It is trivial, >> fact, to disprove the hypothesis that the "experiment" supposedly proved. >> >> > >Will you guys *please* stop sending me email with the Shavian letter >CHURCH everywhere the Latin letters "ct" should be? It's most distracting. > :-) John, please don't assume that I use private-use codepoints the same way someone else does without first verifying. My document contained neither a Latin ligature "ct" not Shavian letter CHURCH, but rather my most delightful LATIN LIGATURE IN WITH SWASH SERIF AND TAIL. ;-) - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
Fw: (long) Re: Chromatic font research
- Original Message - From: "Stefan Persson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 01, 2002 2:48 PM Subject: Re: (long) Re: Chromatic font research > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, June 30, 2002 6:17 PM > Subject: Re: (long) Re: Chromatic font research > > > On 06/29/2002 08:34:44 PM "John H. Jenkins" wrote: > > > > >> OK, now I know the > cha・・淏槭悶殊゜龠蒹凍・帝凾タ・瘤筐彦・粤纖ぢ・・w)松鉤肆凾タ・・竚・・繖?瘍鱚・・癆鉤樌・?竢逅跂・礪:ぢ・・竕 > 粤釿絎ヌ龠蜩鉈釿傑梵:・w)松蓊・ェ?粡齔鳫・縲跫占比肚賀?・癆縲纔鞳鱸辣銓◇齦韶闢繖踟w)頏阮繖㈲uシ暑uシ暑uシw)衝蛹譫尞・ > 苺崧ィ韭縺黼齡關寂鉗蛟・?纃瘟譫・・縲ム葹・瘤・緋肓丘シ暖孀暖肭肓医偵?・・戻・迸跂・纈・≪槇溿娯榱辮?ヌ・・迴齡w)粡齡鱇笏蜴 > 膊w)償檮ォ・u丘丘ネ闊邵ユ蛹譫尞・韭縺黼璢?竅鱚胚譫鈿龠・゜齠・・・癆・?・・閹゜矼底゜蜴w)竢粤竟蜴龠蜩縲阪?癈阪冗縲肆F > 鶤ヒ・粹笊辣銓礪殊゜蜴繖・賀跂逐゜w)齦碵・・・蒻逐ハ癆蜴・緋肓笏◇鈿髷尞・ム葹・瘤・緋肓梺g孀暖・碯龠逋w)迴齡粤悟・椁ソ塢璃 > 棉覗壞凖ヌ璃徂堡ム彖喩ム賭鋲・僧寵堊斌哺w)w)鮫・u丘丘丘ォホ續纈w)w)w) > ⑬・uホ續纈チ闔齡痰跂w)w)麗遶呰轣迸噬鱸頸ヌ鉗・癆蝟絳ム斌ヌ銓纈釶・闔瘡w)卦旭ユ・秩逅ユ蜩粹・吮・ツ瘡赱鵺メ悚卦桶喬モ啻 > >w)壹貂ゥ・昂応薫捲郡元w)鏑轣蛹込腫續纈焜闔齡痰跂栴蛹・鱧暑u丘 > > > This message becomes more readable if you display it as ISO/IEC 8859-1: > > > On 06/29/2002 08:34:44 PM "John H. Jenkins" wrote: > > >> OK, now I know the cha$B?(B of events that he was referr$B?(Bg to, > and I'm def$B?(B > >> itely $B?(Bcl$B?(Bed to agree that it was complete co$B?(Bcidence. > It is trivial, $B?(B > >> fact, to disprove the hypothesis that the "experiment" supposedly > proved. > >> > >> > > > >Will you guys *please* stop sending me email with the Shavian letter > >CHURCH everywhere the Latin letters "ct" should be? It's most > distracting. > > :-) > > > John: Will you please be careful not to assume that my use of a certain > codepoint is the same as someone else's. My document contained neither a > substitute for Latin letters "ct" nor your Shavian letter CHURCH, but my > most delightful LATIN LIGATURE IN WITH SWASH SERIFS AND TAILS. > > ;-) > > > > - Peter > > > -- - > Peter Constable > > Non-Roman Script Initiative, SIL International > 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA > Tel: +1 972 708 7485 > E-mail: <[EMAIL PROTECTED]> > > > > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
John H. Jenkins wrote: > That seems pretty clear to me. If you want a "ct" ligature in your > document because you think it "looks cool," then you use some higher-level > protocol. The "looks cool" factor simply doesn't apply unless you know > what font you're dealing with, because "ct" "looks cool" in some fonts, > but not others. It's enough that an author would want a "ct" ligature to appear in text, the motivation for the desire isn't relevant. Authors who want to specify a certain ligature know about font selection. One problem with TR28 is that it is worded so that it appears to be "in addition" to earlier guidelines. This implies that the examples used in TR27, for one, are still valid. In TR27, font developers are urged to add things like "f+ZWJ+i" to existing tables where "f+i" is already present. Another problem with TR28 is that its date is earlier than the date on TR27. This suggests that TR27 is more current. Another issue is that a search of the Unicode site for "controlling ligatures" gives TR27 as a hit, but not TR28. Having slept on this, I concur that it might be "cool" to be able to turn on or turn off ligatures over a range of text or an entire file using a higher level protocol. However, options should be preserved for the user. Ligature selection is a task for the author/typesetter at the fundamental level; it should not be completely left to the rendering system. > The programs that provide ligature control do so by means of having the > user select a range of text and then changing the level of ligation. The > type formats like OpenType or AAT support this by allowing the type > designer to categorize ligatures as "common," "rare," "required," and so > on. Thus, if I'm typesetting a document in Adobe InDesign, I'll select > text, and turn "rare" ligatures on and thus see the "ct" ligature, if it > exists in the font and if the type designer has designated it a "rare" > ligature. That's a lot of ifs and it leaves too much to chance. When an author determines that, for instance, a "ct" ligature is required, there needs to be a method to encode it which is unambiguous. ZWJ fits the bill. > To be frank, turning on an optional "ct" ligature throughout a document by > means of inserting ZWJ everywhere you want it to take place makes as much > sense in that modelthe model that Western typography uses for languages > such as Englishas having the user insert a pair around every > letter they want in italics. Not at all. This is apples and oranges. The italic tags operate upon every character in the enclosed string equally. Using a similar ligature tag would be expected to make ligatures wherever possible within the enclosed string according the the user system's ability to render ligatures... irrespective of the author's intent. Depending upon the system, the same run of text could be expressed with no ligatures at all in a monospaced font or as scripto continuo in a handwriting font. Furthermore, ZWJ doesn't require proprietary software or proprietary rich text formats which are often not exchangeable. > Remember, Unicode is aiming at encoding *plain text*. For the bulk of > Latin-based languages, ligation control is simply not a matter of *plain > text*that is, the message is still perfectly correct whether ligatures > are on or off. There are some exceptional cases. The ZWJ/ZWNJ is > available for such exceptional cases. Three cheers for plain text! But, we disagree about 'perfectly correct'. If an author is reproducing an older document in which the "ct" ligature is used, rendering the "ct" string rather than the ligature is not faithful to the source. (Even though it might be semantically equivalentit is merely approximately correct...) How about "Encyclopædia Britannica"? That's plain text enough. It's the title of a book; it isn't italic, bold, blue, or green. To cite from "Encyclopedia" or "Encyclopaedia" would be correct, but not perfectly so. Unicode provides the long "s" form, which is arguably a presentation form. Users have the option of directly encoding the long s form where it is either appropriate or desired. Trusting something like long-s-substitution to a higher protocol is not desirable because of exceptional cases like "Malmesbury" in which the final "s" is used medially. Fortunately, since the long s is a Unicode character, no one has to resort to higher protocols. Likewise for the "oe" ligature and other Latin ligatures which are directly covered by Unicode. "Onomatopoeia" and "Onomatopia" are the same in one sense, much like "font" and "fount". Yet both pairs are also different. Unicoders have the option of specifying the "oe" ligature in plain text at the fundamental level. It is suggested that the Standard be consistent with regard to Latin ligatures in this respect and preserve the use of ZWJ for this purpose. Best regards, James Kass.
Re: (long) Re: Chromatic font research
At 19:27 -0600 2002-06-29, John H. Jenkins wrote: >I must point out that for English (and a lot of other languages), >the use of ZWJ to control ligation is considered improper. The ZWJ >technique for requesting ligatures is intended to be limited to >cases where the word is spelled incorrectly if *not* ligated What! No! Look at my paper and the examples of Runic and Old Hungarian and Irish. There are examples where ligation is used on a nonce-basis, not having anything to do with global ligation or "correctness". >(and similarly ZWNJ is intended to prevent ligature formation where >that would make the word spelled incorrectly). The kind and degree >of ligation in English is generally considered a sylistic issue and >is best left to higher-level protocols. Thus saith Unicode 3.2. It doesn't go so far as to say what you did. Maybe Book needs to check the text some on this point. We should have consensus. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: (long) Re: Chromatic font research
On 06/29/2002 08:34:44 PM "John H. Jenkins" wrote: >> OK, now I know the cha$B?(B of events that he was referr$B?(Bg to, and I'm >def$B?(B >> itely $B?(Bcl$B?(Bed to agree that it was complete co$B?(Bcidence. It is >trivial, $B?(B >> fact, to disprove the hypothesis that the "experiment" supposedly proved. >> >> > >Will you guys *please* stop sending me email with the Shavian letter >CHURCH everywhere the Latin letters "ct" should be? It's most distracting. > :-) John: Will you please be careful not to assume that my use of a certain codepoint is the same as someone else's. My document contained neither a substitute for Latin letters "ct" nor your Shavian letter CHURCH, but my most delightful LATIN LIGATURE IN WITH SWASH SERIFS AND TAILS. ;-) - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Chromatic font research
William Overington wrote: > >A decorated full stop should only appear within a piece of > text marked up in some special way, e.g.: > > > > > > This is my colorful text. > > > > > >Therefore, color decoration is an issue only for *fonts* > and/or *rich* text > >systems, not for Unicode or *plain* text encoding. > > Well, why? Surely a decorated full stop could be in a plain > text file [...] It could be, yes, but it wouldn't make sense. Plain text is typically used to edit computer programs or send emails -- this kind of things. An Ethiopic programmer wishing his source code to be color-decorated would just be an eccentric guy: pretty like an European programmer wishing his source code to be set in Fraktur. > [...] What is the correct, polite way to proceed please? > Is there a committee that would need to be approached or > what? Does anyone know please? First of all, it should be recognized that the whole discussion has absolutely nothing to do with Unicode or encoding. Multicolor glyphs is a pure FONT issue. On the light of this fact, I think that this discussion should come to an end. A blatantly off-topic thread may become unbearable after nearly 100 posts, especially if it deals with an irrelevant issue such as mimicking on computers the calligraphy of ancient illuminators. To answer your question, I don't think there exists any "committee" for such issues. As far as I know, there are no standards for computer fonts: there are several competing for formats, and for each one of them there is some company, group, association, or individual who takes care of maintaining the specifications. There are electronic discussion groups dealing with some font technologies. But I wouldn't expect much attention even from such forums: color illumination is not exactly priority number one for modern font technologies. _ Marco
Re: ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
On Sunday, June 30, 2002, at 05:31 AM, James Kass wrote: > Can you please point me to a URL for Unicode 3.2 ligature control? > This link (March 2002): > http://www.unicode.org/unicode/reports/tr28/ > ...glosses over Latin ligatures suggesting that mark-up should be > used in some cases and ZWJ in others. > The precise language of the TR is: Ligatures and Latin Typography (addition) It is the task of the rendering system to select a ligature (where ligatures are possible) as part of the task of creating the most pleasing line layout. Fonts that provide more ligatures give the rendering system more options. However, defining the locations where ligatures are possible cannot be done by the rendering system, because there are many languages in which this depends not on simple letter pair context but on the meaning of the word in question. ZWJ and ZWNJ are to be used for the latter task, marking the non-regular cases where ligatures are required or prohibited. This is different from selecting a degree of ligation for stylistic reasons. Such selection is best done with style markup. See Unicode Technical Report #20, Unicode in XML and other Markup Languages for more information. That seems pretty clear to me. If you want a "ct" ligature in your document because you think it "looks cool," then you use some higher-level protocol. The "looks cool" factor simply doesn't apply unless you know what font you're dealing with, because "ct" "looks cool" in some fonts, but not others. In real Latin typography, the set of ligatures available with a typeface varies from font to font. Type designers add ligatures (or not) depending on their esthetic sense of what looks good and how the letters interact with one another. From a type design perspective, a monospaced font like Courier should have no ligatures; they don't make sense. A rich book font like Adobe Minion Pro will have a fairly large but standard set, and a calligraphic font like Linotype's Zapfino will have a huge and imaginative set. The programs that provide ligature control do so by means of having the user select a range of text and then changing the level of ligation. The type formats like OpenType or AAT support this by allowing the type designer to categorize ligatures as "common," "rare," "required," and so on. Thus, if I'm typesetting a document in Adobe InDesign, I'll select text, and turn "rare" ligatures on and thus see the "ct" ligature, if it exists in the font and if the type designer has designated it a "rare" ligature. To be frank, turning on an optional "ct" ligature throughout a document by means of inserting ZWJ everywhere you want it to take place makes as much sense in that modelthe model that Western typography uses for languages such as Englishas having the user insert a pair around every letter they want in italics. Remember, Unicode is aiming at encoding *plain text*. For the bulk of Latin-based languages, ligation control is simply not a matter of *plain text*that is, the message is still perfectly correct whether ligatures are on or off. There are some exceptional cases. The ZWJ/ZWNJ is available for such exceptional cases. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
ZWJ and Latin Ligatures (was Re: (long) Re: Chromatic font research)
John H. Jenkins wrote, > I must point out that for English (and a lot of other languages), the use > of ZWJ to control ligation is considered improper. The ZWJ technique for > requesting ligatures is intended to be limited to cases where the word is > spelled incorrectly if *not* ligated (and similarly ZWNJ is intended to > prevent ligature formation where that would make the word spelled > incorrectly). The kind and degree of ligation in English is generally > considered a sylistic issue and is best left to higher-level protocols. > Thus saith Unicode 3.2. > Sounds like a giant step backwards from Unicode 3.0.1 (March 2002) http://www.unicode.org/unicode/standard/versions/Unicode3.0.1.html (see section "Controlling Ligatures") This page clearly states that ZWJ is proper for controlling the formation of Latin ligatures and even uses f+ZWJ+i as an example. Unicode 3.1 (May 2002) uses the same examples: http://www.unicode.org/unicode/reports/tr27/index.html Can you please point me to a URL for Unicode 3.2 ligature control? This link (March 2002): http://www.unicode.org/unicode/reports/tr28/ ...glosses over Latin ligatures suggesting that mark-up should be used in some cases and ZWJ in others. Becuase of the reasons cited in that last link, IMHO ligature control is best performed by the author of a document and ZWJ still seems to be the most straightforward method. Best regards, James Kass.
Re: (long) Re: Chromatic font research
On Saturday, June 29, 2002, at 03:01 PM, [EMAIL PROTECTED] wrote: > > On 06/28/2002 11:34:35 PM "Doug Ewell" wrote: > >> OK, here are the details... > > OK, now I know the cha of events that he was referrg to, and I'm def > itely cled to agree that it was complete cocidence. It is trivial, > fact, to disprove the hypothesis that the "experiment" supposedly proved. > > Will you guys *please* stop sending me email with the Shavian letter CHURCH everywhere the Latin letters "ct" should be? It's most distracting. :-) == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: (long) Re: Chromatic font research
Hmm. Disregard the last message from me. It isn't "ct" you're replacing. See how annoying this all is? :-) == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: (long) Re: Chromatic font research
On Saturday, June 29, 2002, at 06:41 AM, James Kass wrote: > > This is a display issue rather than an encoding one. Unicode already > provides for the correct encoding of the "ct" ligature with the > ZWJ "character". Anyone wishing to correctly display the "ct" > ligature might need to use a "work-around". Substituting PUA code > points by private agreement is one workable method. I must point out that for English (and a lot of other languages), the use of ZWJ to control ligation is considered improper. The ZWJ technique for requesting ligatures is intended to be limited to cases where the word is spelled incorrectly if *not* ligated (and similarly ZWNJ is intended to prevent ligature formation where that would make the word spelled incorrectly). The kind and degree of ligation in English is generally considered a sylistic issue and is best left to higher-level protocols. Thus saith Unicode 3.2. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: Chromatic font research
At 11:05 +0100 2002-06-29, William Overington wrote: > >Therefore, color decoration is an issue only for *fonts* and/or *rich* text > >systems, not for Unicode or *plain* text encoding. > >Well, why? Surely a decorated full stop could be in a plain text file being >displayed in a program which has a background colour of white, a foreground >colour of black and a decoration colour of red set as the colours in which >the program works. Because the underlying text encoded is the same, "This is my colourful text" whether it is formatted in red, in italic, or in some special font. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: (long) Re: Chromatic font research
On 06/29/2002 04:47:17 AM "William Overington" wrote: >This use of two routes to the same glyph in an OpenType font, one newer >method together with one older method, seems to me to be a development, >which James Kass thought of, I can assure you, the idea did not originate with James Kass, and the concensus of the professional font development has, on the whole, been that that very practice needs to be *abandoned* . >My point in citing The Respectfully Experiment in the recent post is that >even though the reasons for not including any more ligatures in Unicode may >have seemed totally reasonable at the time that that decision was made, the >idea of James Kass that the glyphs for ligatures in an OpenType font could >also be accessed directly does add new evidence to the situation. It is not new evidence, and the decision *not* to directly encode any further ligatures was made with a very thorough awareness that what James did was possible (and has been used in some commercially available fonts). > In the >light of this new evidence, I am wondering whether the decision not to >encode any new ligatures in regular Unicode could possibly be looked at >again. Given the absense of any new evidence, I think it will not be. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
Re: (long) Re: Chromatic font research
On 06/28/2002 11:34:35 PM "Doug Ewell" wrote: > OK, here are the details... OK, now I know the cha$B?(B of events that he was referr$B?(Bg to, and I'm def$B?(B itely $B?(Bcl$B?(Bed to agree that it was a complete co$B?(Bcidence. It is trivial, $B?(B fact, to disprove the hypothesis that the "experiment" supposedly proved. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
Re: (long) Re: Chromatic font research
On 06/28/2002 11:34:35 PM "Doug Ewell" wrote: > OK, here are the details... OK, now I know the cha of events that he was referrg to, and I'm def itely cled to agree that it was complete cocidence. It is trivial, fact, to disprove the hypothesis that the "experiment" supposedly proved. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
Re: (long) Re: Chromatic font research
William Overington wrote: > This post makes the scientific > situation quite clear Several others have taken you to task for using English words with your own private meaning, rather than a generally accepted meaning that can be shared by all on the list. "Science" is one of those words. Science is the activity of finding out things that aren't already known. It involves hypotheses that can be tested by experimentation or observation. Your conclusions about ligatures are completely predictable from knowledge of the way that fonts work. No experiment was necessary, just as it is unnecessary to count stones to establish that four plus three equals seven. -- Curtis Clark http://www.csupomona.edu/~jcclark/ Mockingbird Font Works http://www.mockfont.com/
Re: (long) Re: Chromatic font research
- Original Message - From: "Doug Ewell" <[EMAIL PROTECTED]> To: "William Overington" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, June 29, 2002 5:20 PM Subject: Re: (long) Re: Chromatic font research > This isn't limited to ligatures, either. Font designers also regularly > include a glyph for U+00E1 LATIN SMALL LETTER A WITH ACUTE. You can > either encode U+00E1 directly and see the glyph, or you can encode > U+0061 U+0301 (a ´) and get the same glyph. This doesn't even require > OpenType, just non-spacing glyphs. This does require the use of OpenType since the accent should be placed at different places for different characters. Stefan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: (long) Re: Chromatic font research
William Overington wrote: > My point in citing The Respectfully Experiment in the recent post is > that even though the reasons for not including any more ligatures in > Unicode may have seemed totally reasonable at the time that that > decision was made, the idea of James Kass that the glyphs for > ligatures in an OpenType font could also be accessed directly does > add new evidence to the situation. In the light of this new evidence, > I am wondering whether the decision not to encode any new ligatures > in regular Unicode could possibly be looked at again. So the "new evidence" is that a precomposed glyph can be used both (a) directly, to render a single Unicode code point, and (b) indirectly, to render a combining sequence? There's nothing new there, William. Font designers regularly include a glyph for U+FB01 LATIN SMALL LIGATURE FI. It has always been known, and obvious, that a user could access this glyph directly by encoding U+FB01. With the advent of OpenType and a smart-enough rendering system, the user could alternatively encode the sequence U+0066 U+200D U+0069 (f ZWJ i) and get the same glyph. (Or, as John Jenkins points out, if you have a Mac you can see this glyph simply by encoding "fi," without the need for the ZWJ hint.) This isn't limited to ligatures, either. Font designers also regularly include a glyph for U+00E1 LATIN SMALL LETTER A WITH ACUTE. You can either encode U+00E1 directly and see the glyph, or you can encode U+0061 U+0301 (a ´) and get the same glyph. This doesn't even require OpenType, just non-spacing glyphs. What is so different about doing this with a ct ligature, encoded provisionally in the PUA, compared to doing it with the fi ligature or the a-with-acute that have been in Unicode at least since version 1.1? Where is the new scientific discovery? > My intended meaning was that both types of ligation (precomposed and > ZWJ) could be in the same font. Of course they can. > Also, it is not a matter of overturning a decision, it is a matter of > the decision being modified in the light of the new evidence, namely > that both methods may be used simultaneously in an OpenType font. Without worrying about the distinction between "overturning" and "modifying" a decision, the fact remains that there is nothing new about this "new evidence." Every OpenType font designer knows it. -Doug Ewell Fullerton, California
Re: (long) Re: Chromatic font research
Doug Ewell wrote, > ... > On 2002-05-31, I wrote a response which ended "Respectfully, Doug," > except that I used William's code point U+E707 in place of the letters > "ct." My intent was that everyone on the Unicode list, including > William, would see "Respefully," thus demonstrating the lack > of interoperability of this PUA solution. Only users of a font that > happened to contain William's PUA character would see the ct ligature, > and I didn't think any such font existed. > > Much to my surprise, however, James Kass had modified his private > version of the Code2000 font to include William's ct ligature at U+E707, > and he was using it to read my message, so oiut of everyone on the list, > he alone did see the ligature. > Sitting atop a rugged mountain peak in an isolated cabin during late March after having just reclaimed this computer from a distant storage facility, an effort was made to catch up on the hundreds of e-mails which were sent during the off-line time. One of the threads on this list concerned Latin ligatures. Casting about for something constructive to do, working on Latin ligatures struck my fancy. Several such ligatures were drawn and added to the working version of Code2000. The OpenType table generator and databases were tweaked to accomodate these new features. These ligatures weren't assigned to code points. With OpenType and "smart" font technology, code points for presentation forms aren't required. ...unless someone wants to display them. This system supports OpenType substitution for many scripts like Bengali, Tamil, Devanagari, and so forth. But, OpenType support for the Latin script is not yet enabled. Time passed and William Overington published the Golden Ligatures set. It only took a moment to assign existing ligatures in the font to these unofficial code points, so I did it. > William observed that I had sent, and James had received, a ct ligature > at U+E707, based not on any private arrangement but on our mutual (and > coincidental) use of William's code point. He latched onto this chain > of events as proof that end-user publication of PUA code points was a > success, and named it "The Respectfully Experiment," despite my protests > that the whole incident was a freak accident. (I think "ct" was the > only one of William's "golden" ligatures for which James had provided a > Code2000 glyph.) > Also "fj" and "ffj". IIRC, the balance of the ligatures in The Golden Ligatures would be best suited for specialty fonts, like Fraktur. This is a display issue rather than an encoding one. Unicode already provides for the correct encoding of the "ct" ligature with the ZWJ "character". Anyone wishing to correctly display the "ct" ligature might need to use a "work-around". Substituting PUA code points by private agreement is one workable method. Right now, if someone sent me a file with c+ZWJ+t, the easiest way that it could be displayed on this system would be to open the file in a plain text editor and globally replace all instances of c+ZWJ+t with U+E707 and then open the altered file in an appropriate application with the desired font active. This is one way in which PUA code points can be used in conjunction with the ZWJ mark-up. Best regards, James Kass.
Re: (long) Re: Chromatic font research
> OK, here are the details. I'm reluctant to admit having been >part of this "experiment," since it is now being presented as evidence >to support the proliferation of private-use ligatures. Actually, no. What I am seeking to use it as evidence for is the addition of ligatures such as ct to the U+FB.. block of regular Unicode. In the recent post I used it as evidence that ideas about what should not be included in Unicode can change over a period of time as new scientific evidence is discovered. My point in citing The Respectfully Experiment being that in an OpenType font, which is the type of font which James Kass was using, the ct glyph is accessible by c ZWJ t yet is not accessible directly using regular Unicode. Adding U+FB07 as a ct ligature would mean that an OpenType font would still normally use c ZWJ t to access the ct glyph, yet people with older equipment, or some older software, could also access the same glyph directly as U+FB07. This use of two routes to the same glyph in an OpenType font, one newer method together with one older method, seems to me to be a development, which James Kass thought of, which would potentially be of benefit to end users as it would mean that ligature glyphs provided in OpenType fonts could be accessed by users of older equipment as well as by users of newer equipment. Certainly it would not be leading edge use of technology for document storage, yet it could be useful for people wishing to print stylish pages of text locally or to prepare document transcriptions using older equipment which transcriptions could then be sent or taken somewhere and processed into the newer ZWJ style format. For example, suppose a team of people working using open access computers in a library is transcribing various old books using the older software on those older computers. Once the files are on a floppy disc they can be taken or sent to a more modern computer and the files converted to using a ZWJ format for ligatures, before the files are added into the database of files of transcriptions. Bearing in mind the way that research projects often have to get by as best they can with the equipment that is already there, it just seems to me that some extra ligature characters in the U+FB.. block would be useful. Now, certainly this effect can be produced now using the Private Use Area code points which I have suggested, as James Kass has demonstrated, yet I feel that it would be better if it could be done with regular Unicode code points. My point in citing The Respectfully Experiment in the recent post is that even though the reasons for not including any more ligatures in Unicode may have seemed totally reasonable at the time that that decision was made, the idea of James Kass that the glyphs for ligatures in an OpenType font could also be accessed directly does add new evidence to the situation. In the light of this new evidence, I am wondering whether the decision not to encode any new ligatures in regular Unicode could possibly be looked at again. Now, I do not regard this adding of ligatures as a major issue. Certainly I would like it to happen if it can be done as a fairly straightforward exercise without any great problems or taking up of great amounts of committee time, yet if it cannot be done or would cause great anguish and arguments, well, that is that, forget it. >I don't think William really meant "in conjunction with" in the sense >that ZWJ would be applied directly to precomposed ligatures. He meant >in the same document, or maybe not even that, maybe just that both types >of ligation (precomposed and ZWJ) would be conformant to Unicode. My intended meaning was that both types of ligation (precomposed and ZWJ) could be in the same font. >Nothing about "The Respectfully Experiment" -- and no appeals that users >of 80386 PCs must be able to reproduce 18th-century ligatures in plain >text -- will serve as the "evidence" that William is waiting for to >overturn the decision not to encode any more precomposed ligatures. Well, it is for far more recent machines than for 80386 PCs, such as for many Pentium based machines running Windows 95 and Windows 98. Also, it is not a matter of overturning a decision, it is a matter of the decision being modified in the light of the new evidence, namely that both methods may be used simultaneously in an OpenType font. And I am not waiting for this to happen. This post makes the scientific situation quite clear and if the committee chooses to encode some more ligatures in the U+FB.. block then that is great, but it is not an event for which I am waiting. Unless any other aspect arises, such as a need for some more ligatures or some more ligatures being added into regular Unicode, I have no intention of either adding to, changing or deleting the code point documents for ligatures that are currently available in our family webspace. http://www.users.globalnet.co.uk/~ngo/golden.htm I produced the lists during a peri
Re: Chromatic font research
Marco Cimarosti wrote as follows. >William Overington wrote: >> The occurrence of red words raises an interesting aspect of >> this discussion in that a chromatic font would be needed >> for the full stop character when decorated [...] > >A chromatic font in *conjunction* with markup, of course. Well, actually, I was thinking of a chromatic font in use with a plain text file, but chromatic fonts could be used with either plain text or markup as desired. >You are talking abut *decorative* color, and there is no need to have any >decorative elements in *plain* text, if I understand the meaning of the >English adjective "plain". Well, yes, plain can mean undecorated in English, yet I was using the word plain in the sense of a file containing just Unicode characters having the meanings in the Unicode code charts, as contrasted with a file that contains markup or fancy text of some manufacturer's proprietary file format where some of the codes are assigned meanings specific to that markup or fancy text system which meanings are not included in the Unicode code charts. So, in the sense in which I used the word plain in the phrase plain text I was intending to convey the notion of a sequence of code points where the only meanings are those in the Unicode specification, so, for the Ethiopic full stop it would be in a plain text file and would also be decorated. >A decorated full stop should only appear within a piece of text marked up in >some special way, e.g.: > > > This is my colorful text. > > >Therefore, color decoration is an issue only for *fonts* and/or *rich* text >systems, not for Unicode or *plain* text encoding. Well, why? Surely a decorated full stop could be in a plain text file being displayed in a program which has a background colour of white, a foreground colour of black and a decoration colour of red set as the colours in which the program works. Certainly for the Ethiopic text the colours are always white, black and red and the matter may be more complicated for lettering and symbols of a general nature. Yet I feel that a presumtion that markup is obligatory is not necessary. The colours need to be decided in some way. Those ways could be markup; or setting of colours by the end user pushing buttons to alter the default colours of the program displaying the file; or by the font offering guidance as to the colours to use; or some interacting combination of those methods. It seems to me that various people have contributed various good ideas as to how chromatic fonts could be produced and applied and the way that they could also contain items such as text to help a speech synthesiser and software subroutines which could be obeyed. I wonder if the topic could now move forward with a view to defining a format for these and any other features so that hopefully an advanced font format which can encompass them all can arise. What is the correct, polite way to proceed please? Is there a committee that would need to be approached or what? Does anyone know please? William Overington 29 June 2002
(long) Re: Chromatic font research
William Overington wrote: > For example, a recent experiment, documented > in the archives of this list as The Respectfully Experiment, shows > that there is now new evidence about the facts regarding the encoding > of code points for ligatures... and responded: > Also, I don't recall posts from this list detailing the experiment > referred to above, which admittedly leaves me at a disadvantage. OK, here are the details. I'm reluctant to admit having been part of this "experiment," since it is now being presented as evidence to support the proliferation of private-use ligatures. But anyway: In late May, William began suggesting that code points in the Private Use Area be assigned to Latin ligatures, so that they could be represented in plain text without the use of smart fonts, ZWJ sequences, etc., which he claims are only available to users of "the very latest" hardware and software. In particular, William proposed the PUA code point U+E707 for the Latin "ct" ligature, and that particular ligature was used as an example throughout the thread. On 2002-05-31, I wrote a response which ended "Respectfully, Doug," except that I used William's code point U+E707 in place of the letters "ct." My intent was that everyone on the Unicode list, including William, would see "Respefully," thus demonstrating the lack of interoperability of this PUA solution. Only users of a font that happened to contain William's PUA character would see the ct ligature, and I didn't think any such font existed. Much to my surprise, however, James Kass had modified his private version of the Code2000 font to include William's ct ligature at U+E707, and he was using it to read my message, so oiut of everyone on the list, he alone did see the ligature. William observed that I had sent, and James had received, a ct ligature at U+E707, based not on any private arrangement but on our mutual (and coincidental) use of William's code point. He latched onto this chain of events as proof that end-user publication of PUA code points was a success, and named it "The Respectfully Experiment," despite my protests that the whole incident was a freak accident. (I think "ct" was the only one of William's "golden" ligatures for which James had provided a Code2000 glyph.) William continued: > ... because it has now been realized that > such code points can now be used in conjunction with ZWJ type > mechanisms of advanced font technology formats as an alternative > method of coding to assist people with less than the latest equipment, > such code points for ligatures working in conjunction with advanced > font technology rather than as an alternative to it which is the way > that such code points were regarded when a decision not to encode any > more of them without a strong case was taken, though even for that > decision there was provision for the general thrust of that decision > to be overridden in the light of future evidence. and Peter replied: > ... my knowledge of the Unicode standard and of advanced font > technologies leaves me rather puzzled about how "...code points [for > ligatures] can now be used in conjunction with ZWJ type mechanisms > of advanced font technology...": codepoints for ligatures are > unnecessary because of advanced font technologies. ZWJ does not work > in conjunction with encoded ligatures because encoded ligatures > aren't needed; and if they existed, ZWJ would not particularly > interact with them in any usage that has been described as part of > the Unicode standard. I don't think William really meant "in conjunction with" in the sense that ZWJ would be applied directly to precomposed ligatures. He meant in the same document, or maybe not even that, maybe just that both types of ligation (precomposed and ZWJ) would be conformant to Unicode. There is no new revelation here, though. Nothing "has now been realized" that wasn't already known. Because of the Latin compatibility ligatures already encoded from U+FB00 through U+FB06, it has always been possible to encode (say) an "fi" ligature using either the ZWJ method or the precomposed ligature at U+FB01, or both according to whimsy. (Or it might just magically appear without any special encoding at all, as John Jenkins could point out.) It makes no difference whether a PUA code point or a standardized Unicode code point is used for the precomposed ligature. Nothing about "The Respectfully Experiment" -- and no appeals that users of 80386 PCs must be able to reproduce 18th-century ligatures in plain text -- will serve as the "evidence" that William is waiting for to overturn the decision not to encode any more precomposed ligatures. > There is at present a barrier, which I feel might be called the markup > barrier, which is acting as a barrier to progress. This is not a barrier; it's just a distinction. People who are VERY familiar with the issues have drawn a line between: (a) plain text, which represents content, and (b) markup, which repr
Re: Chromatic font research
> In the handwritten form, could you please say whether the adding of the red > increases the width of the area needed to represent the character? yes, absolutely, at least by the width of two dots. > Also, when handwritten, does the scribe have a black pen in one hand and a > red pen in the other so that colouring takes place on a character by > character basis as writing proceeds, or does the scribe put down one pen and > pick up another, and, if so, is that on a character by character basis or is > that on the basis of producing a number of characters in black and then > adding the red afterwards. This would seem to be possibly significant due > to the possible need to allow for the greater width of the area used for a > character that is later to receive red flourishes. my oh my, these are wonderfully interesting questions :) I would think the use of tools would be highly sensitive to the experience, training, and learned habits of the writer. I haven't witnessed a great enough number to sensibly say what a norm would be. I certainly haven't seen a person hold two pens at once though. The scribes I've seen (maybe 4 I watched closely) were pragmatic in their writing, when a red word occurred they would put down the black brush and pick up the red and write the word. While the utensil was still in hand they would go back and add red dots or strokes where they thought it was needed. If no red words occurred (usually one every sentence or two depending upon the material) they would continue writing in black until the end of a sentence or section and stop there to change pens to go back and update punctuation or tonal marks. Again, I wouldn't draw any significant conclusions from this. I don't believe extra space is considered for adding red marks later, the red is allowed to bleed over the black. Trying to reproduce the practice with fonts though I have used an enlarged version of 1362 because the result looked much clearer. The original intention was lost when keeping the original proportions. My thought at the time was that it was just a natural adjustment that one makes when going from ink and paper to computer typography, the goal being that we try to improve upon what the hand can do without losing the essence of it. /Daniel
Re: Chromatic font research
Sampo Syreeni recently said: > National flags are a far cry, true. Naval signalling ones perhaps aren't. > They stand for characters and I believe in some variations for entire > well-known concepts. They are utilized in a way we would expect characters > to be. I don't think the entire collection of flags used around the world > coincides neatly enough with an already encoded script to be considered > pure glyph variants. And colors are certainly meaningful in this context. > > (I can't fathom why anyone would want to encode those, though. Anything > you can do with flags you can do with ordinary characters, only more > efficiently. However, this could serve as an example of a script which > relies on color as an essential feature.) I'd agree that you wouldn't want to encode them, but you might want to make a font where each signaling flag is in the place of its corresponding character. That would be a use for chromatic fonts. The only other use that springs to mind is Egyptian hieroglyphics which have a colouring scheme when written in full colour. (Of course colour isn't *required* when reading them, it is just an aid that helps recognition.) As someone (Doug?) pointed out a little while back on another thread, fonts are (mis)used to hold collections of graphics conveniently. I imagine that if chromatic fonts were available this kind of usage would grow. It would also allow things like illuminated capitals to be put in a font rather than suplied as a collection of graphics files. Tim -- Tim Partridge. Any opinions expressed are mine only and not those of my employer
RE: UniCharacter (Re: Codes for codes for codes for... (RE: Chromatic font research))
Folks, WAIT A BIT. This method, as tempting as it is, would make all text "not accessible" for people with visual disabilities. And, as you all know, Section 508 requires that any electronic information from the government (e.g. web site) must be accessible to people with disabilities. Here goes a great idea unless we find an accessible way to "display" colors for the blind ! Assistive Technologies companies - here is your challenge !!! Arnold > -Original Message- > From: Rick McGowan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 1:12 PM > To: [EMAIL PROTECTED] > Subject: Re: UniCharacter (Re: Codes for codes for codes for... (RE: > Chromatic font research)) > > > Tex wrote: > > > Lends a whole new meaning to unification! The single > character encoding, > > UniCharacter!. Just color what you need. > > Yeah! I like Tex's suggestion. It would eliminate all kinds > of problems. > We wouldn't have to worry about encoding anything ever again, > because users > would have all the tools they need to express whatever they > wanted just by > coloring in the bits! And nobody would have any problems decoding it! > > The only question that remains is, "how much resolution is > enough"? I > think if we have 512x512 bytes for 256x256 resolution at > 16-bits/pixel for > color, that ought to be enough resolution to satisfy anyone. So each > character would only require 2,097,152 bits. With all the > fancy compression > schemes we could cook up, that shouldn't pose any difficulty > at all. And > it really ought to appeal to the RAM manufacturers... > > Speaking of compression schemes, we could pick a space of say > 32 bits and > allow people to register the characters they like by NUMBER > (!), and we > could keep a whole technical committee engrossed for decades > in deciding > which proposed pictures were really the same and thus have > "already been > registered", and numbering things, then we could transmit > information > compactly by using the catalog numbers instead of the > pictures. That might > be helpful to users, I'm not sure... > > Rick > > >
RE: Codes for codes for codes for... (RE: Chromatic font research)
Stefan Persson wrote: > I see. How do I propose millions of Unicode code points for > inclusion in the stantard? ;-) Just put them in the PUA, publish them, and wait: sooner or later, they'll get promoted. ;-} _ Marco
Re: UniCharacter (Re: Codes for codes for codes for... (RE: Chromatic font research))
Good point about resolution. I just realized an even bigger problem- steganography. Embedding data in pictures. By changing the colors associated with a character string, someone could spell out a completely different message. My "Hello world" could be changed to "Bite me". It might not even be intentional, could be just a bad color gun in a monitor. Although, it would certainly be an aid to translation, (one set of message strings fits all!) there is too much of a security risk. Never mind. ;-) (Maybe the heat is getting to me.) Rick McGowan wrote: > > Tex wrote: > > > Lends a whole new meaning to unification! The single character encoding, > > UniCharacter!. Just color what you need. > > Yeah! I like Tex's suggestion. It would eliminate all kinds of problems. > We wouldn't have to worry about encoding anything ever again, because users > would have all the tools they need to express whatever they wanted just by > coloring in the bits! And nobody would have any problems decoding it! > > The only question that remains is, "how much resolution is enough"? I > think if we have 512x512 bytes for 256x256 resolution at 16-bits/pixel for > color, that ought to be enough resolution to satisfy anyone. So each > character would only require 2,097,152 bits. With all the fancy compression > schemes we could cook up, that shouldn't pose any difficulty at all. And > it really ought to appeal to the RAM manufacturers... > > Speaking of compression schemes, we could pick a space of say 32 bits and > allow people to register the characters they like by NUMBER (!), and we > could keep a whole technical committee engrossed for decades in deciding > which proposed pictures were really the same and thus have "already been > registered", and numbering things, then we could transmit information > compactly by using the catalog numbers instead of the pictures. That might > be helpful to users, I'm not sure... > > Rick -- - Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] Xen Master http://www.i18nGuy.com XenCrafthttp://www.XenCraft.com Making e-Business Work Around the World -
RE: Codes for codes for codes for... (RE: Chromatic font research)
Doug Ewell wrote: > I think the reason the Braille block is legitimate, and doesn't fall > into the codes-for-codes trap you described, is that it is a flexible > cipher rather than a fixed one. The same Braille symbol can stand for > different letters depending on which script, or even which alphabet > within the same script, it is used to represent. And then > there's Grade > 2 Braille, which completely breaks the "simple cipher" model. I stand corrected. _ Marco
RE: Chromatic font research
> -Original Message- > From: William Overington [mailto:[EMAIL PROTECTED]] > It would seem that it would be entirely within the letter and > the spirit of > that definition to use code points in regular Unicode to > denote all manner > of items for human and computer communication. Given the frequency that these types of issues come up, I wonder if it would be useful to list a few examples in the FAQ of what would -not- be considered for inclusion in future releases of the standard? For example, I'm guessing that my idea for encoding furniture icons and room positioning indicators so that I could create floor layouts using a text editor, would probably not be accepted. (No doubt because corporate giants are trying to prevent the incredible financial success I would realize if they allowed it.) Perhaps if there were a few (more?) places on the site which explained what Unicode is NOT, it would be easier for people to realize they should build an app to accomplish their goal instead. Examples of innappropriate submissions and explanations of why might help reduce the problem. (Apologies if such a thing does exist on the site... my poking around in the FAQ and the "Submitting Proposals" page didn't find it.) Suzanne Topping BizWonk Inc. [EMAIL PROTECTED]
Re: UniCharacter (Re: Codes for codes for codes for... (RE: Chromatic font research))
Tex wrote: > Lends a whole new meaning to unification! The single character encoding, > UniCharacter!. Just color what you need. Yeah! I like Tex's suggestion. It would eliminate all kinds of problems. We wouldn't have to worry about encoding anything ever again, because users would have all the tools they need to express whatever they wanted just by coloring in the bits! And nobody would have any problems decoding it! The only question that remains is, "how much resolution is enough"? I think if we have 512x512 bytes for 256x256 resolution at 16-bits/pixel for color, that ought to be enough resolution to satisfy anyone. So each character would only require 2,097,152 bits. With all the fancy compression schemes we could cook up, that shouldn't pose any difficulty at all. And it really ought to appeal to the RAM manufacturers... Speaking of compression schemes, we could pick a space of say 32 bits and allow people to register the characters they like by NUMBER (!), and we could keep a whole technical committee engrossed for decades in deciding which proposed pictures were really the same and thus have "already been registered", and numbering things, then we could transmit information compactly by using the catalog numbers instead of the pictures. That might be helpful to users, I'm not sure... Rick
Re: Codes for codes for codes for... (RE: Chromatic font research)
- Original Message - From: "Marco Cimarosti" <[EMAIL PROTECTED]> To: "'Stefan Persson'" <[EMAIL PROTECTED]>; "'Sampo Syreeni'" <[EMAIL PROTECTED]>; "Kenneth Whistler" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, June 27, 2002 1:58 PM Subject: Codes for codes for codes for... (RE: Chromatic font research) > Stefan Persson wrote: > > From: "Marco Cimarosti" <[EMAIL PROTECTED]> > > > Or 127 ASCII code points? > > > Or ca. 9000 JIS code points? > > > > They are already encoded, aren't they? > > No, they aren't. Unicode encodes the same characters encoded by ASCII (at > the same code points) and the same characters encoded by JIS (at different > code points), but it does NOT(*) include the ASCII or JIS code points > themselves. That would be like assigning a code to represent a code which > represents a character. > > (*: Actually, 33 ASCII code points are encoded in range U+2400..U+2422, to > allow visible symbols for ASCII control codes). I see. How do I propose millions of Unicode code points for inclusion in the stantard? ;-) Stefan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
UniCharacter (Re: Codes for codes for codes for... (RE: Chromatic font research))
Interestingly, once you have chromatic capabilities, you can encode
Braille as a single character with all dots, and apply coloring, to each
dot as needed, of the background color to eliminate dots, and foreground
color(s) to present them, to make all 256 combinations.
For that matter, you can encode worst-case-composed characters (a base
letter plus all possible combining characters) as single characters and
then apply background/foreground coloring to eliminate the marks you
don't want, even reducing to just the base character.
Hmm. Actually you can include all the possible base characters into one
character as well, and only color the one you want.
Lends a whole new meaning to unification! The single character encoding,
UniCharacter!. Just color what you need.
OK, who's with me in forming a consortium! I gotta call Crayola.
;-)
Doug Ewell wrote:
>
> Marco Cimarosti wrote:
>
> > But such a thing actually has a precedent: the Braille block. But
> > this had a (faint!) justification: those Braille patterns are not
> > used to "encode Braille in Unicode", but rather to encode commands
> > to be sent to Braille printers ("embossers", actually).
--
-
Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED]
Xen Master http://www.i18nGuy.com
XenCrafthttp://www.XenCraft.com
Making e-Business Work Around the World
-
Re: Codes for codes for codes for... (RE: Chromatic font research)
Doug Ewell scripsit: > And then there's Grade > 2 Braille, which completely breaks the "simple cipher" model. Not really: it is just enciphered code. Similarly, in the flag code we can encode the phrase "I require a pilot" as G, or "I am in distress" as "NC", and then encipher these (one-to-one) using the flags for those letters. The code "G", BTW, also represents "I am hauling nets". Again, this is like encoding "Abandon all claims" as "ABALC", and then enciphering this using International Morse or Baudot, as was done in cable days. The reason for Unicoding Braille was practical, not theoretical. -- John Cowan <[EMAIL PROTECTED]> http://www.reutershealth.com I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
Re: Codes for codes for codes for... (RE: Chromatic font research)
Marco Cimarosti wrote:
> But such a thing actually has a precedent: the Braille block. But
> this had a (faint!) justification: those Braille patterns are not
> used to "encode Braille in Unicode", but rather to encode commands
> to be sent to Braille printers ("embossers", actually).
I think the reason the Braille block is legitimate, and doesn't fall
into the codes-for-codes trap you described, is that it is a flexible
cipher rather than a fixed one. The same Braille symbol can stand for
different letters depending on which script, or even which alphabet
within the same script, it is used to represent. And then there's Grade
2 Braille, which completely breaks the "simple cipher" model.
-Doug Ewell
Fullerton, California
Re: Chromatic font research
On 06/27/2002 01:57:01 AM "William Overington" wrote: >It would seem that it would be entirely within the letter and the spirit of >that definition to use code points in regular Unicode to denote all manner >of items for human and computer communication. It may so seem to you, but this definitely is *not* in the spirit of that definition. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Chromatic font research
I (Marco Cimarosti) wrote:
> Michael Everson wrote:
> > Marco said:
> >
> > >MC> However, the Aztec script uses color has a structural element:
> > >MC> signs with the same design can mean different things if
> > painted in
> > >MC> different colors.
> >
> > Has it? Reference?
>
> The best I can come up with from my private library is a
> single paragraph on
> a book about the history of writing in general ("Storia
> universale della
> scrittura" by Giorgio R. Cardona, Arnoldo Mondadori Editore,
> Milano 1986,
> chapter XII "Le scritture del continente americano", 2 "Le scritture
> mesoamericane", "Area azteca e olmeca", page 257):
I noticed only now that this book also has a specific chapter about color
(II-VII "La scrittura colorata", pages 85-87). The chapter refers how color
was and is applied to writing by different cultures. Most of these usages
involve coloring whole glyphs or the background: what we moderns would call
"markup".
However, at the very end of the chapter, the author deals again with
Meso-American writing system, stating more clearly that color was a
structural element, which could even form minimal pairs:
"L'uso più cospicuo del simbolismo dei colori in un sistema grafico
è dato dai manoscritti mesoamericani; le figurazioni e i glifi hanno le
varie parti colorate con colori precisi, legati a un simbolismo che in parte
conosciamo e che rimanda al pantheon delle divinità, alla divisione dello
spazio, agli elementi componenti del cosmo. Anche le rappresentazioni a
bassorilievo erano in realtà colorate, benché [ciò] si possa ricostruire
solo congetturalmente. Questi colori erano decifrati esattamente come
qualsiasi [altra] componente della scrittura, e in certi casi il colore è
l'unico determinante in glifi per il resto uguali."
(my translation: "The most important use of color symbolism in a
graphical system is found in the Meso-American manuscripts; the pictures and
the glyphs have their various parts colored with well-defined colors, bound
to a symbolism that we know in part, and which refers to the deities
pantheon, to the subdivision of space, to the elements composing the world.
Actually, also the bass-relief representation were colored, although [this]
can only be reconstructed by guesswork. These colors were deciphered exactly
like any [other] component of the writing system, and in some cases color
was the only difference {determinant} in glyphs otherwise identical."
_ Marco
Codes for codes for codes for... (RE: Chromatic font research)
Stefan Persson wrote:
> From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> > Or 127 ASCII code points?
> > Or ca. 9000 JIS code points?
>
> They are already encoded, aren't they?
No, they aren't. Unicode encodes the same characters encoded by ASCII (at
the same code points) and the same characters encoded by JIS (at different
code points), but it does NOT(*) include the ASCII or JIS code points
themselves. That would be like assigning a code to represent a code which
represents a character.
(*: Actually, 33 ASCII code points are encoded in range U+2400..U+2422, to
allow visible symbols for ASCII control codes).
Encoding the navy's flag alphabet or the Morse code would be exactly doing
this: assigning a code to a code which represents a letter.
But such a thing actually has a precedent: the Braille block. But this had a
(faint!) justification: those Braille patterns are not used to "encode
Braille in Unicode", but rather to encode commands to be sent to Braille
printers ("embossers", actually).
_ Marco
Re: Chromatic font research
On Wed, 26 Jun 2002 [EMAIL PROTECTED] wrote: >Sure, pictures have colour, but pictures are not characters. Not even >pictures of things that represent characters. Depends on what you consider a character. In my inexpert opinion, any sign which can be used in a way reminiscent of a character (i.e. can be used to encode an abstract concept, is used as a part of a wider, orderly system of similar signs to encode information, and so on) *is* a character. I mean, if it walks like a duck... The fact that people didn't happen to have photographically accurate megacolor printers when they first came up with the idea of writing is a historical detail which I cannot see having anything to do with the definition of a "character", per se. >We could invent a system that uses 4 x 4 matrices of squares each in one >of 16 colours with each configuration representing a different character >from a repertoire of up to 256 characters. Should these representations >of characters be themselves encoded as characters? No, IMO. I'm not quite sure about this, either. Precisely such a scheme is currently used to encode certain high capacity 2D barcodes. IMO, what we're dealing with, here, are indeed characters. Much like the many purely technical symbols already encoded, Braille, Dingbats, bullets and certain other kinds of punctuation, arrows, control pictures, character recognition and block drawing symbols, block elements, geometric shapes, the non-Han symbols used in CJK text, musical symbols and tags. In fact, many of those seem far less like characters than discrete barcode symbols used to encode alphanumeric information -- many of the symbols already encoded are not used as part of an orderly writing system, at all, but in isolation. I think what counts is use in interchange. If there is a wide-spread need to interchange data containing a specific symbol it should be standardized and encoded in Unicode regardless of its genesis or similarity to older, more conventional characters. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Re: Chromatic font research
On Wed, 26 Jun 2002, John Cowan wrote: >I looked at the image (less than ideal) at >http://www.fortknoxxjewelry.com/store/myname/images/1177_l.jpg and fed >it through the Gimp to strip out color information (specifically, >Image/Colors/Desaturate followed by Image/Colors/Threshold, taking the >127 default, which leaves stark black and white). The point was, there are a lot more. You can start with http://members.shaw.ca/quadibloc/other/flaint.htm . And that is only for the international flags. There are lots of national and proprietary ones, too, if I'm not entirely mistaken. Unify the whole set and you'll end up with a number of distinct symbols with no difference besides color. >In any event, this is plainly a letter-by-letter cipher for the basic >Latin alphabet (A-Z), and the fact that single letters or combinations >may be used as codes for cross-linguistic concepts is of no more >interest to a character encoding standard than that "ABALC" can mean >"Abandon all claims" in any of various natural languages. To a degree, yes. But the line is hardly clear-cut. By the same token, we might as well deprecate many of the alphabets in Unicode as they can be considered a cipher of IPA. The point is, a widely used cipher does constitute a new alphabet. (We might get back into the Klingon debate, here. I'd rather refrain.) Again, I'm not saying signalling flags should be coded. Neither am I disputing the fact that such signalling systems are subordinate to conventional alphabets. I'm not even saying a single set of such flags couldn't be validly coded in monochrome. (Any single set of signalling flags is usually designed to be read in adverse lighting conditions where color is poorly perceived. It is not an accident you found little trouble distinguishing the flags in monochrome.) What I'm suggesting, instead, is that in certain contexts where printing/wrinting technology hasn't presented an obstacle, meaning can indeed have been assigned to colors in what is basically running text. This makes me think that the monochromatic nature of characters is more a technological necessity than an inherent part of the definition of a character. If this is the case, it wouldn't be a bad idea to prepare for the inclusion of colored glyphs in Unicode, should the need arise, and to be careful not to dismiss coloring as a potential primary feature of new character when considering coding proposals in the future. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Re: Chromatic font research
At 07:57 +0100 2002-06-27, William Overington wrote: >Michael Everson wrote as follows. > >>I think, William, you ought to read the TR on the character-glyph >>model many times because it's clear that you want to use character >>encoding, even private-use character encoding, for things that have > >nothing to do with character encoding. > >I have now had the opportunity to study the document. >That was quick. Methinks it was overquick. >In Annex B Characters there is the following definition for a character. > >quote > >A member of a set of elements used for the organisation, control, and >representation of data. > >end quote > >There is then mention of data characters and control characters, including >the use of the word usually. > >It seems to me from that definition that codes for 36 POINT and GREEN and so >on are well within that definition. Sorry, William, but you just aren't getting it. >Indeed, that definition shows that codes such as 36 POINT and GREEN are but >on the sea shore as far as goes what a character could be used to represent. Green and 36-point are markup attibutes to be applied to real characters. Please go back and try again. Our terminology is not full of portmanteau words you can make mean whatever *you* like. This is a game for which the rules have been developed with some rigour over the years, and we try not to break them. We know that they have been broken in the past. And we also know how to apply them and we've been trying to tell you that you've been coming up with ideas that are so far afield as to boggle the mind. >Consider for example a code point for LET THERE BE A TRIANGLE and a code >point for LET THERE BE A QUADRILATERAL and a code point for LET THE NEXT >CLOCKWISE VERTEX BE REPRESENTED BY THE FOLLOWING SYMBOL (where any Unicode >character can then be used to represent that vertex in that item) and so on. >Codes such as JOIN THE PREVIOUSLY DESIGNATED VERTICES REPRESENTED BY THE >FOLLOWING TWO SYMBOLS and so on could be defined, thus allowing a computer >to produce a picture and also have a data structure which has knowledge of >the mathematical structure of the picture. William. This is ***NOT*** character encoding. It may be something that you can do with a computer. That does not mean it has anything to do with character encoding, fonts, or the Unicode Standard. >It would seem that it would be entirely within the letter and the spirit of >that definition to use code points in regular Unicode to denote all manner >of items for human and computer communication. The potential uses for pure >mathematics, artificial intelligence and psychology are enormous. Uses for >computer aided design are also possible. Don't even go there, William. This is NOT what character encoding is for. Go back and read the TR again. And again. And again. Then go read the Unicode Standard again. And again. And again. Then get a book on writing systems. Not on semasiology or philosophy of font design or any other such herring. You apparently have a lot of work to do to get onto the same page as the rest of us are. This is not an ad hominem attack. It is just a plea. -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
Michael Everson wrote:
> Marco said:
>
> >MC> However, the Aztec script uses color has a structural element:
> >MC> signs with the same design can mean different things if
> painted in
> >MC> different colors.
>
> Has it? Reference?
The best I can come up with from my private library is a single paragraph on
a book about the history of writing in general ("Storia universale della
scrittura" by Giorgio R. Cardona, Arnoldo Mondadori Editore, Milano 1986,
chapter XII "Le scritture del continente americano", 2 "Le scritture
mesoamericane", "Area azteca e olmeca", page 257):
"Gli Aztechi attribuivano una grande importanza all'opposizione tra
i vari colori: i colori avevano per loro un significato simbolico ben
preciso e, come si è accertato solo in tempi molto recenti, erano usati
normalmente nelle rappresentazioni tridimensionali; era per esempio colorato
il tante volte riprodotto disco del calendario messicano, ora nel Museo
Nazionale di Antropologia di Città del Messico. Coerentemente, anche nei
logogrammi aztechi il colore costituiva un tratto significativo."
(my translation: "Aztecs assigned great importance to color
oppositions: colors had for them a well defined symbolic meaning and, as was
proved very recently, colors were normally employed in three-dimensional
representations; for instance, color was used in the often-reproduced
Mexican calendar disc, now at the National Anthropology Museum in Mexico
City. Consistently, color was a meaningful feature also in Aztec
logographs.")
I also found a mention about this on the web ("Aztec Writing"
), although I don't know
how reliable the site is:
"Color was also important. The signs for grass, canes, and rushes
look very much the same in black and white, but in color there could be no
mistake: in the Codex Mendoza grass is yellow, canes are blue, rushes green.
A ruler could be recognized at once from the shape of his diadem and from
its color, turquoise, which was reserved for royal use."
_ Marco
Re: Chromatic font research
Daniel Yacob wrote as follows. > >In the ethiopic case it is 1362 (four dots like ::) interlaced with 5 red dots >in the sign of the cross that is the most common. This is 9 dots altogether >and at a glance looks like a colorful paragraph separator. Any punctuation >or numeral may receive extra flourishes of red (1364 receives red strokes >about as often), there is no semantic impact on the character. It is a practice >relegated by and large to religious works, scribes themselves have told me that >they have no rhyme nor reason for why they've made one character or word red in >one sentence and not the next -save for possible subliminal divine inspiration >at that particular instant :) > >The capability to the same electronically would be well received. > In the handwritten form, could you please say whether the adding of the red increases the width of the area needed to represent the character? Also, when handwritten, does the scribe have a black pen in one hand and a red pen in the other so that colouring takes place on a character by character basis as writing proceeds, or does the scribe put down one pen and pick up another, and, if so, is that on a character by character basis or is that on the basis of producing a number of characters in black and then adding the red afterwards. This would seem to be possibly significant due to the possible need to allow for the greater width of the area used for a character that is later to receive red flourishes. William Overington 27 June 2002
Re: Chromatic font research
Michael Everson wrote as follows. >I think, William, you ought to read the TR on the character-glyph >model many times because it's clear that you want to use character >encoding, even private-use character encoding, for things that have >nothing to do with character encoding. I have now had the opportunity to study the document. In Annex B Characters there is the following definition for a character. quote A member of a set of elements used for the organisation, control, and representation of data. end quote There is then mention of data characters and control characters, including the use of the word usually. It seems to me from that definition that codes for 36 POINT and GREEN and so on are well within that definition. Indeed, that definition shows that codes such as 36 POINT and GREEN are but on the sea shore as far as goes what a character could be used to represent. Consider for example a code point for LET THERE BE A TRIANGLE and a code point for LET THERE BE A QUADRILATERAL and a code point for LET THE NEXT CLOCKWISE VERTEX BE REPRESENTED BY THE FOLLOWING SYMBOL (where any Unicode character can then be used to represent that vertex in that item) and so on. Codes such as JOIN THE PREVIOUSLY DESIGNATED VERTICES REPRESENTED BY THE FOLLOWING TWO SYMBOLS and so on could be defined, thus allowing a computer to produce a picture and also have a data structure which has knowledge of the mathematical structure of the picture. It would seem that it would be entirely within the letter and the spirit of that definition to use code points in regular Unicode to denote all manner of items for human and computer communication. The potential uses for pure mathematics, artificial intelligence and psychology are enormous. Uses for computer aided design are also possible. William Overington 27 June 2002
Re: Chromatic font research
I, myself, am fascinated with this thread. I concur with Peter. Our system of characters grew out of a di-chromatic world. Every phase in the history of writing was affected by the tools at hand and was dated by it. The word for scribe in hieroglyphics is a pen and (two colour) ink horn. We wouldn't recognise it today until someone pointed it out. Cuneiform has the distinctive wedge shape because of the specific specie of plant used. Serifs came about through experimentation because carving in stone tended to crack unless it was done that way. Something about relieving the stresses in the material, I think. The indent for paragraphs came about from books being printed and leaving room for an illustrator to add the versals, decorated initials. I've read about font designers having to accommodate the differences in the type of press. Letterpress left a visible dent in the paper that added to the "colour" or total ratio of black to white of the text area. If the same exact font were chosen for web offset printing, the ratio would be off. I'm sure Michael could elaborate on the design of fonts for electronic media. My point is this. There is a cultural inertia to use a modern technology to accommodate an earlier form. I've heard it described as "instant ivy". "Ye olde shoppe" on the High Street. Unicode bowed to some of that pressure by including heritage characters like dingbats. The purpose of defining character glyphs is the goal. Leave the artistic expression of those glyphs to the font designers. There has always been the urge to embellish the text with a bit of colour, but that's what it is, an artistic embellishment. As soon as it's legislated, artists will try to do it differently just to be different. P.S. Petra Sancta was a Jesuit who devised a shorthand called "tricking" of recording heraldic shields in black and white. The demand for such books outstripped the ability to paint them in. It was later adapted to other things with a limited palette like vexillology, the study of flags. P.P.S. The design of heraldry and of flags grew out of the need to be seen on a battlefield or at sea. This dictated the use of bold, easily recognisable colours and patterns. The embellishments people employed in their armorial achievement soon grew so cluttered as to render it unrecognisable. Wm Seán Glen
Re: Chromatic font research
Petra Sancta is a centuries old method for the representation of heraldic/vexillological colours in binary black and white graphics. Fx. red is vertical lines and blue is horizontal lines. http://www.fotw.net/flags/heraldry.html#psm -Herman John Cowan skreiv: > > Sampo Syreeni scripsit: > > > > On Wed, 26 Jun 2002, Kenneth Whistler wrote: > > > > >As *characters*? Why? > > > > Naval signalling ones perhaps aren't. > > I looked at the image (less than ideal) at > http://www.fortknoxxjewelry.com/store/myname/images/1177_l.jpg > and fed it through the Gimp to strip out color information > (specifically, Image/Colors/Desaturate followed by Image/Colors/Threshold, > taking the 127 default, which leaves stark black and white). > > The only remotely confusable letters are H and K, I think, though > other people with better visual imagination may wish to check this > conclusion. > > In any event, this is plainly a letter-by-letter cipher for the basic > Latin alphabet (A-Z), and the fact that single letters or combinations > may be used as codes for cross-linguistic concepts is of no more > interest to a character encoding standard than that "ABALC" can mean > "Abandon all claims" in any of various natural languages. > > -- > John Cowan <[EMAIL PROTECTED]> http://www.reutershealth.com > I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan > han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_ -- Herman Ranes Høgskolen i Sør-Trøndelag Avdeling for teknologi Telefon +47 73559606Institutt for elektroteknikk Telefaks +47 73559581 <[EMAIL PROTECTED]> N-7004 TRONDHEIM http://www.hist.no/~herman/ NOREG
Re: Chromatic font research
- Original Message - From: "Marco Cimarosti" <[EMAIL PROTECTED]> To: "'Sampo Syreeni'" <[EMAIL PROTECTED]>; "Kenneth Whistler" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 26, 2002 8:39 PM Subject: RE: Chromatic font research > Or 127 ASCII code points? > Or ca. 9000 JIS code points? They are already encoded, aren't they? Stefan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Chromatic font research
On 06/26/2002 12:33:49 PM Sampo Syreeni wrote: >National flags are a far cry, true. Naval signalling ones perhaps aren't. >They stand for characters But that doesn't mean that they themselves are characters. (I can just imagine: characters for the signals representing the characters that represent the signals that represent... ) and I believe in some variations for entire >well-known concepts. They are utilized in a way we would expect characters >to be. I don't think the entire collection of flags used around the world >coincides neatly enough with an already encoded script to be considered >pure glyph variants. And colors are certainly meaningful in this context. OK. Twice in the past few days I've held back from writing this: characters are about text, not pictures. Pictures may be polychromatic, but text is basically non-chromatic. It's origins are making markings in sand with a stick, in clay with a stylus, on leaves with a stylus, and later on leather or paper (i.e. the precursors of paper as we know it today) with a reed pen or brush dipped in ink (and the ink was somethng dark and inexpensive -- no concern for colour -- so at most we should say that text is di-chromatic, with one tone for figure and another for the ground against which it is set). The eventual use of different colours in manuscripts for runs of characters or for the appendiges of characters (such as dots) was purely an artistic add-on; the text itself was independent of colour. It's certainly nice that we have technologies today that allow us to colour our text, sometimes even specifying the colour of the outlines and the fills separately. But that isn't part of the text itself; it's an attribute of the electronic pen used to draw the text. The text itself remains colour-neutral, and the colour attributes belong to a level of representation other than characters. Sure, pictures have colour, but pictures are not characters. Not even pictures of things that represent characters. We could invent a system that uses 4 x 4 matrices of squares each in one of 16 colours with each configuration representing a different character from a repertoire of up to 256 characters. Should these representations of characters be themselves encoded as characters? No, IMO. >(I can't fathom why anyone would want to encode those, though. Anything >you can do with flags you can do with ordinary characters, only more >efficiently. However, this could serve as an example of a script which >relies on color as an essential feature.) But it isn't a script. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Chromatic font research
Sampo Syreeni wrote: > >As *characters*? Why? > > National flags are a far cry, true. Naval signalling ones > perhaps aren't. They stand for characters [...] So, why not encoding Morse codes? Or 127 ASCII code points? Or ca. 9000 JIS code points? Or Braille dot patterns? (Ooops: delete the last example:-) _ Marco
Re: Chromatic font research
KW> As *characters*? Why? Partly because they are used in contexts that might allow interpreting them as characters (for example, used to signify languages, to signify nationalities of delegates at conferences in conference papers or to signify countries in soccer match statistics :-)). I'm not saying they *are* characters, just that it's worth thinking about it. If I had genuine evidence for them being characters, I'd propose them formally. KW> What is this bug that people catch, which induces them to consider KW> all things semiological to be, ipso facto, abstract characters KW> suitable for encoding in Unicode? In the mail to which you're answering, I dimly recall writing something like >> The most obvious and simple example for glyph colours with semantic >> meaning that I can think of... I wanted to mention something I considered a pretty good "example for glyph colours with semantic meaning". That's all. You're slightly overreacting when you talk about people catching bugs here. If I wanted to have flag characters in Unicode, I'd probably write a summery about flag character use in electronic communication and propose the whole bit, risking it being rejected as opposed to risking being snarled at on this mailing list for mentioning them. (And in a standard that has bothered to allocate Zapf Dingbats because it's present in a lot of laser printers, "all things semiological" is a bit of a broad measure) Philipp
Re: Chromatic font research
On Wed, Jun 26, 2002 at 12:04:28PM -0400, Tex Texin wrote: > Hi Keld, > > The livelink page had a link to proceed to public areas without going > thru the password. > That is how I got to the URL to the zip I mentioned below. > > So, we can access the zip on your site now without passwords? If so that > is good news. What is the URL? normal url: http://www.dkuug.dk/jtc1/sc2/wg2/ It is now both on the front page and on the standards page. The standards page: http://www.dkuug.dk/jtc1/sc2/wg2/docs/standards.html regards Keld
Re: Chromatic font research
Sampo Syreeni scripsit: > > On Wed, 26 Jun 2002, Kenneth Whistler wrote: > > >As *characters*? Why? > > Naval signalling ones perhaps aren't. I looked at the image (less than ideal) at http://www.fortknoxxjewelry.com/store/myname/images/1177_l.jpg and fed it through the Gimp to strip out color information (specifically, Image/Colors/Desaturate followed by Image/Colors/Threshold, taking the 127 default, which leaves stark black and white). The only remotely confusable letters are H and K, I think, though other people with better visual imagination may wish to check this conclusion. In any event, this is plainly a letter-by-letter cipher for the basic Latin alphabet (A-Z), and the fact that single letters or combinations may be used as codes for cross-linguistic concepts is of no more interest to a character encoding standard than that "ABALC" can mean "Abandon all claims" in any of various natural languages. -- John Cowan <[EMAIL PROTECTED]> http://www.reutershealth.com I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
Re: Chromatic font research
On Wed, 26 Jun 2002, Kenneth Whistler wrote: >As *characters*? Why? National flags are a far cry, true. Naval signalling ones perhaps aren't. They stand for characters and I believe in some variations for entire well-known concepts. They are utilized in a way we would expect characters to be. I don't think the entire collection of flags used around the world coincides neatly enough with an already encoded script to be considered pure glyph variants. And colors are certainly meaningful in this context. (I can't fathom why anyone would want to encode those, though. Anything you can do with flags you can do with ordinary characters, only more efficiently. However, this could serve as an example of a script which relies on color as an essential feature.) Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Re: Chromatic font research
Marco said: >MC> However, the Aztec script uses color has a structural element: >MC> signs with the same design can mean different things if painted in >MC> different colors. Has it? Reference? -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
DANISH/SWEDISH/FINNISH; NORWEGIAN/ICELANDIC Don // -Original Message- From: Philipp Reichmuth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 8:55 AM To: Marco Cimarosti Cc: [EMAIL PROTECTED] Subject: Re: Chromatic font research The most obvious and simple example for glyph colours with semantic meaning that I can think of appears to be encoding characters for national flags (something that might even be considered proposable). The differences between IRISH FLAG, BELGIAN FLAG, FRENCH FLAG (or TRICOLORE?), NIGERIAN FLAG, ITALIAN FLAG, DUTCH FLAG, GERMAN FLAG and NAMIBIAN FLAG are pretty obvious (apart from some being vertically, some being horizontally striped...) and I don't think that's all of them :-) And I'm quite positive that Aztec can safely considered "writing"... Philipp
Re: Chromatic font research
Philipp said: > The most obvious and simple example for glyph colours with semantic > meaning that I can think of appears to be encoding characters for > national flags (something that might even be considered proposable). As *characters*? Why? What is this bug that people catch, which induces them to consider all things semiological to be, ipso facto, abstract characters suitable for encoding in Unicode? There are signs that are not characters. There are symbols that are not characters. There are icons that are not characters. There are significant gestures that are not characters. There are meaningful looks that are not characters. There are color significances that are not characters. There are pregnant pauses that are not characters... > And I'm quite positive that Aztec can safely considered "writing"... Aztec is clearly a language. Whether or not the Aztec codices are appropriate to represent in plain text remains to be seen. As yet, we have no proposal, let alone one which addresses the potential problems in detail. --Ken > > Philipp
Re: Chromatic font research
MC> However, the Aztec script uses color has a structural element: MC> signs with the same design can mean different things if painted in MC> different colors. So, if scholars *would* agree that Aztec is MC> "writing", and if this script *would* get into Unicode, then color MC> *should* have to be considered also at the encoding level. The most obvious and simple example for glyph colours with semantic meaning that I can think of appears to be encoding characters for national flags (something that might even be considered proposable). The differences between IRISH FLAG, BELGIAN FLAG, FRENCH FLAG (or TRICOLORE?), NIGERIAN FLAG, ITALIAN FLAG, DUTCH FLAG, GERMAN FLAG and NAMIBIAN FLAG are pretty obvious (apart from some being vertically, some being horizontally striped...) and I don't think that's all of them :-) And I'm quite positive that Aztec can safely considered "writing"... Philipp
Re: Chromatic font research
Hi Keld, The livelink page had a link to proceed to public areas without going thru the password. That is how I got to the URL to the zip I mentioned below. So, we can access the zip on your site now without passwords? If so that is good news. What is the URL? It would be good if the Unicode site had a link to it. tex Keld Jørn Simonsen wrote: > > The livelink was on the SC2/WG2 standards page, I now > added the .zip file. BTW, the livelink has a password protection. > > Kind regards > keld > > On Tue, Jun 25, 2002 at 09:35:14PM -0400, Tex Texin wrote: > > Since it is freely available, I wonder if permission to host and make > > the doc additionally available on-line were requested, if it would be > > granted. > > > > In the interim, I don't see a legal issue with publishing the direct URL > > and making it known from the various sites containing info on i18n- is > > there a problem with that? > > > > http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/C027163e.zip > > > > > > [EMAIL PROTECTED] wrote: > > > > > > On 06/25/2002 03:21:50 PM Michael Everson wrote: > > > > > > >"ISO/IEC TR 15285 - An operational model for characters and glyphs" > > > >can be had for for 98 Swiss Francs from > > > >http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=27163 > > > > > > The ISO catalog is incredibly annoying in that it doesn't tell you about > > > ISO standards that have been made freely available in electronic versions. > > > ISO/IEC TR 15285:1998 is freely available at the following location (and > > > good luck tracking it down from scratch in the future). > > > > > > >http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm??Redirect=1 > > > > > > - Peter > > > > > > --- > > > Peter Constable > > > > > > Non-Roman Script Initiative, SIL International > > > 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA > > > Tel: +1 972 708 7485 > > > E-mail: <[EMAIL PROTECTED]> > > > > -- > > - > > Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] > > Xen Master http://www.i18nGuy.com > > > > XenCraft http://www.XenCraft.com > > Making e-Business Work Around the World > > - -- - Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] Xen Master http://www.i18nGuy.com XenCrafthttp://www.XenCraft.com Making e-Business Work Around the World -
Re: Chromatic font research
The livelink was on the SC2/WG2 standards page, I now added the .zip file. BTW, the livelink has a password protection. Kind regards keld On Tue, Jun 25, 2002 at 09:35:14PM -0400, Tex Texin wrote: > Since it is freely available, I wonder if permission to host and make > the doc additionally available on-line were requested, if it would be > granted. > > In the interim, I don't see a legal issue with publishing the direct URL > and making it known from the various sites containing info on i18n- is > there a problem with that? > > http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/C027163e.zip > > > [EMAIL PROTECTED] wrote: > > > > On 06/25/2002 03:21:50 PM Michael Everson wrote: > > > > >"ISO/IEC TR 15285 - An operational model for characters and glyphs" > > >can be had for for 98 Swiss Francs from > > >http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=27163 > > > > The ISO catalog is incredibly annoying in that it doesn't tell you about > > ISO standards that have been made freely available in electronic versions. > > ISO/IEC TR 15285:1998 is freely available at the following location (and > > good luck tracking it down from scratch in the future). > > > > >http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm??Redirect=1 > > > > - Peter > > > > --- > > Peter Constable > > > > Non-Roman Script Initiative, SIL International > > 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA > > Tel: +1 972 708 7485 > > E-mail: <[EMAIL PROTECTED]> > > -- > - > Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] > Xen Master http://www.i18nGuy.com > > XenCraft http://www.XenCraft.com > Making e-Business Work Around the World > -
RE: Chromatic font research
Peter Constable wrote: > On 06/25/2002 11:17:52 AM Marco Cimarosti wrote: > > >Use of the Private Use Area is never questionable, as far as > it remains > >*private*. > > I think this might be overreacting -- or at least it can seem > to be so. [...] Sorry if I made this impression: I actually had a quite different thing in mind. I meant that, as a *minimum*, private usage of PUA is perfectly acceptable. (I was not talking about publicly documented usages, which I don't consider "illegal" a priori). William O.'s idea of Christmas leaf PUA character to demonstrate a certain technology (chromatic fonts) is *definitely* private and, hence, definitely legal. What I argued is that such an ad-hoc character was an inappropriate example, because it would distract people from the main fact: that it has two colors. I mean: people would ask: "What's that character?"; "If you wanted a multi-color Christmas decoration, why didn't you insert a picture?"; and so on. On the other hand, showing an entire Arabic (or English) text where all dots have a different color from the rest of text makes it clear that you could not use pictures to do it. > BTW, while I think your character is perfectly fine for you > to experiment with (and has a fun aspect to it), I am quite > concerned at your choice of name: it suggests that it might > be reasonable for someone to encode characters with > specific chromatic attributes. I definitely think this > would be inappropriate for a character set encoding standard. There is a remote theoretical possibility that this statement may become incorrect in the future. In all the examples we made so far, including William's leaf, color is just decorative so it doesn't belong to encoding itself. However, the Aztec script uses color has a structural element: signs with the same design can mean different things if painted in different colors. So, if scholars *would* agree that Aztec is "writing", and if this script *would* get into Unicode, then color *should* have to be considered also at the encoding level. Ciao. Marco
Re: Chromatic font research
"ISO/IEC TR 15285 - An operational model for characters and glyphs" can be had for for 98 Swiss Francs from http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=27163 -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
At 19:31 +0100 2002-06-25, Alistair Vining wrote: > > > ISO/IEC TR 15285 - An operational model for characters and glyphs > >To pre-empt any questions, Google says: >http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/N1411.doc (working draft). That is not the final document, is it? As such it should not be used. The published version should be used. -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
On 06/25/2002 11:17:52 AM Marco Cimarosti wrote: >Use of the Private Use Area is never questionable, as far as it remains >*private*. I think this might be overreacting -- or at least it can seem to be so. In principle, there's nothing wrong with William creating a character to experiment with, nothing wrong with assigning a PUA codepoint for that character, and nothing wrong with publicly documenting that. William, I think some people on this list are just a little exhausted on Overingtonian discussions of the PUA. I may be wrong, but I suspect that that's really what Marco is reacting to. You might want to limit comments in that regard a bit. You said, >Also, as a contribution to the research discussion, I wonder if I may >suggest the following test item. > >U+E7C2 HOLLY LEAF (GREEN) SURROUNDED BY FIVE BERRIES (RED) Your definition of the character for your purposes is valid in and of itself, but it's not centrally important to the discussion (Marco has identified other candidates that can be used for experimentation), and is probably a tender spot with some people. In particular, the wording suggests you're offering this character to the rest of the list, which is reminiscent of ideas of standardised PUA allocations, to which most are very opposed. Thus, others might appreciate it if a comment in this vein were limited to something like, "For my experimentation, I'm defining a PUA character HOLLY LEAF (GREEN) SURROUNDED BY FIVE BERRIES (RED), which I'll document on my web site in case it's of interest to anyone else.' BTW, while I think your character is perfectly fine for you to experiment with (and has a fun aspect to it), I am quite concerned at your choice of name: it suggests that it might be reasonable for someone to encode characters with specific chromatic attributes. I definitely think this would be inappropriate for a character set encoding standard. >> [... I am hopeful that chromatic font technology >> has now reached a gel level [...] > >As far as I know, chromatic font technology does *not* exist yet and there >is no big need for it. I had the same thoughts. - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Chromatic font research
Michael Everson wrote: > > An ISO Technical Report. The one in question is > > ISO/IEC TR 15285 - An operational model for characters and glyphs To pre-empt any questions, Google says: http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/N1411.doc (working draft). Al.
Re: Chromatic font research
At 17:30 +0100 2002-06-25, William Overington wrote: >Michael Everson wrote as follows. > >>I think, William, you ought to read the TR on the character-glyph >>model many times because it's clear that you want to use character >>encoding, even private-use character encoding, for things that have >>nothing to do with character encoding. > >What please is a TR? An ISO Technical Report. The one in question is ISO/IEC TR 15285 - An operational model for characters and glyphs -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Chromatic font research
Michael Everson wrote as follows. >I think, William, you ought to read the TR on the character-glyph >model many times because it's clear that you want to use character >encoding, even private-use character encoding, for things that have >nothing to do with character encoding. What please is a TR? William Overington 25 June 2002
Re: Chromatic font research
> of the uses have a cultural and sometimes religious significance I felt that > it would be respectful to those situations to use a purely ornamental In the ethiopic case it is 1362 (four dots like ::) interlaced with 5 red dots in the sign of the cross that is the most common. This is 9 dots altogether and at a glance looks like a colorful paragraph separator. Any punctuation or numeral may receive extra flourishes of red (1364 receives red strokes about as often), there is no semantic impact on the character. It is a practice relegated by and large to religious works, scribes themselves have told me that they have no rhyme nor reason for why they've made one character or word red in one sentence and not the next -save for possible subliminal divine inspiration at that particular instant :) The capability to the same electronically would be well received. /Daniel
RE: Chromatic font research
William Overington wrote: > I am not knowledgable about Ethiopic manuscripts or Arabic > letters. As many of the uses have a cultural and sometimes > religious significance I felt that it would be respectful to > those situations to use a purely ornamental example for > experiments, [...] OK, let's assume this possibility. (BWT, I don't think it is the case of Arabic, but I am not sure about Ethiopic). Anyway, one can use any other familiar character: no need of inventing an ad-hoc one. E.g., you can have a blue "i" with a red dot (U+0069); a green hat on a pale blue "snowman" (U+2603), a yellow fill for a black-framed "smiling face" (U+263A), an orange shadow for a "shadowed white star" (U+2730). > [...] > Given that, surely it is respectful and polite of me to place it > in the Private Use Area Things like a blue "i" with a red dot (U+0069) can perhaps be ugly or pointless, but how can they be inpolite or unrespectful? > rather than for me to have suggested some adaption of a regular > Unicode symbol in a way that would perhaps not be compatible with the > Unicode specification. Several people are repeating over and over one thing: Unicode specification does not specify the look (color, font, size, ect.) of the glyphs which represent characters. > Unfortunately what I thought was my thoughtful and > considerate correctness in using the Private Use Area for the > purpose needed is seen as in some way questionable. Use of the Private Use Area is never questionable, as far as it remains *private*. > I cannot understand what is seen as questionable about defining > a character in the Private Use Area in order to help facilitate > some research. The point is another: there is no point in having a special character for an example! Imagine that I wanted to make a short educational film to teach children how to lace shows. Obviously, I need an actor or actress who sits in front of the camera and shows, very slowly, how lacing is done. Would it be OK, for you, to choose a green-skinned naked girl bleeding blue blood from her left arm while she vomits orange worms and with a screeming purple condor sitting on her bald head? Would children pay more attention to the proccess of lacing shows or to the characteristics of the bizzarre person who is performing the action? > Also, I had not understood the two cases which you explain > above. I realize > now that some way of indicating that a colour should be mapped to null > rather than to black in the event of a chromatic rendering > system for a chromatic font not being available. Yes, good rewording, that's what I meant. > [... I am hopeful that chromatic font technology > has now reached a gel level [...] As far as I know, chromatic font technology does *not* exist yet and there is no big need for it. But I may be wrong, of course: I don't have hidden mikes in the labs of software companies. _ Marco
Re: Chromatic font research
William Overington wrote: > I am not knowledgable about Ethiopic manuscripts or Arabic letters. > As many of the uses have a cultural and sometimes religious > significance I felt that it would be respectful to those situations > to use a purely ornamental example for experiments, one with which > I am familiar because of the use of metal type ornaments with a > hand press as part of a hobby interest in letterpress printing. My > feeling was that if the technology could be produced, then, once > soundly based using experimental examples, the technology could be > employed in a correct cultural and religious context by those with > the appropriate knowledge to apply the technology correctly in > those situations. For once, I agree with William about something. The problem of unintentionally causing offense is well known in the field of i18n/L10n (and not just for software, either). Unless you are sure what you are doing, it is often better to use an artificial example for demonstration purposes than to risk misusing a real example. -Doug Ewell Fullerton, California
Re: Chromatic font research
Marco Cimarosti asked the following. >How is an imaginary test case preferable to the real cases which were >already proposed? These were: > >1) Black Ethiopic paragraph separator (U+1368) decorated with little red >dots (suggested by Peter Constable). > >2) Arabic letters with black stems and red dots (suggested by me). > >Both chromatic combinations are actually used (although not in current >modern usage), and they are representative of the whole issue, because they >map in two different ways to the usual monochrome display: > >- In the Ethiopic case (1), the red dots are just decorative, so they should >be dropped in monochrome display. > >- In the Arabic case, just the color of the red dots is decorative, but the >dots themselves are part of the letter, so they should be retained also in >monochrome display. I am not knowledgable about Ethiopic manuscripts or Arabic letters. As many of the uses have a cultural and sometimes religious significance I felt that it would be respectful to those situations to use a purely ornamental example for experiments, one with which I am familiar because of the use of metal type ornaments with a hand press as part of a hobby interest in letterpress printing. My feeling was that if the technology could be produced, then, once soundly based using experimental examples, the technology could be employed in a correct cultural and religious context by those with the appropriate knowledge to apply the technology correctly in those situations. >Moreover, Peter's and my examples, by using existing characters, do not >require any "PUA agreement" -- or is it mandatory to use the PUA for just >everything? > No, it is not mandatory to use the Private Use Area for everything. I was here using it to produce a character for specific research purposes. Given that, surely it is respectful and polite of me to place it in the Private Use Area rather than for me to have suggested some adaption of a regular Unicode symbol in a way that would perhaps not be compatible with the Unicode specification. Unfortunately what I thought was my thoughtful and considerate correctness in using the Private Use Area for the purpose needed is seen as in some way questionable. I cannot understand what is seen as questionable about defining a character in the Private Use Area in order to help facilitate some research. Also, I had not understood the two cases which you explain above. I realize now that some way of indicating that a colour should be mapped to null rather than to black in the event of a chromatic rendering system for a chromatic font not being available. I am only recently learning how to produce fonts. I have three experimental fonts at early stages. One is text with ligatures such as ct and so on. One is a chess font, including the extra pieces for the historical variant Carrera's Chess. The other is a font for artistic use in graphic art. I am learning a lot from trying to produce them. I am hopeful that chromatic font technology has now reached a gel level whereby it is no longer seen as something which is only hypothetical but as a technology which is now as likely to be implemented within the next five years as not. My experience with inventions and the inventive process is that it is quite possible that major corporations are now actively considering the possibilities for chromatic fonts and that chromatic fonts may possibly now be regarded as leading edge research which may soon become state of the art. Naturally, businesses do not make public statements about everything that they are researching in case they wish to file patent applications on what they develop. Also I feel that whereas chromatic font technology could be very usefully applied to transcribing ancient manuscripts and I hope that that is done, in order for it to gain widespread enthusiasm and for the development of desktop publishing packages which can handle it, there need to be some mainstream computing applications available where using chromatic font technology will give that extra flair to people's use of computers. Defining one or more Private Use Area codes gives people something to consider and, if they so choose, to apply. William Overington 25 June 2002 http://www.users.globalnet.co.uk/~ngo
RE: Chromatic font research
> In Egyptian in the coffin texts passages are put in red, and this has > a meaning, but it doesn't mean that we wouldn't do it with markup. > Though if it WERE done by character encoding, it would be via BEGIN > RUBRIC and END RUBRIC characters functioning like left and right > parentheses leaving the display up to the very clever Egyptian-savvy > renderer. Wait: the issue being discussed is when *parts* of a glyph have different colors. Changing the color of whole characters or passages is not an issue: just use markup. (Either standard or home-made markup :-) _ Marco
RE: Chromatic font research
At 12:22 +0200 2002-06-25, Marco Cimarosti wrote: >William Overington wrote: >> Michael Everson raised a very interesting question, which >> caused me to sit and think about it for quite a while. >> >> >At 08:16 +0100 2002-06-24, William Overington wrote: >> > >> >>U+E7C2 HOLLY LEAF (GREEN) SURROUNDED BY FIVE BERRIES (RED) >> > >> >As a "character", will this differ from HOLLY LEAF SURROUNDED BY FIVE >> >BERRIES in its semantics? If not, then you are using character coding >> >for a higher level protocol again. >> >> Well, after some thought as to whether it would differ in its >> semantics or >> whether it would not differ in its semantics, I realized that I had no >> intention that HOLLY LEAF SURROUNDED BY FIVE BERRIES would be >> defined as >> well. I suggested U+E7C2 HOLLY LEAF (GREEN) SURROUNDED BY >> FIVE BERRIES (RED) as a test item, [...] > >How is an imaginary test case preferable to the real cases which were >already proposed? These were: > >1) Black Ethiopic paragraph separator (U+1368) decorated with little red >dots (suggested by Peter Constable). > >2) Arabic letters with black stems and red dots (suggested by me). > >Both chromatic combinations are actually used (although not in current >modern usage), and they are representative of the whole issue, because they >map in two different ways to the usual monochrome display: > >- In the Ethiopic case (1), the red dots are just decorative, so they should >be dropped in monochrome display. > >- In the Arabic case, just the color of the red dots is decorative, but the >dots themselves are part of the letter, so they should be retained also in >monochrome display. > >Moreover, Peter's and my examples, by using existing characters, do not >require any "PUA agreement" -- or is it mandatory to use the PUA for just >everything? > >_ Marco -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
In Egyptian in the coffin texts passages are put in red, and this has a meaning, but it doesn't mean that we wouldn't do it with markup. Though if it WERE done by character encoding, it would be via BEGIN RUBRIC and END RUBRIC characters functioning like left and right parentheses leaving the display up to the very clever Egyptian-savvy renderer. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Chromatic font research
I think, William, you ought to read the TR on the character-glyph model many times because it's clear that you want to use character encoding, even private-use character encoding, for things that have nothing to do with character encoding. -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: Chromatic font research
William Overington wrote: > Michael Everson raised a very interesting question, which > caused me to sit and think about it for quite a while. > > >At 08:16 +0100 2002-06-24, William Overington wrote: > > > >>U+E7C2 HOLLY LEAF (GREEN) SURROUNDED BY FIVE BERRIES (RED) > > > >As a "character", will this differ from HOLLY LEAF SURROUNDED BY FIVE > >BERRIES in its semantics? If not, then you are using character coding > >for a higher level protocol again. > > Well, after some thought as to whether it would differ in its > semantics or > whether it would not differ in its semantics, I realized that I had no > intention that HOLLY LEAF SURROUNDED BY FIVE BERRIES would be > defined as > well. I suggested U+E7C2 HOLLY LEAF (GREEN) SURROUNDED BY > FIVE BERRIES (RED) as a test item, [...] How is an imaginary test case preferable to the real cases which were already proposed? These were: 1) Black Ethiopic paragraph separator (U+1368) decorated with little red dots (suggested by Peter Constable). 2) Arabic letters with black stems and red dots (suggested by me). Both chromatic combinations are actually used (although not in current modern usage), and they are representative of the whole issue, because they map in two different ways to the usual monochrome display: - In the Ethiopic case (1), the red dots are just decorative, so they should be dropped in monochrome display. - In the Arabic case, just the color of the red dots is decorative, but the dots themselves are part of the letter, so they should be retained also in monochrome display. Moreover, Peter's and my examples, by using existing characters, do not require any "PUA agreement" -- or is it mandatory to use the PUA for just everything? _ Marco
