From sai at fiatfiendum.org Thu Jun 6 12:45:34 2024 From: sai at fiatfiendum.org (Sai) Date: Thu, 6 Jun 2024 18:45:34 +0100 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji Message-ID: Dear Unicode Consortium and implementers, # Reference and background The emoji ??? (and the various gender, skin tone & facing variants) represent blind people using a long white guide cane. (I'm one, hi.) My thanks to Ash Holland, CCed, who found the issue below and pointed it out to me. The text below is my own. ## Terminology Per World Blind Union (WBU) norms, I use the term "blind" to include anyone with visual disability sufficient to benefit from a cane. This includes "visually impaired" (VI), "partially sighted", etc. Equipment terminology varies by country. The kind of cane used by blind people for walking at speed in public, typically sternum to forehead length and covered in mostly white reflective tape, is called a "guide cane", "long cane", and/or "white cane". Some manufacturers, notably Ambutech (one of the largest), use "mobility cane". I'm going to just use "cane" to refer to this. In the UK, but not US, "guide cane" refers to a very short (lower than sternum, roughly waist to ribs length) cane which can be used for limited mobility, as opposed to "long cane" which has the meaning above. (In the US these terms are synonymous for the long version, and short canes like this aren't really a thing.) "ID cane" or "symbol cane" is a very short cane, not long enough to touch the ground, used for signaling purposes (and light indoor use), not navigation. Countries differ in colour usage. Globally, an all white cane always means some type of blindness. In the US, all white or white with one red section canes are default and interchangeable; two separate red sections indicate deaf-blind. In the UK and other countries, one red section may indicate deaf-blind. Some South American countries use green, orange, and other colours as well, e.g. to indicate visually impaired as opposed to totally blind. And, worldwide, other colours are sometimes used just for fun or fashion. The above are all used specifically by blind people. These are distinct from a "support cane", like a hiking stick, which is used by both sighted and blind people with mobility issues like strength, stamina, or balance. (Including me ? I walk with both a cane and white-taped hiking stick.) ## Unicode of cane use emoji The cane emoji solo is https://www.unicode.org/emoji/charts/emoji-list.html#1f9af 1355 U+1F9AF [image: ?] white cane accessibility | blind | white cane The person using cane are all ZWJ emoji, not solo codepoints https://www.unicode.org/emoji/charts/emoji-list.html#1f9d1_200d_1f9af 423 U+1F9D1 U+200D U+1F9AF ??? person with white cane accessibility | blind | person with white cane 424 U+1F9D1 U+200D U+1F9AF U+200D U+27A1 U+FE0F ?????? ? person with white cane facing right 425 U+1F468 U+200D U+1F9AF ??? man with white cane accessibility | blind | man | man with white cane 426 U+1F468 U+200D U+1F9AF U+200D U+27A1 U+FE0F ?????? ? man with white cane facing right 427 U+1F469 U+200D U+1F9AF ??? woman with white cane accessibility | blind | woman | woman with white cane 428 U+1F469 U+200D U+1F9AF U+200D U+27A1 U+FE0F ?????? ? woman with white cane facing right These also all take skin tone variants, e.g. person with white cane dark skin tone ????. # The problem with current cane emoji In nearly all implementations listed at https://emojis.wiki/person-with-white-cane/ , these are depicted with the person having their hand through the cane's bungee loop as if it were a wrist strap. This is both wrong and, as an implicit norm/suggestion, it is dangerous misinformation that may cause real world fatalities to cane users. Not all canes have bungee loops ? fixed length or telescoping canes with screw on tips often don't. For canes that do have one, the bungee loop on canes is _not_ a wrist strap, as the current emoji depictions suggest. The loop is for two primary purposes: 1. structure (for both sectional canes and canes with "hook on" type tips, which operate by bungee tension along the entire length of the cane between the top knot and the tip) 2. storage (for sectional canes, to hold them collapsed, by pulling a narrow loop around the collapsed bundle). It can also be incidentally used, when standing and holding it vertically, to rest one's hand by hooking a finger in the loop; or for hanging the cane on a wall hook or hat/coat rack. However, one should _never_ have one's hand through the loop, as depicted in these emoji. This is because if the tip gets caught on a moving jogger/bicycle/vehicle/train/etc, and the hand is through the loop, the cane user will get yanked and likely injured, possibly fatally (e.g. if dragged into a large vehicle at speed). The current emoji are therefore both: 1. inaccurate in depicting the loop as if it were a wrist strap, which it is not, and 2. actually dangerous misinformation liable to cause real world physical injuries, because they implicitly normalise the idea of misusing the loop as a wrist strap, which a current or future cane user would therefore be more likely to do, thus leading to physical injury to that person ? up to and including death. ## Specific critique of implementations, including non hazardous inaccuracies * Apple Dangerous: none. Inaccurate: lower fingers not wrapped around the grip; grip pinched between thumb and index finger. Rare: hand holding the loop. * Facebook Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white; loop with thickness of a hiking pole strap. Rare: cane is extremely short, though this is proportionate to comic style. * Google Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white. Rare: cane is short. * Microsoft Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white; cane held like a walking stick; cane coming out the pinky end; cane held at the top of the handle; cane held without a thumb; cane at different angle than forearm. Rare: cane is short. * Samsung [image: image.png] Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white; loop with thickness of a hiking pole strap. Rare: none. * Twitter Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white; cane handle with a flange like a hiking pole; hand resting over the top like a hiking pole; cane at different angle than forearm. Rare: cane is short. * WhatsApp Dangerous: use of loop as a wrist strap. Inaccurate: cane body in grey rather than white; cane held reversed, with palm facing away from the user's body; cane at different angle than forearm. Rare: none. ## Further examples in solo white cane emoji All of the above issues are likewise reflected in the implementations of emoji for a white cane alone, see https://emojis.wiki/white-cane/ For instance, Facebook's implementation [image: image.png] incorrectly depicts a hiking stick style wide wrist strap, depicted in an open manner suggesting it should be used as a wrist strap. Google's implementation [image: image.png] incorrectly depicts a wrist strap that pierces the cane handle for a load bearing design, like on a hiking stick. The bungee loop of a cane comes out the tip of the handle, since it is a structural element of the hook tip or collapsible cane assembly itself (the cane is hollow and the bungee cord runs its entire length), not an added component meant to be load bearing like on a hiking stick. Twitter's implementation [image: image.png] again shows a flange, such as on a hiking stick, which does not exist on canes; and shows the loop in an outstretched position suggesting that a hand is meant to go through it, rather than it being left alone when in use. # Requested changes ## Immediate changes Because the current implementations pose a risk of causing actual physical harm, I request the following changes be made as soon as possible. 1. Unicode: Change the implementation definition for all variants of A. the person with white cane emoji: The loop MUST NOT be around the user's wrist. The loop MAY, at implementer's discretion, a. hang downwards, b. be held against the handle by the caning hand palm, c. be tied along the cane handle, or d. be omitted entirely. B. the white cane emoji: The loop, if depicted, MUST NOT be suggestive of a wrist strap in width or positioning. 2. All implementers: Please change all cane use emoji accordingly, without waiting for a Unicode change. I suggest just removing the loop entirely. ## Normative change and extension for cane colour semantics 3. Unicode: Change the implementation definition, and add combining forms, for accuracy and to represent semantically different canes: A. Normative cane grip When depicted in use (i.e. in extended grip), the cane SHOULD be held: a. in golf grip, palm facing body b. with the caning hand palm on the outside edge of the handle c. thumb curling around over the top d. other fingers curling around under the bottom e. with cane extending out the thumb side of the hand. B. Cane colour coding The cane SHOULD be either: a. entirely white, or white with the bottom section red, at implementer's discretion (default) c. white with two bottom sections red, separated by a white section (if combined ZWJ with U+1F9CF ? DEAF PERSON) d. entirely a vibrant colour (if combined ZWJ with a colour) with "white" being as close to vibrant white as feasible given artistic style (e.g. presence of drawn outlines, 'reflective' patches, etc) and the need to be distinguishable on a white background. All implementers: Please change depictions accordingly. ## Structural change In light of this having gotten implemented in a way that indicates Unicode and implementers clearly have no experience actually using a cane, and were oblivious to the inaccuracy and possible harm of these depictions ? and it wasn't caught before now ? I also request a structural change. 4. For all current and future emoji involving disabled people or their equipment, specifically consult the largest umbrella group run by such people, and their major national or higher level member organisations, to get their feedback on the exact details of both the abstract proposal and its implementations. In the case of blind people, that umbrella group is the World Blind Union (WBU). I have therefore CCed the WBU President. I have also CCed the two largest US blind organisations, American Council of the Blind (ACB) and National Federation of the Blind (NFB). I am a member of both. Thank you in advance for your time and consideration. Sincerely, Sai President, Fiat Fiendum, Inc., a 501(c)(3) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717666957078.png Type: image/png Size: 9595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667014466.jpg Type: image/jpeg Size: 8376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667131475.png Type: image/png Size: 10973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667208523.png Type: image/png Size: 4930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667376174.png Type: image/png Size: 5982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667446450.jpg Type: image/jpeg Size: 9809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 4397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 8842 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 6912 bytes Desc: not available URL: From sai at fiatfiendum.org Thu Jun 6 15:13:17 2024 From: sai at fiatfiendum.org (Sai) Date: Thu, 6 Jun 2024 21:13:17 +0100 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: > d. other fingers curling around under the bottom Clarification: the middle through pinky fingers should be curled around under the bottom. The index finger may be extended along the top or outside, or curled under. Sincerely, Sai President, Fiat Fiendum, Inc., a 501(c)(3) Sent from my mobile phone; please excuse the concision, typos, and autocorrect errors. On Thu, 6 Jun 2024, 18:45 Sai, wrote: > Dear Unicode Consortium and implementers, > > > # Reference and background > > The emoji ??? (and the various gender, skin tone & facing variants) > represent blind people using a long white guide cane. (I'm one, hi.) > > My thanks to Ash Holland, CCed, who found the issue below and pointed it > out to me. The text below is my own. > > > ## Terminology > > Per World Blind Union (WBU) norms, I use the term "blind" to include > anyone with visual disability sufficient to benefit from a cane. This > includes "visually impaired" (VI), "partially sighted", etc. > > Equipment terminology varies by country. > > The kind of cane used by blind people for walking at speed in public, > typically sternum to forehead length and covered in mostly white reflective > tape, is called a "guide cane", "long cane", and/or "white cane". Some > manufacturers, notably Ambutech (one of the largest), use "mobility cane". > I'm going to just use "cane" to refer to this. > > In the UK, but not US, "guide cane" refers to a very short (lower than > sternum, roughly waist to ribs length) cane which can be used for limited > mobility, as opposed to "long cane" which has the meaning above. (In the US > these terms are synonymous for the long version, and short canes like this > aren't really a thing.) "ID cane" or "symbol cane" is a very short cane, > not long enough to touch the ground, used for signaling purposes (and light > indoor use), not navigation. > > Countries differ in colour usage. Globally, an all white cane always means > some type of blindness. In the US, all white or white with one red section > canes are default and interchangeable; two separate red sections indicate > deaf-blind. In the UK and other countries, one red section may indicate > deaf-blind. Some South American countries use green, orange, and other > colours as well, e.g. to indicate visually impaired as opposed to totally > blind. And, worldwide, other colours are sometimes used just for fun or > fashion. > > The above are all used specifically by blind people. These are distinct > from a "support cane", like a hiking stick, which is used by both sighted > and blind people with mobility issues like strength, stamina, or balance. > (Including me ? I walk with both a cane and white-taped hiking stick.) > > > ## Unicode of cane use emoji > > The cane emoji solo is > https://www.unicode.org/emoji/charts/emoji-list.html#1f9af > 1355 U+1F9AF [image: > ?] white > cane accessibility | blind | white cane > > > The person using cane are all ZWJ emoji, not solo codepoints > https://www.unicode.org/emoji/charts/emoji-list.html#1f9d1_200d_1f9af > 423 U+1F9D1 U+200D U+1F9AF > > ??? > person with white cane accessibility | blind | person with white cane > 424 U+1F9D1 U+200D U+1F9AF U+200D U+27A1 U+FE0F > > ?????? > ? person with white cane facing right > 425 U+1F468 U+200D U+1F9AF > > ??? > man with white cane accessibility | blind | man | man with white cane > 426 U+1F468 U+200D U+1F9AF U+200D U+27A1 U+FE0F > > ?????? > ? man with white cane facing right > 427 U+1F469 U+200D U+1F9AF > > ??? > woman with white cane accessibility | blind | woman | woman with white > cane > 428 U+1F469 U+200D U+1F9AF U+200D U+27A1 U+FE0F > > ?????? > ? woman with white cane facing right > > These also all take skin tone variants, e.g. person with white cane dark > skin tone ????. > > > > > > # The problem with current cane emoji > > In nearly all implementations listed at > https://emojis.wiki/person-with-white-cane/ , these are depicted with the > person having their hand through the cane's bungee loop as if it were a > wrist strap. > > This is both wrong and, as an implicit norm/suggestion, it is dangerous > misinformation that may cause real world fatalities to cane users. > > > Not all canes have bungee loops ? fixed length or telescoping canes with > screw on tips often don't. For canes that do have one, the bungee loop on > canes is _not_ a wrist strap, as the current emoji depictions suggest. > > The loop is for two primary purposes: > 1. structure (for both sectional canes and canes with "hook on" type tips, > which operate by bungee tension along the entire length of the cane between > the top knot and the tip) > 2. storage (for sectional canes, to hold them collapsed, by pulling a > narrow loop around the collapsed bundle). > > It can also be incidentally used, when standing and holding it vertically, > to rest one's hand by hooking a finger in the loop; or for hanging the cane > on a wall hook or hat/coat rack. > > However, one should _never_ have one's hand through the loop, as depicted > in these emoji. This is because if the tip gets caught on a moving > jogger/bicycle/vehicle/train/etc, and the hand is through the loop, the > cane user will get yanked and likely injured, possibly fatally (e.g. if > dragged into a large vehicle at speed). > > > > The current emoji are therefore both: > 1. inaccurate in depicting the loop as if it were a wrist strap, which it > is not, and > 2. actually dangerous misinformation liable to cause real world physical > injuries, because they implicitly normalise the idea of misusing the loop > as a wrist strap, which a current or future cane user would therefore be > more likely to do, thus leading to physical injury to that person ? up to > and including death. > > > ## Specific critique of implementations, including non hazardous > inaccuracies > > * Apple > > > > Dangerous: none. > > Inaccurate: lower fingers not wrapped around the grip; grip pinched > between thumb and index finger. > > Rare: hand holding the loop. > > > * Facebook > > > > > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white; loop with thickness of a > hiking pole strap. > > Rare: cane is extremely short, though this is proportionate to comic style. > > > * Google > > > > > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white. > > Rare: cane is short. > > > * Microsoft > > > > > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white; cane held like a walking > stick; cane coming out the pinky end; cane held at the top of the handle; > cane held without a thumb; cane at different angle than forearm. > > Rare: cane is short. > > > * Samsung > > [image: image.png] > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white; loop with thickness of a > hiking pole strap. > > Rare: none. > > > > * Twitter > > > > > > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white; cane handle with a flange > like a hiking pole; hand resting over the top like a hiking pole; cane at > different angle than forearm. > > Rare: cane is short. > > > > * WhatsApp > > > > > > Dangerous: use of loop as a wrist strap. > > Inaccurate: cane body in grey rather than white; cane held reversed, with > palm facing away from the user's body; cane at different angle than forearm. > > Rare: none. > > > > ## Further examples in solo white cane emoji > > All of the above issues are likewise reflected in the implementations of > emoji for a white cane alone, see https://emojis.wiki/white-cane/ > > For instance, Facebook's implementation > [image: image.png] > > incorrectly depicts a hiking stick style wide wrist strap, depicted in an > open manner suggesting it should be used as a wrist strap. > > Google's implementation > [image: image.png] > incorrectly depicts a wrist strap that pierces the cane handle for a load > bearing design, like on a hiking stick. The bungee loop of a cane comes out > the tip of the handle, since it is a structural element of the hook tip or > collapsible cane assembly itself (the cane is hollow and the bungee cord > runs its entire length), not an added component meant to be load bearing > like on a hiking stick. > > Twitter's implementation > [image: image.png] > again shows a flange, such as on a hiking stick, which does not exist on > canes; and shows the loop in an outstretched position suggesting that a > hand is meant to go through it, rather than it being left alone when in use. > > > > > # Requested changes > > ## Immediate changes > > Because the current implementations pose a risk of causing actual physical > harm, I request the following changes be made as soon as possible. > > 1. Unicode: Change the implementation definition for all variants of > > A. the person with white cane emoji: > > The loop MUST NOT be around the user's wrist. > > The loop MAY, at implementer's discretion, > a. hang downwards, > b. be held against the handle by the caning hand palm, > c. be tied along the cane handle, or > d. be omitted entirely. > > B. the white cane emoji: > > The loop, if depicted, MUST NOT be suggestive of a wrist strap in width or > positioning. > > > 2. All implementers: Please change all cane use emoji accordingly, without > waiting for a Unicode change. > > I suggest just removing the loop entirely. > > > ## Normative change and extension for cane colour semantics > > 3. Unicode: Change the implementation definition, and add combining forms, > for accuracy and to represent semantically different canes: > > A. Normative cane grip > > When depicted in use (i.e. in extended grip), the cane SHOULD be held: > a. in golf grip, palm facing body > b. with the caning hand palm on the outside edge of the handle > c. thumb curling around over the top > d. other fingers curling around under the bottom > e. with cane extending out the thumb side of the hand. > > B. Cane colour coding > > The cane SHOULD be either: > a. entirely white, or white with the bottom section red, at implementer's > discretion (default) > c. white with two bottom sections red, separated by a white section (if > combined ZWJ with U+1F9CF ? DEAF PERSON) > d. entirely a vibrant colour (if combined ZWJ with a colour) > > with "white" being as close to vibrant white as feasible given artistic > style (e.g. presence of drawn outlines, 'reflective' patches, etc) and the > need to be distinguishable on a white background. > > All implementers: Please change depictions accordingly. > > > ## Structural change > > In light of this having gotten implemented in a way that indicates Unicode > and implementers clearly have no experience actually using a cane, and were > oblivious to the inaccuracy and possible harm of these depictions ? and it > wasn't caught before now ? I also request a structural change. > > > 4. For all current and future emoji involving disabled people or their > equipment, specifically consult the largest umbrella group run by such > people, and their major national or higher level member organisations, to > get their feedback on the exact details of both the abstract proposal and > its implementations. > > In the case of blind people, that umbrella group is the World Blind Union > (WBU). I have therefore CCed the WBU President. > > I have also CCed the two largest US blind organisations, American Council > of the Blind (ACB) and National Federation of the Blind (NFB). I am a > member of both. > > > Thank you in advance for your time and consideration. > > Sincerely, > Sai > President, Fiat Fiendum, Inc., a 501(c)(3) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717666957078.png Type: image/png Size: 9595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667014466.jpg Type: image/jpeg Size: 8376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667131475.png Type: image/png Size: 10973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667208523.png Type: image/png Size: 4930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667376174.png Type: image/png Size: 5982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1717667446450.jpg Type: image/jpeg Size: 9809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 4397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 8842 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 6912 bytes Desc: not available URL: From doug at ewellic.org Fri Jun 7 00:07:22 2024 From: doug at ewellic.org (Doug Ewell) Date: Fri, 7 Jun 2024 05:07:22 +0000 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: Sai wrote: > Dear Unicode Consortium and implementers, > > [...] > > In nearly all implementations listed at > https://emojis.wiki/person-with-white-cane/ , these are depicted with > the person having their hand through the cane's bungee loop as if it > were a wrist strap. > > This is both wrong and, as an implicit norm/suggestion, it is > dangerous misinformation that may cause real world fatalities to cane > users. The Unicode Consortium provides reference glyphs, but they are not normative; they do not dictate to font vendors exactly how a character must be rendered. This is particularly true for emoji which are implemented as ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. As such, Sai?s message is only a call for implementers to change the glyphs in their fonts. The Unicode Consortium has no action item here, urgent or otherwise, because their only reference glyph is of the cane by itself, which (according to Sai) is not incorrect with a strap. It is unfortunate if we have gotten to the point where the cartoon representation of a human figure in some vendor?s emoji font can be viewed as a safety hazard in and of itself. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From sai at fiatfiendum.org Sat Jun 8 04:37:55 2024 From: sai at fiatfiendum.org (Sai) Date: Sat, 8 Jun 2024 10:37:55 +0100 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: > The Unicode Consortium provides reference glyphs, but they are not normative; they do not dictate to font vendors exactly how a character must be rendered. This is particularly true for emoji which are implemented as ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. While this may be technically correct in a legalistic or documentation sense, it is not really accurate to say there's no normative content. An implementer is not going to depict WHITE CANE + ZWJ + PERSON as someone riding the cane like a witch broom. Nor, most likely, to depict them even just standing with cane in vertical rest position. There is inherent normative value in the reference glyphs. Otherwise you wouldn't have one. That's kinda the point of a "reference" item ? that it depicts a standard, normal version of the thing, which can be elaborated on with intentional artistic (etc) variation. And this ZWJ sequence is in the official table I cited. > As such, Sai?s message is only a call for implementers to change the glyphs in their fonts. The Unicode Consortium has no action item here, urgent or otherwise, because their only reference glyph I pointed to the reference ZWJ glyphs. Also, given this response, I will add another structural request: 5. Unicode: Where the name alone is insufficient for implementers to make an accurate implementation, provide specifications of code points and sequences. In particular, do so here. > the cane by itself, which is not incorrect with a strap. You did not understand my post. It IS incorrect to depict a cane as having a strap. No blind cane has a walking stick type strap; this is simply not a thing. (There are support canes which get white taping because intersectional disabilities, like mine, but those are semantically not the same object.) This is a misinterpretation by implementers, and it seems by you also. A cane has a structural loop of bungee cord that runs from the tip (which typically has a hook for this, a stem smaller than the cane's inner diameter which goes inside the cane section, and a larger body which stays outside), all the way through the cane, out a hole in the centre of the handle section, where it is knotted off at the correct tension and given an additional knotted loop to contain the bundle for a collapsed sectional cane. The bungee loop is not a strap. In particular it is not a wrist strap. It is never wide like a wrist strap, only round cord. It never pierces the handle like a hiking pole, only comes out the tip (if present at all). Depiction of it as a strap is factually wrong. It is semantic error, confusion for a walking stick, which is likewise the reason for essentially all of the specific inaccuracies I pointed out. > (according to Sai) You don't need to take my word for it. If you tried even a minimum amount you would verify everything I said. Rather than being snide and dismissive, you could spend one minute on Google, or ambutech.com, to verify what I said as to the physical design. It's not hard to find close up photos. You could spend sightly more time to look at O&M materials, or talking to literally any well trained blind person (or poorly trained one who's used it long enough to have learned the hard way), to verify what I said about the use. Here's a canonical reference for you https://nfb.org/sites/nfb.org/files/images/nfb/publications/books/cfcane/cane04.htm >> Many canes have a loop of chain or string through the handle which is for the purpose of hanging up the cane when it is not in use. Do not put your hand through the loop when you are walking. If something should happen to pull the cane out of your hand, it is better to drop the cane than to be pulled down with it. > It is unfortunate if we have gotten to the point where the cartoon representation of a human figure in some vendor?s emoji font can be viewed as a safety hazard in and of itself. It is unfortunate that we have stayed at the point where people are utterly oblivious and dismissive of genuine harms caused to disabled people, both in development without us to begin with, and when pointed out explicitly. If you disagree with me that it's a safety hazard to use a cane in this way, do so directly. Find something that considers the question and says it's a good idea, or even neutral, for a blind person to put their hand through a cane's bungee loop. If you disagree with me that such depictions of dangerous use are likely to cause real world dangerous use, say why depicting people doing so by default would not give the impression that that's correct usage and thereby cause people to do it. Otherwise, this is just ignorant snark. ??? is a depiction of genuinely dangerous real world usage of a critical tool. It's not ? which is obviously cartoon depiction of something that doesn't happen. And it's not ? either; it's not a question of what messages people communicate. ??? depicts a chemist? wearing safety glasses and a lab coat when handling chemicals, as they should. People seeing it will, therefore, be implicitly nudged to consider that as normative behaviour, and by having that as a norm, they will be more likely to wear safety glasses and lab coats when doing chemistry. ? depicts a construction worker? wearing a hard hat and high-viz vest. ??? is like depicting a chemist just casually pouring a vial of gaseous chemicals with no safety precautions, mad hatter style? as the default standard way of depicting a chemist. Ditto for construction. Etc. This is depicting, as plainly normative rather than as Tom & Jerry style obvious comedy, actually dangerous usage of a real life thing (cane use) based on real life misconceptions held by people who are not adequately trained against it. I've personally trained actual blind people newly using a cane who did this exact thing because they had the same misconception. I know others who have been physically injured because they did this. It being in the standard depiction will cause others to have the same idea. I was not exaggerating when I said that this can cause actual real world physical injury. Sincerely, Sai President, Fiat Fiendum, Inc., a 501(c)(3) Sent from my mobile phone; please excuse the concision, typos, and autocorrect errors. On Fri, 7 Jun 2024, 06:07 Doug Ewell, wrote: > Sai wrote: > > > Dear Unicode Consortium and implementers, > > > > [...] > > > > In nearly all implementations listed at > > https://emojis.wiki/person-with-white-cane/ , these are depicted with > > the person having their hand through the cane's bungee loop as if it > > were a wrist strap. > > > > This is both wrong and, as an implicit norm/suggestion, it is > > dangerous misinformation that may cause real world fatalities to cane > > users. > > The Unicode Consortium provides reference glyphs, but they are not > normative; they do not dictate to font vendors exactly how a character must > be rendered. This is particularly true for emoji which are implemented as > ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. > > As such, Sai?s message is only a call for implementers to change the > glyphs in their fonts. The Unicode Consortium has no action item here, > urgent or otherwise, because their only reference glyph is of the cane by > itself, which (according to Sai) is not incorrect with a strap. > > It is unfortunate if we have gotten to the point where the cartoon > representation of a human figure in some vendor?s emoji font can be viewed > as a safety hazard in and of itself. > > -- > Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irgendeinbenutzername at gmail.com Sat Jun 8 06:02:47 2024 From: irgendeinbenutzername at gmail.com (Charlotte Eiffel Lilith Buff) Date: Sat, 8 Jun 2024 13:02:47 +0200 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: Taking one step back, please note that you have submitted your request to the Unicode mailing list, which is just a place for random people to discuss miscellaneous Unicode topics. Nothing that happens here is going to affect the development or implementation of the Unicode Standard. Am Sa., 8. Juni 2024 um 11:41 Uhr schrieb Sai via Unicode < unicode at corp.unicode.org>: > > The Unicode Consortium provides reference glyphs, but they are not > normative; they do not dictate to font vendors exactly how a character must > be rendered. This is particularly true for emoji which are implemented as > ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. > > While this may be technically correct in a legalistic or documentation > sense, it is not really accurate to say there's no normative content. > > An implementer is not going to depict WHITE CANE + ZWJ + PERSON as someone > riding the cane like a witch broom. Nor, most likely, to depict them even > just standing with cane in vertical rest position. > > There is inherent normative value in the reference glyphs. Otherwise you > wouldn't have one. That's kinda the point of a "reference" item ? that it > depicts a standard, normal version of the thing, which can be elaborated on > with intentional artistic (etc) variation. > > And this ZWJ sequence is in the official table I cited. > > > As such, Sai?s message is only a call for implementers to change the > glyphs in their fonts. The Unicode Consortium has no action item here, > urgent or otherwise, because their only reference glyph > > I pointed to the reference ZWJ glyphs. > > Also, given this response, I will add another structural request: > > 5. Unicode: Where the name alone is insufficient for implementers to make > an accurate implementation, provide specifications of code points and > sequences. > > In particular, do so here. > > > > the cane by itself, which is not incorrect with a strap. > > You did not understand my post. > > It IS incorrect to depict a cane as having a strap. No blind cane has a > walking stick type strap; this is simply not a thing. (There are support > canes which get white taping because intersectional disabilities, like > mine, but those are semantically not the same object.) > > This is a misinterpretation by implementers, and it seems by you also. A > cane has a structural loop of bungee cord that runs from the tip (which > typically has a hook for this, a stem smaller than the cane's inner > diameter which goes inside the cane section, and a larger body which stays > outside), all the way through the cane, out a hole in the centre of the > handle section, where it is knotted off at the correct tension and given an > additional knotted loop to contain the bundle for a collapsed sectional > cane. > > The bungee loop is not a strap. In particular it is not a wrist strap. It > is never wide like a wrist strap, only round cord. It never pierces the > handle like a hiking pole, only comes out the tip (if present at all). > Depiction of it as a strap is factually wrong. It is semantic error, > confusion for a walking stick, which is likewise the reason for essentially > all of the specific inaccuracies I pointed out. > > > (according to Sai) > > You don't need to take my word for it. If you tried even a minimum amount > you would verify everything I said. > > Rather than being snide and dismissive, you could spend one minute on > Google, or ambutech.com, to verify what I said as to the physical design. > It's not hard to find close up photos. > > You could spend sightly more time to look at O&M materials, or talking to > literally any well trained blind person (or poorly trained one who's used > it long enough to have learned the hard way), to verify what I said about > the use. > > Here's a canonical reference for you > https://nfb.org/sites/nfb.org/files/images/nfb/publications/books/cfcane/cane04.htm > > >> Many canes have a loop of chain or string through the handle which is > for the purpose of hanging up the cane when it is not in use. Do not put > your hand through the loop when you are walking. If something should happen > to pull the cane out of your hand, it is better to drop the cane than to be > pulled down with it. > > > > It is unfortunate if we have gotten to the point where the cartoon > representation of a human figure in some vendor?s emoji font can be viewed > as a safety hazard in and of itself. > > It is unfortunate that we have stayed at the point where people are > utterly oblivious and dismissive of genuine harms caused to disabled > people, both in development without us to begin with, and when pointed out > explicitly. > > If you disagree with me that it's a safety hazard to use a cane in this > way, do so directly. Find something that considers the question and says > it's a good idea, or even neutral, for a blind person to put their hand > through a cane's bungee loop. > > If you disagree with me that such depictions of dangerous use are likely > to cause real world dangerous use, say why depicting people doing so by > default would not give the impression that that's correct usage and thereby > cause people to do it. > > Otherwise, this is just ignorant snark. > > ??? is a depiction of genuinely dangerous real world usage of a critical > tool. It's not ? which is obviously cartoon depiction of something that > doesn't happen. And it's not ? either; it's not a question of what > messages people communicate. > > ??? depicts a chemist? wearing safety glasses and a lab coat when > handling chemicals, as they should. People seeing it will, therefore, be > implicitly nudged to consider that as normative behaviour, and by having > that as a norm, they will be more likely to wear safety glasses and lab > coats when doing chemistry. > > ? depicts a construction worker? wearing a hard hat and high-viz vest. > > ??? is like depicting a chemist just casually pouring a vial of gaseous > chemicals with no safety precautions, mad hatter style? as the default > standard way of depicting a chemist. Ditto for construction. Etc. > > This is depicting, as plainly normative rather than as Tom & Jerry style > obvious comedy, actually dangerous usage of a real life thing (cane use) > based on real life misconceptions held by people who are not adequately > trained against it. I've personally trained actual blind people newly using > a cane who did this exact thing because they had the same misconception. I > know others who have been physically injured because they did this. It > being in the standard depiction will cause others to have the same idea. I > was not exaggerating when I said that this can cause actual real world > physical injury. > > Sincerely, > Sai > President, Fiat Fiendum, Inc., a 501(c)(3) > > Sent from my mobile phone; please excuse the concision, typos, and > autocorrect errors. > > On Fri, 7 Jun 2024, 06:07 Doug Ewell, wrote: > >> Sai wrote: >> >> > Dear Unicode Consortium and implementers, >> > >> > [...] >> > >> > In nearly all implementations listed at >> > https://emojis.wiki/person-with-white-cane/ , these are depicted with >> > the person having their hand through the cane's bungee loop as if it >> > were a wrist strap. >> > >> > This is both wrong and, as an implicit norm/suggestion, it is >> > dangerous misinformation that may cause real world fatalities to cane >> > users. >> >> The Unicode Consortium provides reference glyphs, but they are not >> normative; they do not dictate to font vendors exactly how a character must >> be rendered. This is particularly true for emoji which are implemented as >> ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. >> >> As such, Sai?s message is only a call for implementers to change the >> glyphs in their fonts. The Unicode Consortium has no action item here, >> urgent or otherwise, because their only reference glyph is of the cane by >> itself, which (according to Sai) is not incorrect with a strap. >> >> It is unfortunate if we have gotten to the point where the cartoon >> representation of a human figure in some vendor?s emoji font can be viewed >> as a safety hazard in and of itself. >> >> -- >> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sai at fiatfiendum.org Sat Jun 8 09:24:50 2024 From: sai at fiatfiendum.org (Sai) Date: Sat, 8 Jun 2024 15:24:50 +0100 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: Where should it be better posted, that non fee paying members have access to? Sincerely, Sai President, Fiat Fiendum, Inc., a 501(c)(3) Sent from my mobile phone; please excuse the concision, typos, and autocorrect errors. On Sat, 8 Jun 2024, 12:02 Charlotte Eiffel Lilith Buff, < irgendeinbenutzername at gmail.com> wrote: > Taking one step back, please note that you have submitted your request to > the Unicode mailing list, which is just a place for random people to > discuss miscellaneous Unicode topics. Nothing that happens here is going to > affect the development or implementation of the Unicode Standard. > > Am Sa., 8. Juni 2024 um 11:41 Uhr schrieb Sai via Unicode < > unicode at corp.unicode.org>: > >> > The Unicode Consortium provides reference glyphs, but they are not >> normative; they do not dictate to font vendors exactly how a character must >> be rendered. This is particularly true for emoji which are implemented as >> ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. >> >> While this may be technically correct in a legalistic or documentation >> sense, it is not really accurate to say there's no normative content. >> >> An implementer is not going to depict WHITE CANE + ZWJ + PERSON as >> someone riding the cane like a witch broom. Nor, most likely, to depict >> them even just standing with cane in vertical rest position. >> >> There is inherent normative value in the reference glyphs. Otherwise you >> wouldn't have one. That's kinda the point of a "reference" item ? that it >> depicts a standard, normal version of the thing, which can be elaborated on >> with intentional artistic (etc) variation. >> >> And this ZWJ sequence is in the official table I cited. >> >> > As such, Sai?s message is only a call for implementers to change the >> glyphs in their fonts. The Unicode Consortium has no action item here, >> urgent or otherwise, because their only reference glyph >> >> I pointed to the reference ZWJ glyphs. >> >> Also, given this response, I will add another structural request: >> >> 5. Unicode: Where the name alone is insufficient for implementers to make >> an accurate implementation, provide specifications of code points and >> sequences. >> >> In particular, do so here. >> >> >> > the cane by itself, which is not incorrect with a strap. >> >> You did not understand my post. >> >> It IS incorrect to depict a cane as having a strap. No blind cane has a >> walking stick type strap; this is simply not a thing. (There are support >> canes which get white taping because intersectional disabilities, like >> mine, but those are semantically not the same object.) >> >> This is a misinterpretation by implementers, and it seems by you also. A >> cane has a structural loop of bungee cord that runs from the tip (which >> typically has a hook for this, a stem smaller than the cane's inner >> diameter which goes inside the cane section, and a larger body which stays >> outside), all the way through the cane, out a hole in the centre of the >> handle section, where it is knotted off at the correct tension and given an >> additional knotted loop to contain the bundle for a collapsed sectional >> cane. >> >> The bungee loop is not a strap. In particular it is not a wrist strap. It >> is never wide like a wrist strap, only round cord. It never pierces the >> handle like a hiking pole, only comes out the tip (if present at all). >> Depiction of it as a strap is factually wrong. It is semantic error, >> confusion for a walking stick, which is likewise the reason for essentially >> all of the specific inaccuracies I pointed out. >> >> > (according to Sai) >> >> You don't need to take my word for it. If you tried even a minimum amount >> you would verify everything I said. >> >> Rather than being snide and dismissive, you could spend one minute on >> Google, or ambutech.com, to verify what I said as to the physical >> design. It's not hard to find close up photos. >> >> You could spend sightly more time to look at O&M materials, or talking to >> literally any well trained blind person (or poorly trained one who's used >> it long enough to have learned the hard way), to verify what I said about >> the use. >> >> Here's a canonical reference for you >> https://nfb.org/sites/nfb.org/files/images/nfb/publications/books/cfcane/cane04.htm >> >> >> Many canes have a loop of chain or string through the handle which is >> for the purpose of hanging up the cane when it is not in use. Do not put >> your hand through the loop when you are walking. If something should happen >> to pull the cane out of your hand, it is better to drop the cane than to be >> pulled down with it. >> >> >> > It is unfortunate if we have gotten to the point where the cartoon >> representation of a human figure in some vendor?s emoji font can be viewed >> as a safety hazard in and of itself. >> >> It is unfortunate that we have stayed at the point where people are >> utterly oblivious and dismissive of genuine harms caused to disabled >> people, both in development without us to begin with, and when pointed out >> explicitly. >> >> If you disagree with me that it's a safety hazard to use a cane in this >> way, do so directly. Find something that considers the question and says >> it's a good idea, or even neutral, for a blind person to put their hand >> through a cane's bungee loop. >> >> If you disagree with me that such depictions of dangerous use are likely >> to cause real world dangerous use, say why depicting people doing so by >> default would not give the impression that that's correct usage and thereby >> cause people to do it. >> >> Otherwise, this is just ignorant snark. >> >> ??? is a depiction of genuinely dangerous real world usage of a >> critical tool. It's not ? which is obviously cartoon depiction of >> something that doesn't happen. And it's not ? either; it's not a question >> of what messages people communicate. >> >> ??? depicts a chemist? wearing safety glasses and a lab coat when >> handling chemicals, as they should. People seeing it will, therefore, be >> implicitly nudged to consider that as normative behaviour, and by having >> that as a norm, they will be more likely to wear safety glasses and lab >> coats when doing chemistry. >> >> ? depicts a construction worker? wearing a hard hat and high-viz vest. >> >> ??? is like depicting a chemist just casually pouring a vial of gaseous >> chemicals with no safety precautions, mad hatter style? as the default >> standard way of depicting a chemist. Ditto for construction. Etc. >> >> This is depicting, as plainly normative rather than as Tom & Jerry style >> obvious comedy, actually dangerous usage of a real life thing (cane use) >> based on real life misconceptions held by people who are not adequately >> trained against it. I've personally trained actual blind people newly using >> a cane who did this exact thing because they had the same misconception. I >> know others who have been physically injured because they did this. It >> being in the standard depiction will cause others to have the same idea. I >> was not exaggerating when I said that this can cause actual real world >> physical injury. >> >> Sincerely, >> Sai >> President, Fiat Fiendum, Inc., a 501(c)(3) >> >> Sent from my mobile phone; please excuse the concision, typos, and >> autocorrect errors. >> >> On Fri, 7 Jun 2024, 06:07 Doug Ewell, wrote: >> >>> Sai wrote: >>> >>> > Dear Unicode Consortium and implementers, >>> > >>> > [...] >>> > >>> > In nearly all implementations listed at >>> > https://emojis.wiki/person-with-white-cane/ , these are depicted with >>> > the person having their hand through the cane's bungee loop as if it >>> > were a wrist strap. >>> > >>> > This is both wrong and, as an implicit norm/suggestion, it is >>> > dangerous misinformation that may cause real world fatalities to cane >>> > users. >>> >>> The Unicode Consortium provides reference glyphs, but they are not >>> normative; they do not dictate to font vendors exactly how a character must >>> be rendered. This is particularly true for emoji which are implemented as >>> ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. >>> >>> As such, Sai?s message is only a call for implementers to change the >>> glyphs in their fonts. The Unicode Consortium has no action item here, >>> urgent or otherwise, because their only reference glyph is of the cane by >>> itself, which (according to Sai) is not incorrect with a strap. >>> >>> It is unfortunate if we have gotten to the point where the cartoon >>> representation of a human figure in some vendor?s emoji font can be viewed >>> as a safety hazard in and of itself. >>> >>> -- >>> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at akphs.com Sat Jun 8 09:25:14 2024 From: lists at akphs.com (Phil Smith III) Date: Sat, 8 Jun 2024 10:25:14 -0400 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: <00ee01dab9af$aebfc630$0c3f5290$@akphs.com> Charlotte Eiffel Lilith Buff wrote, in part: >you have submitted your request to the Unicode mailing list, which is >just a place for random people to discuss miscellaneous Unicode >topics. Nothing that happens here is going to affect the development >or implementation of the Unicode Standard. Then can someone suggest a better forum for Sai to make his point? While it seems relatively unlikely that anyone will be harmed by using a cane incorrectly because they saw it in an emoji, there is value in getting it right, as his examples demonstrate. Is there a First Nations emoji that looks like the old Washington Redskins mascot? Is there a Black emoji with a bone in its lip? Would those be ok? I have no dog in this specific fight, but it feels like people are saying ?Oh, this is just PC nitpicking?, and that?s oversimplifying it. This stuff is permanent(ish). Remember the fiasco with the Japanese combining characters, which nobody uses. Like that, this seems to suggest a lack of care/research by the Consortium into real-world usage. And isn?t real-world usage the fundamental goal of Unicode? ...phsiii -------------- next part -------------- An HTML attachment was scrubbed... URL: From sosipiuk at gmail.com Sat Jun 8 12:48:51 2024 From: sosipiuk at gmail.com (=?UTF-8?Q?S=C5=82awomir_Osipiuk?=) Date: Sat, 08 Jun 2024 17:48:51 +0000 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: <00ee01dab9af$aebfc630$0c3f5290$@akphs.com> References: <00ee01dab9af$aebfc630$0c3f5290$@akphs.com> Message-ID: <1717868538858.724396133.1908683728@gmail.com> On Saturday, 08 June 2024, 10:25:14 (-04:00), Phil Smith III via Unicode wrote: Then can someone suggest a better forum for Sai to make his point? It seems what's needed is a "Proposal to update the representative glyph" to be submitted to the UTC. I've seen such proposals for regular characters, but not for an emoji. If someone is aware of one that Sai can use as a guide, and likewise, if anyone knows where exactly such a proposal should be filed, please let the group know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irgendeinbenutzername at gmail.com Sat Jun 8 15:06:52 2024 From: irgendeinbenutzername at gmail.com (Charlotte Eiffel Lilith Buff) Date: Sat, 8 Jun 2024 22:06:52 +0200 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: Information on how to contact the Unicode Consortium is available at https://corp.unicode.org/reporting/ That being said, I think you are wasting your time taking this up with Unicode. There is nothing actionable for the UTC in your request. Unicode provides no specific guidance on emoji glyphs; the website just documents existing glyphs from various vendors. Even for emoji that are singular characters and therefore have representative glyphs in the code charts, said representative glyphs are completely meaningless. Vendors never pay attention to these charts and frequently contradict the intended meaning of new emoji. Historically, the Unicode Standard is far more likely to adapt itself to common vendor practices than the other way around when it comes to emoji. Am Sa., 8. Juni 2024 um 16:25 Uhr schrieb Sai : > Where should it be better posted, that non fee paying members have access > to? > > Sincerely, > Sai > President, Fiat Fiendum, Inc., a 501(c)(3) > > Sent from my mobile phone; please excuse the concision, typos, and > autocorrect errors. > > On Sat, 8 Jun 2024, 12:02 Charlotte Eiffel Lilith Buff, < > irgendeinbenutzername at gmail.com> wrote: > >> Taking one step back, please note that you have submitted your request to >> the Unicode mailing list, which is just a place for random people to >> discuss miscellaneous Unicode topics. Nothing that happens here is going to >> affect the development or implementation of the Unicode Standard. >> >> Am Sa., 8. Juni 2024 um 11:41 Uhr schrieb Sai via Unicode < >> unicode at corp.unicode.org>: >> >>> > The Unicode Consortium provides reference glyphs, but they are not >>> normative; they do not dictate to font vendors exactly how a character must >>> be rendered. This is particularly true for emoji which are implemented as >>> ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. >>> >>> While this may be technically correct in a legalistic or documentation >>> sense, it is not really accurate to say there's no normative content. >>> >>> An implementer is not going to depict WHITE CANE + ZWJ + PERSON as >>> someone riding the cane like a witch broom. Nor, most likely, to depict >>> them even just standing with cane in vertical rest position. >>> >>> There is inherent normative value in the reference glyphs. Otherwise you >>> wouldn't have one. That's kinda the point of a "reference" item ? that it >>> depicts a standard, normal version of the thing, which can be elaborated on >>> with intentional artistic (etc) variation. >>> >>> And this ZWJ sequence is in the official table I cited. >>> >>> > As such, Sai?s message is only a call for implementers to change the >>> glyphs in their fonts. The Unicode Consortium has no action item here, >>> urgent or otherwise, because their only reference glyph >>> >>> I pointed to the reference ZWJ glyphs. >>> >>> Also, given this response, I will add another structural request: >>> >>> 5. Unicode: Where the name alone is insufficient for implementers to >>> make an accurate implementation, provide specifications of code points and >>> sequences. >>> >>> In particular, do so here. >>> >>> >>> > the cane by itself, which is not incorrect with a strap. >>> >>> You did not understand my post. >>> >>> It IS incorrect to depict a cane as having a strap. No blind cane has a >>> walking stick type strap; this is simply not a thing. (There are support >>> canes which get white taping because intersectional disabilities, like >>> mine, but those are semantically not the same object.) >>> >>> This is a misinterpretation by implementers, and it seems by you also. A >>> cane has a structural loop of bungee cord that runs from the tip (which >>> typically has a hook for this, a stem smaller than the cane's inner >>> diameter which goes inside the cane section, and a larger body which stays >>> outside), all the way through the cane, out a hole in the centre of the >>> handle section, where it is knotted off at the correct tension and given an >>> additional knotted loop to contain the bundle for a collapsed sectional >>> cane. >>> >>> The bungee loop is not a strap. In particular it is not a wrist strap. >>> It is never wide like a wrist strap, only round cord. It never pierces the >>> handle like a hiking pole, only comes out the tip (if present at all). >>> Depiction of it as a strap is factually wrong. It is semantic error, >>> confusion for a walking stick, which is likewise the reason for essentially >>> all of the specific inaccuracies I pointed out. >>> >>> > (according to Sai) >>> >>> You don't need to take my word for it. If you tried even a minimum >>> amount you would verify everything I said. >>> >>> Rather than being snide and dismissive, you could spend one minute on >>> Google, or ambutech.com, to verify what I said as to the physical >>> design. It's not hard to find close up photos. >>> >>> You could spend sightly more time to look at O&M materials, or talking >>> to literally any well trained blind person (or poorly trained one who's >>> used it long enough to have learned the hard way), to verify what I said >>> about the use. >>> >>> Here's a canonical reference for you >>> https://nfb.org/sites/nfb.org/files/images/nfb/publications/books/cfcane/cane04.htm >>> >>> >> Many canes have a loop of chain or string through the handle which is >>> for the purpose of hanging up the cane when it is not in use. Do not put >>> your hand through the loop when you are walking. If something should happen >>> to pull the cane out of your hand, it is better to drop the cane than to be >>> pulled down with it. >>> >>> >>> > It is unfortunate if we have gotten to the point where the cartoon >>> representation of a human figure in some vendor?s emoji font can be viewed >>> as a safety hazard in and of itself. >>> >>> It is unfortunate that we have stayed at the point where people are >>> utterly oblivious and dismissive of genuine harms caused to disabled >>> people, both in development without us to begin with, and when pointed out >>> explicitly. >>> >>> If you disagree with me that it's a safety hazard to use a cane in this >>> way, do so directly. Find something that considers the question and says >>> it's a good idea, or even neutral, for a blind person to put their hand >>> through a cane's bungee loop. >>> >>> If you disagree with me that such depictions of dangerous use are likely >>> to cause real world dangerous use, say why depicting people doing so by >>> default would not give the impression that that's correct usage and thereby >>> cause people to do it. >>> >>> Otherwise, this is just ignorant snark. >>> >>> ??? is a depiction of genuinely dangerous real world usage of a >>> critical tool. It's not ? which is obviously cartoon depiction of >>> something that doesn't happen. And it's not ? either; it's not a question >>> of what messages people communicate. >>> >>> ??? depicts a chemist? wearing safety glasses and a lab coat when >>> handling chemicals, as they should. People seeing it will, therefore, be >>> implicitly nudged to consider that as normative behaviour, and by having >>> that as a norm, they will be more likely to wear safety glasses and lab >>> coats when doing chemistry. >>> >>> ? depicts a construction worker? wearing a hard hat and high-viz vest. >>> >>> ??? is like depicting a chemist just casually pouring a vial of >>> gaseous chemicals with no safety precautions, mad hatter style? as the >>> default standard way of depicting a chemist. Ditto for construction. Etc. >>> >>> This is depicting, as plainly normative rather than as Tom & Jerry style >>> obvious comedy, actually dangerous usage of a real life thing (cane use) >>> based on real life misconceptions held by people who are not adequately >>> trained against it. I've personally trained actual blind people newly using >>> a cane who did this exact thing because they had the same misconception. I >>> know others who have been physically injured because they did this. It >>> being in the standard depiction will cause others to have the same idea. I >>> was not exaggerating when I said that this can cause actual real world >>> physical injury. >>> >>> Sincerely, >>> Sai >>> President, Fiat Fiendum, Inc., a 501(c)(3) >>> >>> Sent from my mobile phone; please excuse the concision, typos, and >>> autocorrect errors. >>> >>> On Fri, 7 Jun 2024, 06:07 Doug Ewell, wrote: >>> >>>> Sai wrote: >>>> >>>> > Dear Unicode Consortium and implementers, >>>> > >>>> > [...] >>>> > >>>> > In nearly all implementations listed at >>>> > https://emojis.wiki/person-with-white-cane/ , these are depicted with >>>> > the person having their hand through the cane's bungee loop as if it >>>> > were a wrist strap. >>>> > >>>> > This is both wrong and, as an implicit norm/suggestion, it is >>>> > dangerous misinformation that may cause real world fatalities to cane >>>> > users. >>>> >>>> The Unicode Consortium provides reference glyphs, but they are not >>>> normative; they do not dictate to font vendors exactly how a character must >>>> be rendered. This is particularly true for emoji which are implemented as >>>> ZWJ sequences, such as the PERSON WITH CANE emoji under discussion here. >>>> >>>> As such, Sai?s message is only a call for implementers to change the >>>> glyphs in their fonts. The Unicode Consortium has no action item here, >>>> urgent or otherwise, because their only reference glyph is of the cane by >>>> itself, which (according to Sai) is not incorrect with a strap. >>>> >>>> It is unfortunate if we have gotten to the point where the cartoon >>>> representation of a human figure in some vendor?s emoji font can be viewed >>>> as a safety hazard in and of itself. >>>> >>>> -- >>>> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at ewellic.org Sat Jun 8 15:20:16 2024 From: doug at ewellic.org (Doug Ewell) Date: Sat, 8 Jun 2024 20:20:16 +0000 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: I would like to apologize, sincerely, for what was perceived as a snide or dismissive tone in my earlier message. Any sarcasm or snarkiness that may have been intended was not directed at Sai, nor at any user of a blind cane. I would also like to walk back any implication that it was inappropriate for Sai to post this message to the Unicode list. It is an effective way to reach the people who are actually in a position to make the requested changes. Certainly sending an email to ?Google? or ?Apple,? generically, would be unlikely to achieve the same effect. S?awomir is correct that an actual proposal form needs to be submitted in order to request formal action. However, raising awareness of the issue on this list is not an inappropriate first step, as long as there is no expectation it will directly result in action. It does have to be noted that no ?immediate? action can be expected of either Unicode (to the extent they have any action items, which I still question) or any vendor or font designer. That is simply not the timetable on which standards development organizations and font designers operate. They will triage the reported issue and determine its urgency and priority on their own terms. And even if new fonts were rolled out today, the new images would not immediately replace the old ones. End users of both computers and phones are notoriously slow in performing updates, and often turn off automatic updating services or delay the process as long as possible. So, things will happen when they happen. Regarding reference glyphs, there is no bright line that fits all scenarios for when a reference glyph, or any vendor?s implementation, deviates far enough from its original intent that it can be considered incorrect. At least with normal (non-emoji) characters, there is a concept of the character?s identity. To cite Rebecca?s point, obviously a glyph for U+0041 that is shaped like LATIN CAPITAL LETTER B is over the line; but at the same time, no glyph for U+0041 is required to have serifs or to have the left leg of the A narrower than the right leg, as the reference glyph shows. Likewise, a blind person riding a cane like a witch?s broom would obviously ? *obviously* ? be over the line, but the depicted technique for holding it while walking was apparently lost on most reviewers back in 2018 when this character and its combining sequences were proposed. (Not everybody, though: see Karishma Shah?s public-review comment in https://www.unicode.org/L2/L2018/18138-access-fdbk.pdf , which appears not to have been heeded.) I never claimed that holding a cane with its bungee loop around one?s wrist was not a safety hazard. That is a misrepresentation. My comment was about reliance on vendors? emoji glyphs, especially at small size, to illustrate or teach correct behavior. And that raises one of the issues I have had with Unicode emoji for many years: as they have grown in scope over the years from generic, yellow Simpsons-like faces to try to cover all human scenarios (and more), users have come to expect them to have that characteristic, and have become frustrated or even angry when a scenario is not covered or depicted in a flawed way. Examples of this are legion. I don?t know that all people expect emoji glyphs to depict correct behavior, but it is certainly possible that some do. But I would imagine that blind people, and sighted people who work with them, would have better, more authoritative, more carefully designed guidelines for the proper use of equipment than emoji. I hope that vendors take this proposed change on board and make the glyphs in their emoji fonts more consistent with safe and correct behavior. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From ramm_backup2 at mail.ru Mon Jun 10 02:00:14 2024 From: ramm_backup2 at mail.ru (=?UTF-8?B?0K7RgNC40Lkg0JHRjdC60LDQvw==?=) Date: Mon, 10 Jun 2024 10:00:14 +0300 Subject: =?UTF-8?B?UXVlc3Rpb24gbWFyaw==?= Message-ID: <1718002814.340988646@f733.i.mail.ru> Hello! I've been wondering about the following question for a long time: how difficult and how feasible is it to add a question mark to the Unicode table that would be identical to the regular question mark but usable in Windows operating systems? Almost all characters prohibited in Windows OS have their equivalents in the Unicode table, allowing the use of characters like "/", "", ":", etc. However, there is no proper equivalent for the question mark. All the available options in the table are ugly, unattractive symbols that are inconvenient to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at akphs.com Mon Jun 10 11:05:03 2024 From: lists at akphs.com (Phil Smith III) Date: Mon, 10 Jun 2024 12:05:03 -0400 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: <033301dabb4f$f5149bf0$df3dd3d0$@akphs.com> How is a question mark ?prohibited? by Windows? <==There?s one now, in Windows! From: Unicode On Behalf Of ???? ????? via Unicode Sent: Monday, June 10, 2024 3:00 AM To: unicode at corp.unicode.org Subject: Question mark Hello! I've been wondering about the following question for a long time: how difficult and how feasible is it to add a question mark to the Unicode table that would be identical to the regular question mark but usable in Windows operating systems? Almost all characters prohibited in Windows OS have their equivalents in the Unicode table, allowing the use of characters like "/", "", ":", etc. However, there is no proper equivalent for the question mark. All the available options in the table are ugly, unattractive symbols that are inconvenient to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clarkcox3 at gmail.com Mon Jun 10 11:14:26 2024 From: clarkcox3 at gmail.com (Clark Cox) Date: Mon, 10 Jun 2024 12:14:26 -0400 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: What, exactly, do you mean by ?prohibited?? And how would this hypothetical character be any different from the existing question mark? Clark S. Cox III clarkcox3 at gmail.com On Mon, Jun 10, 2024 at 12:03 ???? ????? via Unicode < unicode at corp.unicode.org> wrote: > Hello! I've been wondering about the following question for a long time: > how difficult and how feasible is it to add a question mark to the Unicode > table that would be identical to the regular question mark but usable in > Windows operating systems? Almost all characters prohibited in Windows OS > have their equivalents in the Unicode table, allowing the use of characters > like "/", "", ":", etc. > > However, there is no proper equivalent for the question mark. All the > available options in the table are ugly, unattractive symbols that are > inconvenient to use. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.plantema at xs4all.nl Mon Jun 10 11:20:10 2024 From: alex.plantema at xs4all.nl (Alex Plantema) Date: Mon, 10 Jun 2024 18:20:10 +0200 Subject: Question mark In-Reply-To: <033301dabb4f$f5149bf0$df3dd3d0$@akphs.com> References: <1718002814.340988646@f733.i.mail.ru> <033301dabb4f$f5149bf0$df3dd3d0$@akphs.com> Message-ID: Op ma 10-06-2024 om 18:05 schreef Phil Smith III via Unicode: > > How is a question mark ?prohibited? by Windows? ?There?s one now, in Windows! > It isn't allowed in file names because it serves as a wildcard. The same for the asterisk. -- Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at akphs.com Mon Jun 10 11:23:54 2024 From: lists at akphs.com (Phil Smith III) Date: Mon, 10 Jun 2024 12:23:54 -0400 Subject: Question mark In-Reply-To: References: <1718002814.340988646@f733.i.mail.ru> <033301dabb4f$f5149bf0$df3dd3d0$@akphs.com> Message-ID: <035901dabb52$96d64c70$c482e550$@akphs.com> Ah. A key detail! I would not think that it would make sense to add this, as folks will be fatally confused by it. Same as putting slashes (back/forward) in filenames. Just Don?t Do It. Besides, any sane normalization would converge them anyway, right? And then people have a filename they can?t use even if they copy/paste! From: Unicode On Behalf Of Alex Plantema via Unicode Sent: Monday, June 10, 2024 12:20 PM To: unicode at corp.unicode.org Subject: Re: Question mark Op ma 10-06-2024 om 18:05 schreef Phil Smith III via Unicode: How is a question mark ?prohibited? by Windows? <==There?s one now, in Windows! It isn't allowed in file names because it serves as a wildcard. The same for the asterisk. -- Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From otto.stolz at uni-konstanz.de Mon Jun 10 12:33:55 2024 From: otto.stolz at uni-konstanz.de (Otto Stolz) Date: Mon, 10 Jun 2024 19:33:55 +0200 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: ?????? ????, am 2024-06-10 um 9:00?Uhr hast du geschrieben: > how difficult and how feasible is it to add a question mark to the > Unicode table that would be identical to the regular question mark but > usable in Windows operating systems? > Almost all characters prohibited in > Windows OS have their equivalents in the Unicode table, If I understand you correctly, you are looking for look-alikes of some punctuation characters, and you would like to employ those in file-names under the Windows operating system. However, this is not what Unicode is all about. Windows file-names is not the only instance of a character sequence that is bound to some syntactic rule, and Unicode surely cannot be expected to cope with all of these uncountable rules. > allowing the use of characters like "/", "", ":", etc. The look-alikes (or almost look-alikes) of these characters are no ?equivalences?; rather they are characters in their own right meant for their respective particular purposes. For example, U+2044 ???, the fraction slash, is used for composing arbitrary fractions, such as ?????, and it is not, by any means, an equivalence for U+002F ?/?, the solidus. > Almost all characters prohibited in Windows OS have their equivalents in the Unicode table Unicode is much, much more than a bare code table. You cannot really understand the Unicode Code Table without some knowledge of the main text of the Standard. For example, the use of punctuation characters is discussed in . To assist newcomers, there are introductions, such as and FAQ lists, cf. . Back to your current issue:?I guess, the users of a system such as the Windows OS?should cope with that system?s syntactic rules and not try to circumvent them: A file-name, for example, is not only interpreted by the system but also by the human user which could be confused by such look-alikes. For example, under Windows, the solidus delimits the folder-name from the file-name proper;?hence, a solidus look-alike would lead the human user to the wrong folder so he would not find the respective file on his disk or ? even worse ? confuse it with some other file in some other folder. I hope I?could help you. Otto From pkar at ieee.org Mon Jun 10 13:04:48 2024 From: pkar at ieee.org (Piotr Karocki) Date: Mon, 10 Jun 2024 20:04:48 +0200 Subject: Question mark Message-ID: In my humble opinion, only "portable filename character set" should be used in filenames. This is the one and only character set that is truly portable between operating systems, works everywhere and everytime, without any problems or inconveniences. Defined in POSIX (IEEE Std 1003.1) https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282 From: Unicode [mailto:unicode-bounces at corp.unicode.org] On Behalf Of Phil Smith III via Unicode Sent: Monday, 10 June 2024 18:24 To: unicode at corp.unicode.org Subject: RE: Question mark Ah. A key detail! I would not think that it would make sense to add this, as folks will be fatally confused by it. Same as putting slashes (back/forward) in filenames. Just Don?t Do It. Besides, any sane normalization would converge them anyway, right? And then people have a filename they can?t use even if they copy/paste! From: Unicode On Behalf Of Alex Plantema via Unicode Sent: Monday, June 10, 2024 12:20 PM To: unicode at corp.unicode.org Subject: Re: Question mark Op ma 10-06-2024 om 18:05 schreef Phil Smith III via Unicode: How is a question mark ?prohibited? by Windows? ?There?s one now, in Windows! It isn't allowed in file names because it serves as a wildcard. The same for the asterisk. -- Alex. From ecm.unicode at gmail.com Mon Jun 10 13:22:44 2024 From: ecm.unicode at gmail.com (Erik Carvalhal Miller) Date: Mon, 10 Jun 2024 14:22:44 -0400 Subject: Question mark In-Reply-To: References: Message-ID: On Monday, June 10, 2024, Piotr Karocki via Unicode < unicode at corp.unicode.org> wrote: ? without any problems or inconveniences Despite the imprimatur of persons with names such as ??????, I can?t quite agree. Surely the permissibility of a much broader range of characters is vastly better ? even if some common characters such as ??? and ?/? and ?:? aren?t invited along for the ride. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harjitmoe at outlook.com Mon Jun 10 14:15:41 2024 From: harjitmoe at outlook.com (Harriet Riddle) Date: Mon, 10 Jun 2024 19:15:41 +0000 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: The ASCII question mark, which is the one used as a shell wildcard and which isn't supported in filenames on some operating systems, is U+003F ? QUESTION MARK. Unicode has a couple more instances of the same symbol: U+FE56 ? SMALL QUESTION MARK is the question mark for *horizontal* text from Big5?while, U+FF1F ??FULLWIDTH QUESTION MARK is the question mark for *vertical*?text from Big5, unified with the question marks from JIS X 0208, GB 2312 and (what was at the time called) KS C 5601.? These exist in Unicode for round-trip compatibility with EUC-CN (i.e. the IANA's "GB2312"), Shift_JIS, EUC-JP, EUC-KR, ISO-2022-JP, mixed ASCII/Big5, and other encodings which combine those double-byte coded character sets with ASCII or modified ASCII. It seems unnecessary for Unicode to add more duplicate question marks besides those ones (my personal inclination would be to use U+FE56). For the sake of completeness, U+0294 ? LATIN LETTER GLOTTAL STOP looks similar, but not actually a question mark, unlike U+FE56 or U+FF1F. (I'm not 100% sure which "ugly, unattractive symbols" you are referring to but, if any of the other characters mentioned above look less attractive than the ASCII one, that's determined more by the font than by Unicode itself; adding yet another Unicode character (which will, at first, not be present in *any* existing font) would not help there.) ?Har. ________________________________________ From:?Unicode on behalf of ???? ????? via Unicode Sent:?10 June 2024 08:00 To:?unicode at corp.unicode.org Subject:?Question mark ? Hello! I've been wondering about the following question for a long time: how difficult and how feasible is it to add a question mark to the Unicode table that would be identical to the regular question mark but usable in Windows operating systems? Almost all characters prohibited in Windows OS have their equivalents in the Unicode table, allowing the use of characters like "/", "", ":", etc. However, there is no proper equivalent for the question mark. All the available options in the table are ugly, unattractive symbols that are inconvenient to use. From steffen at sdaoden.eu Mon Jun 10 14:50:53 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 10 Jun 2024 21:50:53 +0200 Subject: Question mark In-Reply-To: References: Message-ID: <20240610195053.0xZlT4TM@steffen%sdaoden.eu> Piotr Karocki via Unicode wrote in : |In my humble opinion, only "portable filename character set" should be used |in filenames. |This is the one and only character set that is truly portable between |operating systems, works everywhere and everytime, without any problems or |inconveniences. | |Defined in POSIX (IEEE Std 1003.1) |https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html\ |#tag_03_282 Only to note that the minimum acceptible path length of POSIX is 14, but DOS and 8+3 seems advisable, if you go that route. (I have lost it not so many years ago, myself.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From ecm.unicode at gmail.com Mon Jun 10 15:26:37 2024 From: ecm.unicode at gmail.com (Erik Carvalhal Miller) Date: Mon, 10 Jun 2024 16:26:37 -0400 Subject: Question mark In-Reply-To: References: <1718002814.340988646@f733.i.mail.ru> Message-ID: On Monday, June 10, 2024, Harriet Riddle via Unicode < unicode at corp.unicode.org> wrote: ? For the sake of completeness, U+0294 ? LATIN LETTER GLOTTAL STOP looks similar, but not actually a question mark, unlike U+FE56 or U+FF1F. If one?s going to go so far as to use the glottal stop as a substitute, one might as well decorate it with U+0323 COMBINING DOT BELOW: ????. Do it wrong right! Then of course there are the dingbats: U+2753 BLACK QUESTION MARK ORNAMENT ??? and U+2754 WHITE QUESTION MARK ORNAMENT ???. Even when given non?emojified appearance as with U+FE0E VARIATION SELECTOR-15, they may be too heavy, but suitability ultimately depends on one?s particular use case and one?s taste. The user might also find U+2047 DOUBLE QUESTION MARK ??? helpful; depending on context, U+2048 QUESTION EXCLAMATION MARK ??? and U+2049 EXCLAMATION QUESTION MARK ??? (both also subject to non?emojification) could also be useful. Note that all three invoke the normalization concerns raised by Phil Smith III. My usual solution: leave out the question marks altogether. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at akphs.com Mon Jun 10 15:30:45 2024 From: lists at akphs.com (Phil Smith III) Date: Mon, 10 Jun 2024 16:30:45 -0400 Subject: Question mark In-Reply-To: References: <1718002814.340988646@f733.i.mail.ru> Message-ID: <03aa01dabb75$13a52a10$3aef7e30$@akphs.com> > My usual solution: leave out the question marks altogether. Are you sure that?s what you want (See what I did there ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From 142857 at mail.de Mon Jun 10 16:53:27 2024 From: 142857 at mail.de (Alexander Schneider) Date: Mon, 10 Jun 2024 23:53:27 +0200 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: <00ee01dab9af$aebfc630$0c3f5290$@akphs.com> References: <00ee01dab9af$aebfc630$0c3f5290$@akphs.com> Message-ID: Maybe sai tells the cane manufacturers about those risks? They could use magnets (or whatever, that will not resets some cards) for: (Hand) loop >> connection << cane Btw.: I don't get it, how an emoji (sic!) has more influence than experience -> especially in a situation like this. However, sai, your post was very informative - and I am really impressed by your great formating skills. But shouldn't they wearing: a bracelet for the blinds, too? Possibly there are not enough pixels for such small details... Have a great time (all) & sorry for bad grammar > Am 08.06.2024 - 18:57 schrieb Phil Smith III via Unicode: > > > Charlotte Eiffel Lilith Buff wrote, in part: > >you have submitted your request to the Unicode mailing list, which is > >just a place for random people to discuss miscellaneous Unicode > >topics. Nothing that happens here is going to affect the development > >or implementation of the Unicode Standard. > > Then can someone suggest a better forum for Sai to make his point? > > While it seems relatively unlikely that anyone will be harmed by using a cane incorrectly because they saw it in an emoji, there is value in getting it right, as his examples demonstrate. Is there a First Nations emoji that looks like the old Washington Redskins mascot? Is there a Black emoji with a bone in its lip? Would those be ok? > > I have no dog in this specific fight, but it feels like people are saying ?Oh, this is just PC nitpicking?, and that?s oversimplifying it. This stuff is permanent(ish). Remember the fiasco with the Japanese combining characters, which nobody uses. Like that, this seems to suggest a lack of care/research by the Consortium into real-world usage. And isn?t real-world usage the fundamental goal of Unicode? > > ...phsiii ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSIT?T UND KOMFORT From ecm.unicode at gmail.com Mon Jun 10 17:15:41 2024 From: ecm.unicode at gmail.com (Erik Carvalhal Miller) Date: Mon, 10 Jun 2024 18:15:41 -0400 Subject: Question mark In-Reply-To: <03aa01dabb75$13a52a10$3aef7e30$@akphs.com> References: <1718002814.340988646@f733.i.mail.ru> <03aa01dabb75$13a52a10$3aef7e30$@akphs.com> Message-ID: 3F or not 3F: That is the question. (Though not essential to this discussion, 2B would be a plus.) On Monday, June 10, 2024, Phil Smith III via Unicode < unicode at corp.unicode.org> wrote: > > My usual solution: leave out the question marks altogether. > > Are you sure that?s what you want > > (See what I did there ) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prosfilaes at gmail.com Mon Jun 10 20:38:51 2024 From: prosfilaes at gmail.com (David Starner) Date: Mon, 10 Jun 2024 20:38:51 -0500 Subject: Question mark In-Reply-To: References: Message-ID: On Mon, Jun 10, 2024, 1:08 PM Piotr Karocki via Unicode < unicode at corp.unicode.org> wrote: > In my humble opinion, only "portable filename character set" should be used > in filenames. > This is the one and only character set that is truly portable between > operating systems, works everywhere and everytime, without any problems or > inconveniences. > That's just an obsolete relic of Unix-like systems. Virtually all systems will survive with 8.3, upper case letters only and only one period, splitting that 8 and 3. If you're worried about major current operating systems, most ASCII characters are fine, but you need to remember case-insensitivity. I'm not willing to live in that box, but even if you are, there's no reason to treat that list as terribly useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leob at mailcom.com Tue Jun 11 00:03:08 2024 From: leob at mailcom.com (Leo Broukhis) Date: Mon, 10 Jun 2024 22:03:08 -0700 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: On Sat, Jun 8, 2024 at 1:20?PM Doug Ewell via Unicode < unicode at corp.unicode.org> wrote: > > I never claimed that holding a cane with its bungee loop around one?s > wrist was not a safety hazard. That is a misrepresentation. My comment was > about reliance on vendors? emoji glyphs, especially at small size, to > illustrate or teach correct behavior. > ... see Karishma Shah?s public-review comment in > https://www.unicode.org/L2/L2018/18138-access-fdbk.pdf , which appears > not to have been heeded.) > ... > I don?t know that all people expect emoji glyphs to depict correct > behavior, but it is certainly possible that some do. But I would imagine > that blind people, and sighted people who work with them, would have > better, more authoritative, more carefully designed guidelines for the > proper use of equipment than emoji. > A more conceivable scenario is not misinformation of users of canes themselves, as all users of any equipment, in particular those dependent on the equipment for their everyday functioning, are to heed proper manufacturers' or medical professionals' guidelines rather than look at tangentially related emoji for edification; but rather a distraction/annoyance due to sighted well-wishers who might observe one of the emojis in question (nowadays often depicted in high resolution, especially on mobile devices when they appear by themselves), and then would attempt to pester people with a vision impairment about an allegedly incorrect technique of using a cane; said distraction itself a potential safety hazard. > I hope that vendors take this proposed change on board and make the glyphs > in their emoji fonts more consistent with safe and correct behavior. While acknowledging the merit of the current request, as well as the previously unheeded one of 2018, I hope that the vendors' heeding them does not engender a flurry of whimsical change requests regarding arbitrary emoji based on purported safety hazards. Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cate at cateee.net Tue Jun 11 00:29:25 2024 From: cate at cateee.net (Giacomo Catenazzi) Date: Tue, 11 Jun 2024 07:29:25 +0200 Subject: Question mark In-Reply-To: References: Message-ID: On 11.06.2024 03:38, David Starner via Unicode wrote: > On Mon, Jun 10, 2024, 1:08 PM Piotr Karocki via Unicode > > wrote: > > In my humble opinion, only "portable filename character set" should > be used > in filenames. > This is the one and only character set that is truly portable between > operating systems, works everywhere and everytime, without any > problems or > inconveniences. > > That's just an obsolete relic of Unix-like systems. Virtually all > systems will survive with 8.3, upper case letters only and only one > period, splitting that 8 and 3. If you're worried about major current > operating systems, most ASCII characters are fine, but you need to > remember case-insensitivity. I'm not willing to live in that box, but > even if you are, there's no reason to treat that list as terribly useful. The problem is not about operating systems, but file system, and if you follow StackOverflow and related sites you see many weird failures. For your personal files normally it is not a problem: do what you want. But you may get problems as the file touch a remote filesystem (network filesystem, including NAS, "the cloud", etc.), but also same filesystem on different computers (not necessary different operating system), like "usb pen" and other detachable hard-disks Unix-like systems works usually on bytes (so encoded strings), so fully "transparent" to encoding, but also fully failure if one user uses a different encoding compared to others. Because Unix-like systems (including Apple) went quickly to UTF-8, we forget about it, so sometime we have weird bugs with Japan or normalization. Microsoft uses code units, so if a filename contain invalid Unicode string (or just not writable), things may get difficult to access. (single surrogate is most common problem). Typing or also selecting a file not in your locale may be difficult (also on a GUI: if you see just replacement character, which one is a text file, and which it is a virus?) PS: Microsoft has over restriction in filename. "Com" is not allowed. And you get surprises if you uses some characters like space or & or +: they may work fine until you work "in the cloud" (but the cloud add much more restriction on filenames and paths). And just looking for the official solution of the initial question: microsoft can do a sort of escaping, for filesystem compatibility, but I cannot find anymore the translation list, but in meantime I discovered problems using control characters in filenames, and other weird things: we are far from ideal case where we can use Unicode characters (maybe without control characters) freely in filenames. So, not useful the "portable character set", but it is still necessary. Windows is still not fully committed to Unicode, so lazy programmers makes visible i18n bugs. giacomo From eliz at gnu.org Tue Jun 11 01:15:59 2024 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 11 Jun 2024 09:15:59 +0300 Subject: Question mark In-Reply-To: (message from Erik Carvalhal Miller via Unicode on Mon, 10 Jun 2024 16:26:37 -0400) References: <1718002814.340988646@f733.i.mail.ru> Message-ID: <86plso6m3k.fsf@gnu.org> > Date: Mon, 10 Jun 2024 16:26:37 -0400 > Cc: "unicode at corp.unicode.org" > From: Erik Carvalhal Miller via Unicode > > On Monday, June 10, 2024, Harriet Riddle via Unicode wrote: > > ? For the sake of completeness, U+0294 ? LATIN LETTER GLOTTAL STOP looks similar, but not actually a > question mark, unlike U+FE56 or U+FF1F. > > If one?s going to go so far as to use the glottal stop as a substitute, one might as well decorate it with U+0323 > COMBINING DOT BELOW: ????. Do it wrong right! > > Then of course there are the dingbats: U+2753 BLACK QUESTION MARK ORNAMENT ??? and U+2754 > WHITE QUESTION MARK ORNAMENT ???. Even when given non?emojified appearance as with U+FE0E > VARIATION SELECTOR-15, they may be too heavy, but suitability ultimately depends on one?s particular use > case and one?s taste. > > The user might also find U+2047 DOUBLE QUESTION MARK ??? helpful; depending on context, U+2048 > QUESTION EXCLAMATION MARK ??? and U+2049 EXCLAMATION QUESTION MARK ??? (both also subject > to non?emojification) could also be useful. Note that all three invoke the normalization concerns raised by Phil > Smith III. If this is about file names on MS-Windows, then there's another consideration to take into account: it might be unusually hard to name files by names that include exotic characters, if those characters are not supported by the current system codepage. For example, typing such names into the Windows terminal window might be cumbersome if not impossible, and the terminal's font might not support them. Worse, some programs might not be able to access such files at all. UTF-8 support is still in beta even on newest Windows versions, and programs we are used to using are largely not adapted to that yet. So caveat emptor. > My usual solution: leave out the question marks altogether. That's not always the user's choice, as we all know. From pkar at ieee.org Tue Jun 11 01:42:15 2024 From: pkar at ieee.org (Piotr Karocki) Date: Tue, 11 Jun 2024 08:42:15 +0200 Subject: Question mark In-Reply-To: References: <4bc909e3ea2e7bb75c363e12c8354e02@mail.gmail.com> Message-ID: <7cd8d51a210bfe02682a9d6fcc83a9d7@mail.gmail.com> > So ... POSIX uses the AsCII character set. POSIX - yes. But "portable filename character set" can be used without rest of POSIX standard, without ASCII (and ASCII is 7 bit only :) ) From cate at cateee.net Tue Jun 11 02:24:48 2024 From: cate at cateee.net (Giacomo Catenazzi) Date: Tue, 11 Jun 2024 09:24:48 +0200 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: <91da38b1-3496-4af5-8af1-360d82c5454a@cateee.net> On 2024-06-10 9:00, ???? ????? via Unicode wrote: > > Hello! I've been wondering about the following question for a long > time: how difficult and how feasible is it to add a question mark to > the Unicode table that would be identical to the regular question mark > but usable in Windows operating systems? Almost all characters > prohibited in Windows OS have their equivalents in the Unicode table, > allowing the use of characters like "/", "", ":", etc. > > However, there is no proper equivalent for the question mark. All the > available options in the table are ugly, unattractive symbols that are > inconvenient to use. > I still do not find the document of Microsoft on how to transcode characters invalid in Windows but valid in other systems (like `?`), but Wikipedia has a good reference on how to solve (on user side) the problem, using alternate characters: https://en.wikipedia.org/wiki/Filename#Problematic_characters The glottal stop ? (U+0294), the interrobang ? (U+203D), the inverted question mark ? (U+00BF), the double question mark ? (U+2047), and the black question mark ornament?(U+2753) are allowed in all filenames. An in an other site I found the full width characters may be used. In any case, please considere security implications on using any workaround (especially if file is shared). giacomo From lists at akphs.com Tue Jun 11 11:44:10 2024 From: lists at akphs.com (Phil Smith III) Date: Tue, 11 Jun 2024 12:44:10 -0400 Subject: Question mark In-Reply-To: <86plso6m3k.fsf@gnu.org> References: <1718002814.340988646@f733.i.mail.ru> <86plso6m3k.fsf@gnu.org> Message-ID: <04af01dabc1e$96d9ae20$c48d0a60$@akphs.com> Eli Zaretski made some trenchant points, including: >For example, typing such names into the Windows terminal window might >be cumbersome if not impossible, and the terminal's font might not >support them. Ah yes, the classic problem of ?which file do I want to use today?: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 905 bytes Desc: not available URL: From doug at ewellic.org Tue Jun 11 12:39:49 2024 From: doug at ewellic.org (Doug Ewell) Date: Tue, 11 Jun 2024 17:39:49 +0000 Subject: Question mark In-Reply-To: <1718002814.340988646@f733.i.mail.ru> References: <1718002814.340988646@f733.i.mail.ru> Message-ID: ???? ????? ???????: > I've been wondering about the following question for a long time: how > difficult and how feasible is it to add a question mark to the Unicode > table that would be identical to the regular question mark but usable > in Windows operating systems? Almost all characters prohibited in > Windows OS have their equivalents in the Unicode table, allowing the > use of characters like "/", "", ":", etc. As far as difficulty and feasibility are concerned: One would need to write and submit a proposal that explains why encoding an identical-looking character, with identical Unicode properties, and intended for use with the same set of writing systems, as an existing character which is syntactically significant in many environments ? XML, URIs, regular expressions, many programming languages ? would not create a tremendous security problem. Unicode does not typically encode lookalike, or near-lookalike, characters with identical properties for the sole purpose of looking alike. There is usually some functional difference between the two, and that difference must be defined by Unicode, not by (for example) the syntax rules of a particular vendor?s file system. File names, like domain names, are identifiers. They are not required, and usually are not expected, to have all the flexibility of ordinary text in human languages. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From doug at ewellic.org Tue Jun 11 12:44:52 2024 From: doug at ewellic.org (Doug Ewell) Date: Tue, 11 Jun 2024 17:44:52 +0000 Subject: Question mark In-Reply-To: References: Message-ID: Giacomo Catenazzi ha scritto: > Microsoft uses code units, so if a filename contain invalid Unicode > string (or just not writable), things may get difficult to access. > (single surrogate is most common problem). Several years ago, I asked on this list if anyone had ever actually seen an unpaired surrogate in a Windows filename (other than in a test environment), or if that was just a theoretical problem. And I heard... nothing. But the legend continues. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From steffen at sdaoden.eu Tue Jun 11 15:32:10 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 11 Jun 2024 22:32:10 +0200 Subject: Question mark In-Reply-To: References: Message-ID: <20240611203210.HDjE94tA@steffen%sdaoden.eu> Giacomo Catenazzi via Unicode wrote in : |On 11.06.2024 03:38, David Starner via Unicode wrote: |> On Mon, Jun 10, 2024, 1:08 PM Piotr Karocki via Unicode |> > wrote: |> |> In my humble opinion, only "portable filename character set" should |> be used |> in filenames. ... |The problem is not about operating systems, but file system, and if you |follow StackOverflow and related sites you see many weird failures. For |your personal files normally it is not a problem: do what you want. But |you may get problems as the file touch a remote filesystem (network |filesystem, including NAS, "the cloud", etc.), but also same filesystem |on different computers (not necessary different operating system), like |"usb pen" and other detachable hard-disks | |Unix-like systems works usually on bytes (so encoded strings), so fully ... |Microsoft uses code units, so if a filename contain invalid Unicode |string (or just not writable), things may get difficult to access. |(single surrogate is most common problem). | |Typing or also selecting a file not in your locale may be difficult |(also on a GUI: if you see just replacement character, which one is a |text file, and which it is a virus?) | |PS: Microsoft has over restriction in filename. "Com" is not allowed. These are special names like "aux"[.any-extension??] which have a special Microsoft (or DOS?) specific meaning, in each and every directory (as far as i know). lpr, nul and whatnot, i think. Just like /dev/null, /dev/tty in Unix, but without hierarchy. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From public at khwilliamson.com Tue Jun 11 16:37:11 2024 From: public at khwilliamson.com (Karl Williamson) Date: Tue, 11 Jun 2024 15:37:11 -0600 Subject: Request for immediate changes to PERSON WITH WHITE CANE (etc) emoji In-Reply-To: References: Message-ID: <7acdc998-9542-493f-b8f0-4722d11e3fc8@khwilliamson.com> Because of this discussion, I just examined my son-in-law's one year old cane (picture attached). This new one is gray, presumably because the material is reflective, designed to shine brightly under headlights and the like. I seem to remember that the old one was whiter. It has a bungee-like cord tying the sections together, and coming out of the center of the top are two strands forming a loop, which is long enough that a wrist could be put through it. But it is knotted so as to make that not feasible. He said he tied those himself, and that on occasion he has used it with his wrist inserted. -------------- next part -------------- A non-text attachment was scrubbed... Name: cane.jpg Type: image/jpeg Size: 139565 bytes Desc: not available URL: From public at khwilliamson.com Thu Jun 13 20:55:51 2024 From: public at khwilliamson.com (Karl Williamson) Date: Thu, 13 Jun 2024 19:55:51 -0600 Subject: Name Property in Regular Expressions In-Reply-To: <50d7140c-0be1-4630-b3b5-7d39d08280b1@it.aoyama.ac.jp> References: <50d7140c-0be1-4630-b3b5-7d39d08280b1@it.aoyama.ac.jp> Message-ID: <3b4af4b2-cca6-40af-9ff3-7832e1768715@khwilliamson.com> On 5/10/24 02:11, Martin J. D?rst via Unicode wrote: > Dear Unicoders, > > I hope this more on-topic than the most recent discussions. > > I have some questions regarding name properties in regular expressions, > i.e. about > https://www.unicode.org/reports/tr18/#Name_Properties > > 1) When matching (see also > https://www.unicode.org/reports/tr44/#Matching_Rules), it's clear that > "zero-width space" is equivalent to "ZERO WIDTH SPACE" or > "zerowidthspace", but should something like > "Ze-rowi-dThsp ace" (hyphens or spaces in the wrong places) also be > equivalent? Perl, since version 5.16, released May 2012, implements this, though it requires explicit enabling. You may find its documentation illuminating (the references to outside the paragraph are not relevant here): LOOSE MATCHES By specifying ":loose", Unicode's loose character name matching rules are selected instead of the strict exact match used otherwise. That means that *CHARNAME* doesn't have to be so precisely specified. Upper/lower case doesn't matter (except with scripts as mentioned above), nor do any underscores, and the only hyphens that matter are those at the beginning or end of a word in the name (with one exception: the hyphen in U+1180 "HANGUL JUNGSEONG O-E" does matter). Also, blanks not adjacent to hyphens don't matter. The official Unicode names are quite variable as to where they use hyphens versus spaces to separate word-like units, and this option allows you to not have to care as much. The reason non-medial hyphens matter is because of cases like U+0F60 "TIBETAN LETTER -A" versus U+0F68 "TIBETAN LETTER A". The hyphen here is significant, as is the space before it, and so both must be included. ":loose" slows down look-ups by a factor of 2 to 3 versus ":full", but the trade-off may be worth it to you. Each individual look-up takes very little time, and the results are cached, so the speed difference would become a factor only in programs that do look-ups of many different spellings, and probably only when those look-ups are through "vianame()" and "string_vianame()", since "\N{...}" look-ups are done at compile time. > > 2) TR 18 suggests wildcards such as \p{name=/ALIEN/}. This looks very > convenient, but I have doubts that implementation was really considered > when writing this down. In essence, this would have to run a regular > expression over close to one megabyte of name data (+some additional > processing for the algorithmically defined names), just to compile the > regular expression. (It's possible to speed that up with some clever > indexing, but this would only add additional complexity and space.) > So my question is whether anybody actually knows about some > implementation of this name wildcard feature. > Perl, since version 5.32, released June 2020, implements this, though it is still marked as experimental. I ran time perl -l -e 'qr(\p{name=/ALIEN/})' The output was The Unicode property wildcards feature is experimental at -e line 1. real 0m00.01s user 0m00.01s sys 0m00.00s on a 2 year-old Linux box. Turning on the display of what got compiled gave ANYOFRb[1F47D-1F47E] (First UTF-8 byte=F0) That is basically an assembly language level statement for the perl pattern matcher. But you can see that there are only two code points that match in all of Unicode, and that any UTF-8-encoded string that matches either of these must contain the byte 0xF0. This knowledge allows the matcher to use a fast hardware instruction to rule out likely long stretches of a string being matched (Of course, further optimizations would be possible.) From asmusf at ix.netcom.com Tue Jun 18 16:58:21 2024 From: asmusf at ix.netcom.com (Asmus Freytag) Date: Tue, 18 Jun 2024 14:58:21 -0700 Subject: Emoji function as... Message-ID: Emoji function as... https://youtube.com/shorts/M-WYLC5pF-g?si=O7rT68ijNGjg158D A./ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskass at code2001.com Wed Jun 19 19:58:57 2024 From: jameskass at code2001.com (James Kass) Date: Thu, 20 Jun 2024 00:58:57 +0000 Subject: Emoji function as... In-Reply-To: References: Message-ID: <9e588a89-3251-4720-ae57-d8d72fe5b1db@code2001.com> On 2024-06-18 9:58 PM, Asmus Freytag via Unicode wrote: > > > Emoji function as... > > https://youtube.com/shorts/M-WYLC5pF-g?si=O7rT68ijNGjg158D > > A./ > This concept was discussed on this list prior to emoji encoding in Unicode.? There were several posts concerning this in our lively discussion back then.? Among the rebuttals, this one from John Hudson was well stated, IMO. https://www.unicode.org/mail-arch/unicode-ml/y2008-m12/0176.html