Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated)
At 12:33 AM 1/27/02 -0800, Mark Davis \(jtcsv\) wrote: I find it fairly pointless to say that a font supports the variation selection sequence U+03B8, U+FE00 if it does not provide a visual distinction from U+03B8; and such a distinction should be based on the entry description. Thus, of the following four fonts, only number 4 correctly supports the sequence U+03B8, U+FE00. (Of course, any real font would have designs for the two glyphs that were a bit more harmonious!) I couldn't view your examples, but guessing at what they might have been, I'll risk an answer. The problem is that some of the distinctions for which variant selectors are used, are *needed only by a minority of users*. Some of the math variants (not PHI, or THETA, but the ones in StandardizedVariants) may only be needed by *some* math authors. Any requirement that by supporting VS1, one must restrict the glyph range of the unmarked symbol forces either a) the tail to wag the dog or b) many dogs to do without tail Case a is where fonts assume the most restrictive glyph choice for the unmarked symbol, so that they can be used by all users. This is bad since the restricted glyph range for the unmarked symbol may be a somewhat unnatural one. Given the expense of creating a math font, it may not make sense to do one that is not usable by all math authors. Case b is where fonts assert their choice of unmarked glyph and (because of the required contrast) choose not to support the VS1 form, since that's the form they want to use as the unmarked default. Given the expense of creating a math font, the sub-set of math authors may not have the werewithal to source a font for their needs, since most of the market can be covered by something that is 'good enough'. By explicitly defining a way to restrict the glyph range (via coding another character, or another VS sequence) it becomes easier to support groups with related needs, but different requirements in the face of variants. A./
Re: Additional Ethiopic characters?
At 18:59 -0800 2002-01-26, John Hudson wrote: What is the status of ISO/IEC JTC1/SC2/WG2 N1846, the Proposal to encode Ethiopic Extensions in the BMP...? I see that (Eth.Ext.) is included in the BMP roadmap, but don't see any other information on the Unicode site. Daniel Yacob was to get me samples of the characters in use, so we could update the proposal. That hasn't happened yet. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: POSITIVELY MUST READ! Bytext is here!
At 17:54 -0500 2002-01-26, [EMAIL PROTECTED] wrote: One of my favorite parts of Bytext was the section on Emoticons. Certainly, one thing that a serious competitor to Unicode must have is a rich set of emoticons as single characters. I've always felt the UTC was badly out of touch with the user community by neglecting to encode TIRED-BORED FACE, QUESY [sic] FACE, YUKKY FACE, and DROOLING FACE. MISTER YUCK, actually, should be added to Unicode. Isn't it used on some poisonous cleaning products to warn children? As far as Bytext goes, well, in my opinion, if the author had given as much energy to working on the Unicode standard as he did writing up that thesis of his, perhaps the end of his tweens might have been more fruitful. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Additional Ethiopic characters?
I suppose I should also say that Daniel and I are in touch and progress is being made, however slowly. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: POSITIVELY MUST READ! Bytext is here!
Michael Everson wrote, MISTER YUCK, actually, should be added to Unicode. Isn't it used on some poisonous cleaning products to warn children? If so, perhaps it is a glyph variant of skull and crossbones at U+2620 (☠). Best regards, James Kass.
Re: POSITIVELY MUST READ! Bytext is here!
At 06:56 -0800 2002-01-27, James Kass wrote: MISTER YUCK, actually, should be added to Unicode. Isn't it used on some poisonous cleaning products to warn children? If so, perhaps it is a glyph variant of skull and crossbones at U+2620 (òÝ). I don't think it is. Indeed it was introduced precisely because toddlers don't understand the skull and crossbones. They may both denote poison, but they are different things. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Additional Ethiopic characters?
Daniel Yacob was to get me samples of the characters in use, so we could update the proposal. That hasn't happened yet. All good things come to those who wait./Hannibal ..and lots of good things are coming, however slowly ;)
Re: POSITIVELY MUST READ! Bytext is here!
Michael Everson wrote, (MISTER YUCK) If so, perhaps it is a glyph variant of skull and crossbones at U+2620 ([Gratuitous UTF-8 Skull and Crossbones]). I don't think it is. Indeed it was introduced precisely because toddlers don't understand the skull and crossbones. They may both denote poison, but they are different things. Neither do I, really. It was a whimsical statement. Should've used a smiley. MORE WHIMSEY Maybe emoticons should be considered as variants of the smiley, and could be specifically provided for with variant selectors. /MORE WHIMSEY Seriously, the section in the bytext file about emoticons was most enjoyable. Do people exchange information using emoticons? MISTER YUCK: graphic or symbol? Best regards, James Kass.
Re: POSITIVELY MUST READ! Bytext is here!
James Kass wrote: Seriously, the section in the bytext file about emoticons was most enjoyable. Do people exchange information using emoticons? MISTER YUCK: graphic or symbol? Do people use exclamation marks to communicate ;-) P. Andries
Re: POSITIVELY MUST READ! Bytext is here!
At 08:41 -0800 2002-01-27, James Kass wrote: Seriously, the section in the bytext file about emoticons was most enjoyable. Do people exchange information using emoticons? Yes, but these are representable in plain text by Unicode now. ASCII! MISTER YUCK: graphic or symbol? Symbol. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated)
Sorry, I guess not all mailers handle embedded graphics in HTML messages. I posted it so that you could see the graphics, on http://www.macchiato.com/utc/variation_selection/variation_selection_followu p.htm It is *not* exactly the same. I added and rearranged the concrete examples at the very end. I think those last examples of the font are key to this issue: depending on which we say conformantly support the variation sequence will help determine how we handle this issue. I also posted my previous paper, although my thinking has changed a bit since then, particularly on the 'tightness' of the description -- the paragraph containing Suppose a glyph has a slash with an angle of 32° from vertical. http://www.macchiato.com/utc/variation_selection/variation_selection.htm Mark — Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com - Original Message - From: Asmus Freytag [EMAIL PROTECTED] To: Mark Davis (jtcsv) [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 01:36 Subject: Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated) Now this message was clear as mud. Literally. As in totally opaque in the pure visual sense: All the examples show as nice gray boxes in my mailer - please make sure whatever you are sending is an attachment, and not in-line. Thanks, A./ (PS: They may well arrive in viewable condition when this reply gets back to you..., but I can't read it) — Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com - Original Message - From: Asmus Freytag [EMAIL PROTECTED] To: Mark Davis (jtcsv) [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 01:36 Subject: Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated) Now this message was clear as mud. Literally. As in totally opaque in the pure visual sense: All the examples show as nice gray boxes in my mailer - please make sure whatever you are sending is an attachment, and not in-line. Thanks, A./ (PS: They may well arrive in viewable condition when this reply gets back to you..., but I can't read it) At 12:33 AM 1/27/02 -0800, you wrote:  The other possibility is to say that to be strictly Unicode-conformant, fonts should always use the reference glyph for unmarked characters (ignoring differences only of style). I think this is actually a better Boy, great minds to think alike. Mark Davis just proposed that in a paper to the UTC this week. I would like to thank you for the compliment, but I must not have been clear in my paper, since that is not really what I was proposing. Let me try again, with a concrete case. Since I don't have a variety of math fonts, I will use the example of U+03B8 greek small letter theta. This character can be represented by the following glyphs (collected on my system) and many more. Any of these are acceptable, conformant representations of the theta, depending on the design of the font. 1f908bf2.jpg Now, there is already a presentation form for the open form of the theta, at U+03D1 greek theta Symbol. A presentation form of a character represents the same abstract character, but is restricted in format to a subset of the possible glyphs that could represent the character, such as the following: 1f908db5.jpg But suppose there were no such character. In that case, we might add an encoded variant, expressed as an entry in the StandardizedVariants.html file in the UCD, looking something like: Ref Glyph Character Sequence Alt Glyph Description of variant appearance 1f908e05.jpg 03B8, FE00 1f908e4b.jpg Open Theta, unconnected on the left side Now there are four key facts that we need to keep in mind: * This does not, at all, prevent the character alone U+03B8 from having the same appearance as what is titled as the Alt Glyph. It is still a perfectly acceptable representation of that character in normal text. * What is titled Alt Glyph in this entry is also merely a representative, one of many possible glyphs that can represent the variant. Thus both of the glyphs are representative: they do not, and cannot, encompass all of the possible glyphs that can represent either the character alone, or the variant. (It would be a good idea for us to change the title of this column, since it may mislead some into thinking that that precise glyph must be used: it should be Variant Ref Glyph.) * A key feature of the entry is the description; it provides the limitation on the set of glyphs that can be used to represent the sequence, if the sequence is supported by a font. * If a font does not support the variation sequence given by this entry, that it is also perfectly acceptable to ignore the U+FE00, and thus render the sequence U+03B8, U+FE00 with precisely the same glyph as the single character U+03B8. So the open
Re: POSITIVELY MUST READ! Bytext is here!
At 06:56 AM 1/27/02, James Kass wrote: If so, perhaps it is a glyph variant of skull and crossbones at U+2620 (â ). cheek contents=tongue amount=50% I would argue against unification: the skull and crossed bones has additional meanings beyond poison. Although the vision of Disney's Pirates of the Caribbean flying the Yucky Roger is enticing, I can imagine the need for plain text use of U+2620 where the alternate glyph simply wouldn't do. /cheek -- Curtis Clark http://www.csupomona.edu/~jcclark/ Mockingbird Font Works http://www.mockfont.com/
Re: Variation Selection
At 10:00 -0800 2002-01-27, Mark Davis \(jtcsv\) wrote: Sorry, I guess not all mailers handle embedded graphics in HTML messages. In the first place they do not all handle the, though I saw it. In the second place, Mark, you must remember that not all of us live in the US where a local call is free and many of you have broadband. If you doubt this you should look at my monthly phone bill, of which an enormous percentage is internet connection time. Metered by the minute. Check out the IrelandOffline link on my website if you want to know more. Unicode list policy is to NOT send attachments to the lists. Please post to your server and send the URLs. Thank you. -- Michael Everson *** Everson Typography *** http://www.evertype.com
Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated)
It sounds like what you are saying, in concrete terms, is that Font #6 at the bottom of: http://www.macchiato.com/utc/variation_selection/variation_selection_f ollowup.htm is conformant. If that is so, then we would have to have an additional VS to select the closed form of the glyph. In that case, one could only depend on a visual distinction based upon the description if the font supported both of the VS sequences. I can see your point. Mark — Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com - Original Message - From: Asmus Freytag [EMAIL PROTECTED] To: Mark Davis (jtcsv) [EMAIL PROTECTED]; David Hopwood [EMAIL PROTECTED]; [EMAIL PROTECTED]; Unicore [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 01:49 Subject: Re: Variation Selection (Was Re: Unicode 3.2: BETA files updated) At 12:33 AM 1/27/02 -0800, Mark Davis \(jtcsv\) wrote: I find it fairly pointless to say that a font supports the variation selection sequence U+03B8, U+FE00 if it does not provide a visual distinction from U+03B8; and such a distinction should be based on the entry description. Thus, of the following four fonts, only number 4 correctly supports the sequence U+03B8, U+FE00. (Of course, any real font would have designs for the two glyphs that were a bit more harmonious!) I couldn't view your examples, but guessing at what they might have been, I'll risk an answer. The problem is that some of the distinctions for which variant selectors are used, are *needed only by a minority of users*. Some of the math variants (not PHI, or THETA, but the ones in StandardizedVariants) may only be needed by *some* math authors. Any requirement that by supporting VS1, one must restrict the glyph range of the unmarked symbol forces either a) the tail to wag the dog or b) many dogs to do without tail Case a is where fonts assume the most restrictive glyph choice for the unmarked symbol, so that they can be used by all users. This is bad since the restricted glyph range for the unmarked symbol may be a somewhat unnatural one. Given the expense of creating a math font, it may not make sense to do one that is not usable by all math authors. Case b is where fonts assert their choice of unmarked glyph and (because of the required contrast) choose not to support the VS1 form, since that's the form they want to use as the unmarked default. Given the expense of creating a math font, the sub-set of math authors may not have the werewithal to source a font for their needs, since most of the market can be covered by something that is 'good enough'. By explicitly defining a way to restrict the glyph range (via coding another character, or another VS sequence) it becomes easier to support groups with related needs, but different requirements in the face of variants. A./
Re: POSITIVELY MUST READ! Bytext is here!
Michael Everson wrote, ... graphic or symbol? Symbol. -- Because it signifies something specific while a graphic would be subject to random interpretations. Curtis Clark wrote, I would argue against unification: the skull and crossed bones has additional meanings beyond poison. Although the vision of Disney's Pirates of the Caribbean flying the Yucky Roger is enticing, ... Quite enticing. And the notion of making emoticons variants of the smiley because facial expressions are variations of the face is out, too, as the various glyphs each signify something completely different from smiley. Patrick Andries wrote, Do people use exclamation marks to communicate ;-) Yes! Best regards, James Kass.
Re: Variation Selection
Unicode list policy is to NOT send attachments to the lists. Please post to your server and send the URLs. First, have we all servers? Second, if it is a small attachment, the number of bytes transmitted to GO there may well be greater than the number to send the bloody thing. How about an arbitrary attachment limit of 1535 ($B8lO$9g$o$;!'$R$a$_$3(B) bytes? $B"*!!$8$e$&$$$C$A$c$s!!"+(B $B!!$@$s$;$$$i$7$5$`$h$&(B _ $B4JC1$K=PMh$k3Z$7$$%"%k%P%`!#M'C#$KEO$9$N$b%a!<%k$G4JC1$K!*(B http://photos.msn.co.jp/
Re: Variation Selection
At 10:29 PM 1/27/2002 -0500, you wrote: In a message dated 2002-01-27 18:51:35 Pacific Standard Time, [EMAIL PROTECTED] writes: First, have we all servers? No. Assuming we all do is no better than assuming we all have broadband or T1 connections. Yes, we do all have servers: Yahoo is your friend - you can get an unlimited number of 6mb (I think, maybe more) accounts for free. Store images in briefcase.yahoo.com/yourid. Store any files in briefcase.yahoo.com/yourid. Also, this list is mirrored on a yahoo group. the group has storage space too. I don't know ho the moderator of that group is, but maybe he/she can assist. In any of these cases, all that needs to be passed to the list is the url. Frankly, the issue of unexpected attachments in email is not the size for me, but it does cause me security concerns. I would much rather decide whether or not to download a file then to wake up one morning with a virus or worse. Best Regards, Barry Caplan [EMAIL PROTECTED] www.i18n.com - coming soon, preview available now News | Tools | Process for Global Software Team I18N
attachment size (was: Re: Variation Selection)
From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Variation Selection Date: Sun, 27 Jan 2002 22:29:02 EST In a message dated 2002-01-27 18:51:35 Pacific Standard Time, [EMAIL PROTECTED] writes: First, have we all servers? No. Assuming we all do is no better than assuming we all have broadband or T1 connections. Second, if it is a small attachment, the number of bytes transmitted to GO there may well be greater than the number to send the bloody thing. How about an arbitrary attachment limit of 1535 ($B%JDE%'%RW$%D:d(B$B!#c`TE%ec`TD%1%D!'c`(B $BTE@d(B$BTE^d(B$BTEZd(B$BTD%"(B) bytes? I just sent a 500-byte attachment to the Unicode list without any qualms. Almost all messages are longer than 500 bytes, especially when you take headers into account. However, there is certainly such a thing as "too long," and I have no idea where to draw the line and say "this attachment is short enough, that one is too long." -Doug Ewell Fullerton, California I just said 1535 because I like the word "himemiko". Also, it is just under 1 1/2 KB, and that attachment size is good for small black-and-white illustrations (for character placement, etc.) Some Swedish (?) person came up with an excellent use for some illustrations about a month ago, when discussing a Swedish ampersand and a few other characters on this list. Also, Sarasvati's birth year should be an agreeable number for her to use as a file size limit. And since I never give a lady's age, remember, it is not necessarily a Gregorian year! $B"*!!$8$e$&$$$C$A$c$s!!"+(B $B!!$@$s$;$$$i$7$5$`$h$&(B _ $B%a!<%k%5!<%S%9$O!"@$3&(B No.1 $B$N(B MSN Hotmail $B$G!*(Bhttp://www.hotmail.com/JA/
Re: Variation Selection
In a message dated 2002-01-27 18:51:35 Pacific Standard Time, [EMAIL PROTECTED] writes: First, have we all servers? No. Assuming we all do is no better than assuming we all have broadband or T1 connections. Second, if it is a small attachment, the number of bytes transmitted to GO there may well be greater than the number to send the bloody thing. How about an arbitrary attachment limit of 1535 (Œê˜C‡‚킹F‚Ђ߂݂±) bytes? I just sent a 500-byte attachment to the Unicode list without any qualms. Almost all messages are longer than 500 bytes, especially when you take headers into account. However, there is certainly such a thing as too long, and I have no idea where to draw the line and say this attachment is short enough, that one is too long. -Doug Ewell Fullerton, California
Re: attachment size
Dear Little Ones: Michael E suggested: Unicode list policy is to NOT send attachments to the lists. to which Doug E. replied: I just sent a 500-byte attachment to the Unicode list without any qualms. The policy is rather to let the piranhas chew up people who send huge attachments. Little attachment are not troublesome. This list has a 52k limit on message body size, regardless of content, and there is not a specific policy that I care to enforce about little attachments or mail formats. Use good judgement, please. Little [EMAIL PROTECTED] at hotmail.com suggested using or Sarasvati's birth year. However, in terms of C.E., that is an inappropriately large negative number. By the way, the other day on this list Michael K called out my name, but I thought you all were reaching the correct conclusion without interference, and I see the controversy has blown over. Cheery regards from your, -- Sarasvati
