RE: [unicode] Re: FW: Inappropriate Proposals FAQ
On 07/17/2002 02:06:11 PM David Possin wrote: >I was just trying to draw out something useful from a rather >useless long thread that wasted a lot of time. I certainly won't object to any attempt to redeem value from what may have seemed worthless. - 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: [unicode] Re: FW: Inappropriate Proposals FAQ
Marco, I see your point, you are probably right. Peter, I agree with you that color or other attributes are not Unicode issues when each entity has a different meaning. Each just gets their own codepoint. I was just trying to draw out something useful from a rather useless long thread that wasted a lot of time. What I am trying to understand is where exactly the color (or smell, sound) information gets added to the code. Does the font developer add this information to the glyphs and the rendering engine processes the information correctly? The two glyphs look the same otherwise, so how would the rendering engine know what to do without the attribute info? Does a mechanism for attribute already exist when a glyph gets sent from the font to the rendering engine? I know that this Aztec writing system will probably never be encoded, but I like to think in advance about possible solutions when a related issue might pop up some day, even if I push into the back of my brain then. Looking at the amount of time wasted already, a few thoughts about the only usable issue in the thread shouldn't be a waste of time. So, if it is a font issue, how would these attributes be stored with the font? Or does it look up the descriptive attributes assigned to each Unicode character? Meaning now that the attribute is defined in the Unicode standard as part of the character description, thus a Unicode issue after all? Hmm - full circle - chicken or egg? Dave --- [EMAIL PROTECTED] wrote: > > On 07/05/2002 03:00:35 PM Marco Cimarosti wrote: > > >David Possin wrote: > >> But, if something it silently ignored, then somebody has > discovered > >> something that nobody wants to touch. I have observed this sevaral > >> times now, the latest incident was in the Chromatic Font Research > >> thread, with 2 cases: > >> > >> Aztec glyphs: [...] Silence. > > > >Funny. I interpreted that silence the opposite way: very positively. > I > >didn't expect any immediate action, and the absence of denials made > me > feel > >the information I passed was not totally pointless. > > > >Anyway, even if the silence actually meant "Who cares?", it doesn't > bother > >me, because I think this is NOT an issue for Unicode... > > I think Marco has got this right. Let's suppose Aztec writing gets > deciphered and there are cases of the same shape with different > colouring > to mean different things. Let's further suppose that we determine > that the > difference in semantics isn't akin to the ways in which colouring of > English text might conceivably be used (e.g. for emphasis) but is > really > fundamental. Let's also further suppose that, taking all things into > consideration, we really do consider this text and come to the > conclusion > that the best solution is one that's purely text-based (i.e. no > markup or > other higher-level protocal). We're nowhere near having made all > these > conclusions, but let's just suppose. So, we identify two things that > are > minimally contrastive: a red-and-white-whatsit, and a > blue-green-and-yellow-whatsit. They are two entities and each gets a > codepoint. That's an encoding issue. How they get rendered isn't an > encoding issue. > > Of course, at that point, we'd be wanting to consider how to deal > with > chromatic issues in text rendering where chromaticity is inherent to > the > character and not a matter of user-discretion (for which formatting > is > appropriate). But we are not yet at the point of knowing that is even > necessary. And since it would clearly not be a trivial problem to > solve > (it's not finding a way to do it that's hard -- it's the huge amount > of > secondary implications), I think the silence amounts to a reaction > that we > neither are ready to cross that bridge nor do we need to at this time > -- in > fact, it's not yet certain that we will ever need to -- and that in > the > mean time there are more immediate and real concerns to be dealt > with. > > > > - 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]> > > > > = Dave Possin Globalization Consultant www.Welocalize.com http://groups.yahoo.com/group/locales/ __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
RE: [unicode] Re: FW: Inappropriate Proposals FAQ
On 07/05/2002 03:00:35 PM Marco Cimarosti wrote: >David Possin wrote: >> But, if something it silently ignored, then somebody has discovered >> something that nobody wants to touch. I have observed this sevaral >> times now, the latest incident was in the Chromatic Font Research >> thread, with 2 cases: >> >> Aztec glyphs: [...] Silence. > >Funny. I interpreted that silence the opposite way: very positively. I >didn't expect any immediate action, and the absence of denials made me feel >the information I passed was not totally pointless. > >Anyway, even if the silence actually meant "Who cares?", it doesn't bother >me, because I think this is NOT an issue for Unicode... I think Marco has got this right. Let's suppose Aztec writing gets deciphered and there are cases of the same shape with different colouring to mean different things. Let's further suppose that we determine that the difference in semantics isn't akin to the ways in which colouring of English text might conceivably be used (e.g. for emphasis) but is really fundamental. Let's also further suppose that, taking all things into consideration, we really do consider this text and come to the conclusion that the best solution is one that's purely text-based (i.e. no markup or other higher-level protocal). We're nowhere near having made all these conclusions, but let's just suppose. So, we identify two things that are minimally contrastive: a red-and-white-whatsit, and a blue-green-and-yellow-whatsit. They are two entities and each gets a codepoint. That's an encoding issue. How they get rendered isn't an encoding issue. Of course, at that point, we'd be wanting to consider how to deal with chromatic issues in text rendering where chromaticity is inherent to the character and not a matter of user-discretion (for which formatting is appropriate). But we are not yet at the point of knowing that is even necessary. And since it would clearly not be a trivial problem to solve (it's not finding a way to do it that's hard -- it's the huge amount of secondary implications), I think the silence amounts to a reaction that we neither are ready to cross that bridge nor do we need to at this time -- in fact, it's not yet certain that we will ever need to -- and that in the mean time there are more immediate and real concerns to be dealt with. - 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: Chromatic text. (follows from Re: [unicode] Re: FW: Inappropriate Proposals FAQ)
> -Original Message- > From: William Overington [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 08, 2002 10:20 AM > To me, such a distinction means that people who are using > lower cost, more > generally available software packages, might by such an > approach be able in > the not too distant future to use files in a non-proprietary > portable format > and get much better results than just using monochrome > traditional plain text. I don't see how putting this sort of stuff in Unicode in any way speeds up adoption into real-world use. Applications have to "learn" how to deal with the text manipulation specification, whether it's provided as markup or theoretically stored in Unicode. Bottom line is that it would take a while to trickle down to the level you describe. Unicode isn't the/a solution for bridging your digital divide.
RE: Chromatic text. (follows from Re: [unicode] Re: FW: Inappropriate Proposals FAQ)
William Overington wrote: > Actually I was trying in the posting upon which you comment > to suggest that, even if people do not agree with me about > having colour codes in a plain text file, they might > perhaps consider as a separate issue the adding into regular > Unicode of a zero width operator whose use would be > to indicate that a character, such as U+1362, should be > decorated chromatically. Come on, William!! Adding such a "zero width operator" *is* having color in plain text! And adding such "zero width operators" *is* inserting mark up in plain text! > >I interpret your post as one more lengthy repetition of your > well-known > >opinion: differences between "plain text" and "rich text" > should not exist: > >they should be eliminated by incorporating the mark-up in > the encoding. > > Actually, that is not my opinion. No, I know. This is my explanation of my perception of your explanation of your opinion. Now I am not sure what your perception of my explanation of my perception of your explanation of your opinion might be. Gentlemen, communication is such a difficult art! > [...] > Perhaps some sort of consensus over nomenclature for three > categories of > text file could occur, namely plain text in the manner which > you like it, > plain text in the manner in which I like it and markup. > Maybe plain text, > enhanced text and markup would be suitable names. How do > people feel about > that please? I would suggest "proletarian text", "middle-class text" and "capitalist text", if I wasn't so scared that someone could take it seriously. > It is unfortunately the case in discussions that when someone > disagrees with > an idea that is put forward that he or she is more likely to > respond in > public than if he or she agrees with an idea which is put > forward, or has > simply read about the idea and just notes it as an > interesting possibility. > This can have the effect that many people may agree with an > idea or at least > not be against it yet make no comment, perhaps giving an > impression that an > idea is not well received at large when in fact that is not > necessarily the > case. Yes, definitely a difficult art. _ Marco
Re: Chromatic text. (follows from Re: [unicode] Re: FW: Inappropriate Proposals FAQ)
Marco Cimarosti wrote as follows. >Of course you can. But my feeling is that you already *did* suggest this, >many and many times. Actually I was trying in the posting upon which you comment to suggest that, even if people do not agree with me about having colour codes in a plain text file, they might perhaps consider as a separate issue the adding into regular Unicode of a zero width operator whose use would be to indicate that a character, such as U+1362, should be decorated chromatically. This would mean that a sequence U+1362 ZWJ ZWCDO could be used in documents, which would give a chromatically decorated glyph with a chromatic font yet would just give U+1362 as a monochrome character if the font did not recognize the U+1362 ZWJ ZWCDO sequence. > >I interpret your post as one more lengthy repetition of your well-known >opinion: differences between "plain text" and "rich text" should not exist: >they should be eliminated by incorporating the mark-up in the encoding. > Actually, that is not my opinion. My opinion is that splitting text files into just two categories, either plain text or markup is not sufficient, but that there should perhaps be more categories or, if there are but two categories that the dividing line between them should be in a different place. I tend to base the essential dividing line upon whether the encoding of the file of code points is meaningful if one tries to compute the effect of a code point upon the system as simply the effect of that code point as it stands, without having to have software recognize a character such as < and determine that a markup bubble is being entered then to have to read in several more characters within the markup bubble before taking any action as a result of the first character in the sequence (that is, the < character) being read. That distinction means that each Unicode character is processed as it is received within the main loop of the program, without the receiving of a < character putting the processing into an inner loop within a markup bubble, within which bubble ordinary Unicode character codes which are read have a different meaning than in the Unicode specification. To me, such a distinction means that people who are using lower cost, more generally available software packages, might by such an approach be able in the not too distant future to use files in a non-proprietary portable format and get much better results than just using monochrome traditional plain text. Perhaps some sort of consensus over nomenclature for three categories of text file could occur, namely plain text in the manner which you like it, plain text in the manner in which I like it and markup. Maybe plain text, enhanced text and markup would be suitable names. How do people feel about that please? It is unfortunately the case in discussions that when someone disagrees with an idea that is put forward that he or she is more likely to respond in public than if he or she agrees with an idea which is put forward, or has simply read about the idea and just notes it as an interesting possibility. This can have the effect that many people may agree with an idea or at least not be against it yet make no comment, perhaps giving an impression that an idea is not well received at large when in fact that is not necessarily the case. William Overington 8 July 2002
RE: Chromatic text. (follows from Re: [unicode] Re: FW: Inappropriate Proposals FAQ)
William Overington wrote: > >The problem (if there is one!) is only for font technology. > > > >> Ethiopian writing: [...] "The capability to the same electronically > >> would be well received. /Daniel." > > > >Same for this one: Unicode's task was to provide a code point for the > >Ethiopic full stop, and they did. Whether the corresponding glyph is > colored > >or not is problem for fonts and word processors. > > Well, may I please suggest that the issue is one for Unicode > as well as for font technology? > > [...] Of course you can. But my feeling is that you already *did* suggest this, many and many times. I interpret your post as one more lengthy repetition of your well-known opinion: differences between "plain text" and "rich text" should not exist: they should be eliminated by incorporating the mark-up in the encoding. I think that it is your right to repeat your opinions as many times as you want. Nevertheless, I find that repeating opinions which are already well-known to everybody is *useless* and *boring*. _ Marco
Chromatic text. (follows from Re: [unicode] Re: FW: Inappropriate Proposals FAQ)
>The problem (if there is one!) is only for font technology. > >> Ethiopian writing: [...] "The capability to the same electronically >> would be well received. /Daniel." > >Same for this one: Unicode's task was to provide a code point for the >Ethiopic full stop, and they did. Whether the corresponding glyph is colored >or not is problem for fonts and word processors. Well, may I please suggest that the issue is one for Unicode as well as for font technology? Firstly, for the avoidance of doubt in the matter, whereas I am an advocate for adding codes into Unicode for effects for organizing and controlling data in ways which some people consider should be done only by markup methods, I am hoping that, without that aspect of my research prejudicing the matter, readers might consider the possibility of adding into regular Unicode some operators for use in ZWJ sequences for requesting that a chromatically decorated glyph of the 'operated upon' regular Unicode character be produced if the font can provide it, yet otherwise that a monochrome ordinary glyph be provided. May I please refer to the following document. http://www.users.globalnet.co.uk/~ngo/courtfor.htm In that document I wrote as follows. quote Here are some codes for use in ZWJ sequences of the form U+ ZWJ U+F3DC and U+ ZWJ U+F3DD so as to provide facilities to indicate to a chromatic font that a colour decorated version of U+ is requested, where U+ represents any Unicode character where such usage would be meaningful. This facility is provided in anticipation of the possibility of chromatic fonts being introduced at some time in the future. U+F3DC ZERO WIDTH DECORATION OPERATOR OF THE FIRST KIND U+F3DD ZERO WIDTH DECORATION OPERATOR OF THE SECOND KIND end quote May I please refer to the following document. http://www.users.globalnet.co.uk/~ngo/courtcol.htm In that document I wrote as follows. quote U+F3E0 BLACK U+F3E1 BROWN U+F3E2 RED U+F3E3 ORANGE U+F3E4 YELLOW end quote So, it would be the case that in order to set some text in black one would use U+F3E0 then the text and in order to set some text in red one would use U+F3E2 then the text. In order to set some text in black including a character U+1362 in black with red flourishes one would use U+F3E0 then the text which precedes the U+1362 character and then U+1362 ZWJ U+F3DC which should do the job perfectly well as the chromatic font would be set up so that the decoration of the first kind operator worked in black and red. More generally, for other chromatic characters from other applications where the colours are not specific, then the chromatic colours can be changed before using the ZWJ sequence. Quoting from the same document. quote Colour changing is by a specially devised method which will hopefully be efficient in practice. Upon receiving one of the 18 codes to change colour, the system presumes on a temporary basis that the new colour is to become the foreground colour, which is what it will usually be. However, the previous foreground colour is stored. If a command to set one of the other four colours is received, then the foreground colour is used for that purpose, with the foreground colour being replaced by the previous foreground colour. This means that only one code point is needed to change the foreground colour and two code points are needed to change the contents of any of the other colour registers. The decoration colours are intended to be ready for the possible introduction of chromatic fonts at some future date. U+F3AC SET NEW BACKGROUND COLOUR U+F3AD SET NEW FIRST DECORATION COLOUR U+F3AE SET NEW SECOND DECORATION COLOUR U+F3AF SET NEW THIRD DECORATION COLOUR end quote In using chromatic font technology I suggest that the specific colours could either be built into the glyph or could just be foreground colour, background colour, first decoration colour, second decoration colour, third decoration colour, in abstract terms with the specific colours being supplied by the rendering software. This would enable some glyphs, such as those for the Ethiopic manuscripts, to be specified as black and red within the font, and for some glyphs, such as those for an ornament, to be specified by the rendering software. As regards the possibility of including such code points as I have mentioned above in regular Unicode, well, there are various levels. There is the issue of whether codes such as U+F3E2 RED above should be promoted as some people feel that they are markup and should not be included in regular Unicode. Well, that is an issue and I quite accept that I am currently in the minority over that issue, though I would ask that readers might look into the matter of the use of such codes in DVB-MHP (Digital Video Broadcasting - Multimedia Home Platform) broadcasting of multimedia where text in Unicode files will be processed by Java programs which have been broadcast to television sets, before taking a definitive view on the matter, an
Re: [unicode] Re: FW: Inappropriate Proposals FAQ
At 10:37 am -0700 2002-07-05, David Possin wrote: >Aztec glyphs: Some of the glyphs are identical in shape and form, but a >certain colored area changes the meaning if a different color is >applied. When Michael Everson asked for proof, both Marco Cimarosti and >I sent him links to websites that state this color issue. Silence. What did you want me to say? Aztec hasn't been fully deciphered yet, it seems. I did mention Budge's use of a black line over rubricked Egyptian text. If we encountered a script in which colour was really intrinsic we might have to deal with it, but in the real world such a convention would be pretty unstable. How would you carve your name into a tree with a knife if you had no ink with you and D was black but d was blue? >Ethiopian writing: Daniel Yacob described the usage of red dots, >accents, and words in that writing system, nobody except WO followed up >with the significance of Daniel's statements. Silence, even though he >wrote "The capability to the same electronically would be well >received. Would markup not do? >I see two valid possible proposals here to add a color attribute to a >character. What will happen if a need for these characters is >discovered, a consortium with the necessary background is formed, and >the UTC receives an orderly proposal? In Quark I can add colour attributes to a character for printing. We would consider an orderly proposal on its merits. -- Michael Everson *** Everson Typography *** http://www.evertype.com
RE: [unicode] Re: FW: Inappropriate Proposals FAQ
David Possin wrote:
> But, if something it silently ignored, then somebody has discovered
> something that nobody wants to touch. I have observed this sevaral
> times now, the latest incident was in the Chromatic Font Research
> thread, with 2 cases:
>
> Aztec glyphs: [...] Silence.
Funny. I interpreted that silence the opposite way: very positively. I
didn't expect any immediate action, and the absence of denials made me feel
the information I passed was not totally pointless.
Anyway, even if the silence actually meant "Who cares?", it doesn't bother
me, because I think this is NOT an issue for Unicode.
"Unicode encodes character, not glyphs!" Whether the glyphs representing
those characters are colored or not, the only problem for Unicode would be
having four-color printing for a future edition of the Unicode Standard...
The problem (if there is one!) is only for font technology.
> Ethiopian writing: [...] "The capability to the same electronically
> would be well received. /Daniel."
Same for this one: Unicode's task was to provide a code point for the
Ethiopic full stop, and they did. Whether the corresponding glyph is colored
or not is problem for fonts and word processors.
However, there has been one case when Unicode's silence disturbed me, and
this was when I (et al.) raised a real encoding problem, although certainly
a minor one. It had to do with encoding "repha" out of context ("repha" is
one of the contextual glyphs of letter RA in some Indic scripts).
_ Marco
Re: [unicode] Re: FW: Inappropriate Proposals FAQ
Resending this email because for some reason my membership in the Unicode list got deleted. --- Rick McGowan <[EMAIL PROTECTED]> wrote: > Suzanne T asked: > > > Can people from the review committee give me some hard and fast > > rules for when something is thrown out? > > --snip-- > One rule of thumb that people can also use: if an off-the-cuff > proposal > for a thing doesn't fly on the Unicode list, it is unlikely to fly in > UTC. > > Rick > I have noticed something else in this aspect. If an idea gets bashed on the Unicode list it won't make it, and almost all the time I agree that it shouldn't make it. But, if something it silently ignored, then somebody has discovered something that nobody wants to touch. I have observed this sevaral times now, the latest incident was in the Chromatic Font Research thread, with 2 cases: Aztec glyphs: Some of the glyphs are identical in shape and form, but a certain colored area changes the meaning if a different color is applied. When Michael Everson asked for proof, both Marco Cimarosti and I sent him links to websites that state this color issue. Silence. Ethiopian writing: Daniel Yacob described the usage of red dots, accents, and words in that writing system, nobody except WO followed up with the significance of Daniel's statements. Silence, even though he wrote "The capability to the same electronically would be well received. /Daniel." I see two valid possible proposals here to add a color attribute to a character. What will happen if a need for these characters is discovered, a consortium with the necessary background is formed, and the UTC receives an orderly proposal? Between all the arguing and mile long emails nobody actually saw this possibility, or wanted to see the valid issues for a proposal. I believe it is necessary to invest some thought into what a color implementation would mean for Unicode, not for a holly with red berries, but for a real writing system. The silence after these valid statements were made disturbs me. Dave = 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: FW: Inappropriate Proposals FAQ
Otto Stolz wrote: >> I noticed in particular that the characters are non-contiguous >> within themselves. > > This is not enough to decide what constitutes a character. E. g. the > cyrillic character "?" is non-contiguous; in the Latin script, when > "f" and "l" are ligated, they still constitute two characters. For that matter, the dot over lowercase "i" and "j" make those glyphs non-contiguous as well. -Doug Ewell Fullerton, California
Re: FW: Inappropriate Proposals FAQ
On Thursday, July 4, 2002, at 09:07 AM, Otto Stolz wrote: > Michael Everson wrote: >> That, and the fact that it hasn't been deciphered. > > > Which implies that you really cannot tell what constitutes a character, > in that script, nor its writing-direction. > > Actually, you can't even tell *that* it's a script, not for sure. But if it *is* writing, then the nature of the characters seems fairly unambiguous as the various signs are self-contained and don't break down into smaller pieces. It would appear to be a syllabary. Also IIRC the writing direction has been deduced by determining the order in which the characters were stamped into the clay (as indicated by overlaps). I should mention that the proposals for the encoding of the Phaistos disc are the only proposals made to the UTC and WG2 which contain the entire known corpus of writing with that script as a part of the proposal. :-) == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: FW: Inappropriate Proposals FAQ
At 17:07 +0200 2002-07-04, Otto Stolz wrote: >Michael Everson wrote: >>That, and the fact that it hasn't been deciphered. > >Which implies that you really cannot tell what constitutes a character, >in that script, nor its writing-direction. Actually it appears that the writing direction is into the faces of the characters, and that the impression in the clay indicates that this was the likely direction of printing. And as far as the repertoire is concerned, it is small and each character is easily differentiated from the others. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: FW: Inappropriate Proposals FAQ
William Overington had written: > the proposal for encoding of the Phaistos Disk Script into Unicode > [...] was rejected. Is this really for a purported reason that the > script is only found on one item at present? Michael Everson wrote: > That, and the fact that it hasn't been deciphered. Which implies that you really cannot tell what constitutes a character, in that script, nor its writing-direction. William Overington had written: > I noticed in particular that the characters are non-contiguous within > themselves. This is not enough to decide what constitutes a character. E. g. the cyrillic character "Ы" is non-contiguous; in the Latin script, when "f" and "l" are ligated, they still constitute two characters. Best wishes, Otto Stolz
Re: FW: Inappropriate Proposals FAQ
At 05:22 +0100 2002-07-04, William Overington wrote: >Has the Unicode Technical >Committee in fact ever discussed the possibility of whether or not to encode >chess diagrams in regular Unicode at all? No, but I suspect that if they were to do so they would quickly come to the conclusion that markup was best for describing the chess board into which the chess characters were arranged. >One script which the Unicode Technical Committee has turned down is the >Phaistos Disk Script. There is a document, which if I may say so is of high >quality, about the proposal for encoding of the Phaistos Disk Script into >Unicode, into Plane 1. It was rejected. Is this really for a purported >reason that the script is only found on one item at present? That, and the fact that it hasn't been deciphered. >How about discussing the Phaistos Disk Script in this new FAQ document? How about not? General aphorisms are better in this case. >As for the script regarding the cipher in relation to a movie. I feel that >the characters are very elegant and I noticed in particular that the >characters are non-contiguous within themselves. The point made was that the writing system was cumbersome and inefficient qua writing system. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: FW: Inappropriate Proposals FAQ
Marco Cimarosti wrote as follows. >William Overington wrote: >> As for the script regarding the cipher in relation to a >> movie. [...] > >Which one? Doug mentioned three movies: "Men in Black II", "Indiana Jones >and the Temple of Doom", "Atlantis: The Lost Empire". > >_ Marco > The Men in Black II one to which Ken referred in the post to which I was replying. William Overington 4 July 2002
RE: FW: Inappropriate Proposals FAQ
William Overington wrote: > As for the script regarding the cipher in relation to a > movie. [...] Which one? Doug mentioned three movies: "Men in Black II", "Indiana Jones and the Temple of Doom", "Atlantis: The Lost Empire". _ Marco
Re: FW: Inappropriate Proposals FAQ
Ken Whistler wrote as follows. >But if a "script", like the MIIB BurgerKing cipher mentioned today, >or chess diagram notation, is missing from the Roadmap, there is probably >a *good* reason for it not to be there, and people should think twice >(and then again) before they start proposing it for encoding in Unicode. Well, there may or may not be a good reason for something missing from the Roadmap, one good reason possibly being that nobody has suggested something before. I make this point since you mention chess diagram notation. I have recently published some Private Use Area code point allocations for chess diagrams. http://www.users.globalnet.co.uk/~ngo/chess.htm http://www.users.globalnet.co.uk/~ngo/chess2.htm http://www.users.globalnet.co.uk/~ngo/golden.htm I am well aware that some people are not interested in my publishing of Private Use Area allocations, but I am stating the matter here since you mentioned chess diagram encoding and said that there is probably a good reason for it not being in the Roadmap. Has the Unicode Technical Committee in fact ever discussed the possibility of whether or not to encode chess diagrams in regular Unicode at all? Just because something has not arisen before and has never been discussed by members of the 1 dollars a year for a vote group does not in any way make that matter questionable in any way whatsoever. One script which the Unicode Technical Committee has turned down is the Phaistos Disk Script. There is a document, which if I may say so is of high quality, about the proposal for encoding of the Phaistos Disk Script into Unicode, into Plane 1. It was rejected. Is this really for a purported reason that the script is only found on one item at present? I find that a strange thing. I feel that that proposal should be looked at again by the committee. How about discussing the Phaistos Disk Script in this new FAQ document? As for the script regarding the cipher in relation to a movie. I feel that the characters are very elegant and I noticed in particular that the characters are non-contiguous within themselves. Examining the gif file in some detail I find that a lot of care has been taken in preparing those characters and I wonder if anyone knows what are the design influences underlying the design please. Is the designer perhaps reading this list and perhaps would like to comment please? William Overington 4 July 2002
Re: FW: Inappropriate Proposals FAQ
At 12:17 -0700 2002-07-03, Kenneth Whistler wrote: >If a script is listed there in the Roadmap for the BMP or for Plane 1, >then people can be assured that interested members of the encoding >committees have *already* made a tentative determination that >the script is suitable for encoding, although a proposal may not >actually exist yet, and of course, there are no guarantees until the >committees actually do the work on fully filled-out formal proposals. Indeed, we might end up unifying Javanese and Balinese for instance. We don't know just now. >But if a "script", like the MIIB BurgerKing cipher mentioned today, >or chess diagram notation, is missing from the Roadmap, there is probably >a *good* reason for it not to be there, and people should think twice >(and then again) before they start proposing it for encoding in Unicode. Well... a year ago we hadn't heard of N'Ko. Things turn up all the time. >The "voice which shook the earth", from Chapter IV, verse 44 of >LIBER LIBERI vel LAPIDIS LAZULI ADUMBRATIO KABBAL GYPTIORUM, >one of the Holy Books of Thelema: > >http://www.nuit.org/thelema/Library/HolyBooks/LibVII.html Wow. Or indeed UAOAU -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: FW: Inappropriate Proposals FAQ
Suzanne, > Can people from the review committee give me some hard and fast rules for > when something is thrown out? As Michael Everson indicated, the answer to this is probably not. However, perhaps the most important thing for serious script proposers to do, to see if what they are concerned about might be acceptable, is to consult the Roadmap: http://www.unicode.org/roadmaps/ If a script is listed there in the Roadmap for the BMP or for Plane 1, then people can be assured that interested members of the encoding committees have *already* made a tentative determination that the script is suitable for encoding, although a proposal may not actually exist yet, and of course, there are no guarantees until the committees actually do the work on fully filled-out formal proposals. But if a "script", like the MIIB BurgerKing cipher mentioned today, or chess diagram notation, is missing from the Roadmap, there is probably a *good* reason for it not to be there, and people should think twice (and then again) before they start proposing it for encoding in Unicode. --Ken Another "missing" example: The "voice which shook the earth", from Chapter IV, verse 44 of LIBER LIBERI vel LAPIDIS LAZULI ADUMBRATIO KABBALÆ ÆGYPTIORUM, one of the Holy Books of Thelema: http://www.nuit.org/thelema/Library/HolyBooks/LibVII.html Disclaimer: The UTC New Scripts committee does not discriminate among script applicants on the basis of race, color, gender, religion, sexual orientation, national or ethnic origin, age, disability, or veteran status. However, if they are risible, we reserve the right to laugh. ;-)
Re: FW: Inappropriate Proposals FAQ
On Wednesday, July 3, 2002, at 11:57 AM, Asmus Freytag wrote: > Klingon (or any of the Latin ciphers/ movie scripts) > > I'd say Klingon *and* one of the Latin ciphers. Klingon is almost worth a FAQ in itself. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com/jenkins/
Re: FW: Inappropriate Proposals FAQ
At 12:59 -0400 2002-07-03, Suzanne M. Topping wrote: >Can people from the review committee give me some hard and fast rules for >when something is thrown out? I suspect we cannot. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: FW: Inappropriate Proposals FAQ
This looks like a lot of work and it looks like it duplicates as lot of the
work in the "submitting new proposals" section of instructions on our
website and in the standard.
We are getting a large number of *informal* suggestions for proposals that
are more or less clearly inappropriate and spend some amount of time on the
list dealing with them. However, neither UTC nor ISO/IEC JTC1/SC2/WG2 are
receiving a large number of inappropriate *formal* proposals. In fact, both
groups few proposals that don't have active support or involvement of
people active in either or both bodies - ad those people don't need an FAQ.
I submit that, while an interesting excercise, such a FAQ is a solution in
search of a problem. Having a FAQ will not do anything to keep enthusiasts
from storming in with their latest brain child - since it's the nature of
these informal suggestions that people never read the FAQ (any FAQ) before
hitting the send button. (OK, maybe some do).
At the same time, there's the risk that we maintain TWO sets of information
on the same topic ("what's an acceptable proposal"), with all the
maintenance issues and issues of which text is the binding one.
I suggest that we either not do a FAQ, or do a very simple one of a few
(three?) proposals that have definitely failed (or would definitely fail)
as illustrations, just to establish the idea that there are inappropriate
proposals, and then firmly point to the *official* document that sets out
the criteria for creating a *formal* proposal.
My favorite examples are
Klingon (or any of the Latin ciphers/ movie scripts)
Hexadecimal digits or 'Decimal separator'
Any proposal asking for the rearrangement/removal of characters
The decimal separator is a clear example of coding something that is
already encoded using a different model and coding a character purely by
function, which Unicode tends to be leery of, esp. if it can't be visually
distinguished from existing characters.
I would definitely NOT like to see a detailed typology of proposals in a
FAQ, with detailed script classifications etc.
A./
At 12:59 PM 7/3/02 -0400, Suzanne M. Topping wrote:
>I realized that I should probably turn an off-list discussion back to
>the list, as it's illustrating an area of difficulty. (See the bottom of
>this note for a partial discussion of what writing systems could/would
>be considered.)
>
>In the "appropriate use" FAQ entry, how the heck can we state what is
>and isn't a suitable writing system for inclusion? Fictional scripts in
>some cases would be considered, in other cases would not. Historical
>scripts would in some cases be considered, in other cases not. Can
>people from the review committee give me some hard and fast rules for
>when something is thrown out?
>
>Is there some way of listing or detailing the criteria in a way which
>potential readers could determine where theire script or character
>stands? It could perhaps be presented in a table or matrix form, so that
>people could look through the criteria and say "yep, it's fictional, yep
>people currently use it, no, there are no fonts yet" etc. Or maybe a
>decision tree would be better, where the criteria forks.
>
>I guess the first thing I need to collect is the criteria... Here are
>some starters to get the ball rolling:
>
>--Is this an entire script or additions to an existing script?
>
>--Is the script fictional?
>
>--Is the script in use? (as determined how???)
>
>--Does the character(s) already exist in some other part of the
>standard?
>
>--Is there a compelling reason for including a characther which would
>normally not be considered, due to legacy support issues?
>
>--Is the character a precomposed ligature which can be encoded using a
>sequence of existing character (possibly joined by ZWJ's)?
>
>--Is the character a precomposed "accented character" which can be
>composed using an
>existing character and one or more existing combining diacritics?
>
>--Is the character a clone of an existing character whose sole purpose
>is making a *logical* differentiation from some existing characters
>(e.g., hex digits looking
>identical to existing characters "0..9" and "A...F"; or a symbol for
>"meter"
>looking identical to Latin "m")?
>
>--Is the chracter a clone of an existing character whose sole purpose is
>making a
>*graphical* differentiation from some existing characters (e.g., a
>Serbian
>letter "t", disunified from Russian on the basis that italics looks
>different in the two languages)?
>
>--Is the character really a presentation glyph for a shape that can be
>obtained using regular characters in conjunction with ZWJ or ZWNJ?
>
>Again, additions, suggestions, or other help appreciated,
>
>Suzanne
>
>
>-Original Message-
>
>
>At 15:35 -0400 2002-07-02, Suzanne M. Topping wrote:
>
> >Apologies, I was sloppy with my phrasing; of course a script is
> >"written". What I really meant was that the script is in current use in
> >some sort of written form, as opposed
Re: FW: Inappropriate Proposals FAQ
Suzanne T asked: > Can people from the review committee give me some hard and fast > rules for when something is thrown out? There's only one hard and fast rule that I know: when a majority of UTC members vote to NOT encode something. I think the criteria that UTC representatives use to determine their votes would be along the lines of Suzanne's checklist. She might be able to come up with a list of questions such that some specific negative or positive answers would lead one to the conclusion that it is or isn't worth submitting a proposal for some specified thing. One rule of thumb that people can also use: if an off-the-cuff proposal for a thing doesn't fly on the Unicode list, it is unlikely to fly in UTC. Rick
