RE: Terms for rotations
Might also be useful that the primary purpose of the character names is to provide unique, reference identifiers that should be reasonably reflective of the character identity. But they don't need to guarantee unambiguous understanding of the character identity absent of any additional information. In particular, two things that can be assumed when interpreting a character name to understand the character identity are (1) access to the representative glyph for the character from the code charts, and (2) access to the name and representative glyph from the code charts for related characters. So, for example, the identity of 026F LATIN SMALL LETTER TURNED M and 1D1F LATIN SMALL LETTER SIDEWAYS TURNED M can only be clearly understood in reference to the representative glyphs for these characters and to 006D LATIN SMALL LETTER M. Peter -Original Message- From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Whistler, Ken Sent: Monday, November 10, 2014 4:12 PM To: Jean-François Colson Cc: Whistler, Ken; unicode@unicode.org Subject: RE: Terms for rotations > Look at this picture: > http://www.permisecole.com/code-route/priorites/faux-carrefour-a-sens- > giratoire.jpg Imagine you sit in this car and you want to turn RIGHT. > What will you do? Will you turn the driving wheel clockwise or > counterclockwise? And now imagine that you are motoring in a 1904 Cyklonette. Which way would you move the tiller? ;-) Seriously, I think that Ilya's point is well-taken. Although in English there is a strong association of the phrase "turn to the right" with clockwise motion for control devices which rotate, if you take the phrase out of that mechanical context and just talk about the orientation of pictures on paper, there can be some ambiguity based on the conceptual confusion with the concept of "turning to[wards] facing the right", which can mean something very different for symbols which seem to have built-in directions, like arrows. --Ken ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
RE: Terms for rotations
> WIDDERSHINS is shorter then > COUNTERCLOCKWISE, but is not exactly a common term, especially in > technical English. Aye, but laddie, then we'd have to use DEASIL for CLOCKWISE! And we'd have wiccans after us to spell it "DEOSIL" instead. ;-) --Ken ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
On Mon, Nov 10, 2014 at 4:12 PM, Whistler, Ken wrote: > Seriously, I think that Ilya's point is well-taken. Although in English > there is a strong association of the phrase "turn to the right" with > clockwise motion for control devices which rotate, if you take the > phrase out of that mechanical context and just talk about the > orientation of pictures on paper, there can be some ambiguity > based on the conceptual confusion with the concept of > "turning to[wards] facing the right", which can mean something > very different for symbols which seem to have built-in > directions, like arrows. So is there anything wrong with CLOCKWISE and COUNTERCLOCKWISE? TURNED COUNTERCLOCKWISE seems a little verbose. WIDDERSHINS is shorter then COUNTERCLOCKWISE, but is not exactly a common term, especially in technical English. -- Kie ekzistas vivo, ekzistas espero. ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
On Tue, Nov 11, 2014 at 12:43:05AM +0100, Jean-François Colson wrote: > > (I believe that people associate left ↔ counterclockwise etc only > >because for many shapes, visually, the bottom is just a pedestal > >for the top. So you “grab” the shape “on top”.] > > Look at this picture: > http://www.permisecole.com/code-route/priorites/faux-carrefour-a-sens-giratoire.jpg > Imagine you sit in this car and you want to turn RIGHT. What will > you do? Will you turn the driving wheel clockwise or > counterclockwise? It is not clear what you mean here. Should I take into account that the car is parked (judging by the hands being not on the steering wheel in 1:51 position)? (And parked where parking is more or less clearly illegal?) Should I take into account that the previous stretch of the road is curving right, but the current short segment is straight? [You see: currently, I teach very small kids, and try to make my problems as unambiguous as possible. ;-] Ilya ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
RE: Terms for rotations
> Look at this picture: > http://www.permisecole.com/code-route/priorites/faux-carrefour-a-sens-giratoire.jpg > Imagine you sit in this car and you want to turn RIGHT. What will you > do? Will you turn the driving wheel clockwise or counterclockwise? And now imagine that you are motoring in a 1904 Cyklonette. Which way would you move the tiller? ;-) Seriously, I think that Ilya's point is well-taken. Although in English there is a strong association of the phrase "turn to the right" with clockwise motion for control devices which rotate, if you take the phrase out of that mechanical context and just talk about the orientation of pictures on paper, there can be some ambiguity based on the conceptual confusion with the concept of "turning to[wards] facing the right", which can mean something very different for symbols which seem to have built-in directions, like arrows. --Ken ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
Le 11/11/14 00:43, Jean-François Colson a écrit : Le 10/11/14 22:36, Ilya Zakharevich a écrit : On Fri, Nov 07, 2014 at 02:39:58PM -0800, Garth Wallace wrote: I'm leaning towards "turned", "left rotated", and "right rotated" for the cardinal orientations, … Please keep in mind that left/right are especially bad terms to describe rotations. When you rotate the character cell about its center, some parts move to the right, some parts move to the left — both when the rotation is clockwise and counterclockwise. Which of the words left/right LOOKS better suited to describe a particular rotation depends on whether the top or the bottom OF WHAT YOU ROTATE is more “visually important”. (We saw it many times when discussing the math of the rotations with small kids.) Try to rotate ↓ left ;-]. (I believe that people associate left ↔ counterclockwise etc only because for many shapes, visually, the bottom is just a pedestal for the top. So you “grab” the shape “on top”.] Look at this picture: http://www.permisecole.com/code-route/priorites/faux-carrefour-a-sens-giratoire.jpg Imagine you sit in this car and you want to turn RIGHT. What will you do? Will you turn the driving wheel I meant “steering wheel”… clockwise or counterclockwise? ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
Le 10/11/14 22:36, Ilya Zakharevich a écrit : On Fri, Nov 07, 2014 at 02:39:58PM -0800, Garth Wallace wrote: I'm leaning towards "turned", "left rotated", and "right rotated" for the cardinal orientations, … Please keep in mind that left/right are especially bad terms to describe rotations. When you rotate the character cell about its center, some parts move to the right, some parts move to the left — both when the rotation is clockwise and counterclockwise. Which of the words left/right LOOKS better suited to describe a particular rotation depends on whether the top or the bottom OF WHAT YOU ROTATE is more “visually important”. (We saw it many times when discussing the math of the rotations with small kids.) Try to rotate ↓ left ;-]. (I believe that people associate left ↔ counterclockwise etc only because for many shapes, visually, the bottom is just a pedestal for the top. So you “grab” the shape “on top”.] Look at this picture: http://www.permisecole.com/code-route/priorites/faux-carrefour-a-sens-giratoire.jpg Imagine you sit in this car and you want to turn RIGHT. What will you do? Will you turn the driving wheel clockwise or counterclockwise? ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Rotations, SignWriting, and Mr Potato Head
Oups, I forgot to update the subject, AND made a misprint On Mon, Nov 10, 2014 at 02:01:09PM -0800, I wrote: > See, for example, the Mr Potato Head font > http://www.unicode.org/mail-arch/unicode-ml/y2014-m09/0003.html > ; using the same principles, one could encode most (all?) of the hand > symbols as >SignWriting FACE STARTER CHARACTER + upper/lower-script modifiers > For example, hand with fingers 1,2 extended, 3,4 crossed, and 5 bent > halfway could have been encoded as >☆¹²³ˣ⁴⁵ᶜ Of course, it should have been SignWriting HAND STARTER CHARACTER + upper/lower-script modifiers (but the same holds for SignWriting faces etc). And ☆ is supposed to be just a placeholder glyph for the HAND STARTER. Sorry, Ilya ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
On Mon, Nov 10, 2014 at 06:30:37PM +, Whistler, Ken wrote: > > Could the characters SWR2 to SWR8 be applied to chess symbols or should > > new rotation modifiers be created for them? > > They aren't currently defined to do so -- and there is certainly a danger in > opening up the applicability to other sets of symbols, as that would start > down the road of trying to turn them into generic rotation mechanisms. > > I'm inclined here to trust Garth's assessment that for a relatively small > set of rotated chess symbols, the simpler solution is just to enumerate > the set of rotated forms needed for these odd chess notations as > unitary symbols. I just wanted to make sure that the precedent for > SignWriting was part of the consideration, given the fact that > a notation involving rotation of symbols was the topic. Sorry, I had no time (and no clear way to express things) when what I’m going to write could have been more relevant — anyway, this is about SignWriting. I consider the precedent of SignWriting as an especially bad model to become a base for other encodings of extensive collections — and not since it uses “many mechanisms”, but FEW mechanisms. I think that the same functionality could have been implemented using a tiny handful of new characters — while making the encoded SignWriting text readable EVEN WITHOUT SPECIAL FONTS and/or shaping engines. See, for example, the Mr Potato Head font http://www.unicode.org/mail-arch/unicode-ml/y2014-m09/0003.html ; using the same principles, one could encode most (all?) of the hand symbols as SignWriting FACE STARTER CHARACTER + upper/lower-script modifiers For example, hand with fingers 1,2 extended, 3,4 crossed, and 5 bent halfway could have been encoded as ☆¹²³ˣ⁴⁵ᶜ A specialized font would show the needed glyph. Without a specialized font, one could see a representation which allows one able to visualize the shape — and, at least, see a certain distinctive rendition. As far as I checked (about 60% into the SignWriting proposal) this approach would enable all of SignWriting functionality with about 10 base characters needed. As for rotation modifiers, we already have 24 (?) clock face symbols — and they allow granularity of 15° when specifying the rotation. Yous, Ilya ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Terms for rotations
On Fri, Nov 07, 2014 at 02:39:58PM -0800, Garth Wallace wrote: > I'm leaning towards "turned", "left rotated", and "right rotated" for > the cardinal orientations, … Please keep in mind that left/right are especially bad terms to describe rotations. When you rotate the character cell about its center, some parts move to the right, some parts move to the left — both when the rotation is clockwise and counterclockwise. Which of the words left/right LOOKS better suited to describe a particular rotation depends on whether the top or the bottom OF WHAT YOU ROTATE is more “visually important”. (We saw it many times when discussing the math of the rotations with small kids.) Try to rotate ↓ left ;-]. (I believe that people associate left ↔ counterclockwise etc only because for many shapes, visually, the bottom is just a pedestal for the top. So you “grab” the shape “on top”.] Hope this helps, Ilya ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about “Uppercase” in DerivedCoreProperties.txt
Philippe Verdy wrote: |The standard C++ "string" package could have then used this standard |internally in the methods exposed in its API. I cannot understand this |simple effort was never done on such basic functionality needed and used in |almost all softwares and OSes. There are plenty of other things one can bang his head on as necessary, _that_ is for sure. Even overwhelmingly, the pessimistic may say. --steffen ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about “Uppercase” in DerivedCoreProperties.txt
Philippe Verdy wrote: |Successors to convert strings instead of just isolated "characters" (sorry, |they are NOT what we need to handle "texts", they are not even equivalent |to Unicode characters, they are just code units, most often 8-bit with |"char" or 16-bit only with "wchar_t" !) already exist in all C libraries |(including glibc), under different names unfortunately (this is the main |cause why there are complex header files trying to find the appropriate |name, and providing a "default" basic implementation that just scans |individual characters to filter them with tolower and toupper: this is a |bad practice, glibc is the _only_ standard C library i know of that supports its own homebrew functionality regarding the issue (and in a way that i personally don't want to and will never work with). Even the newest ISO C doesn't give just any hand, so that no ISO C programmer can expect to use any standard facility before 2020, if that is the time, and then operating systems have to adhere to that standard, and then programmers have to be convinced to use those functions. Until then different solutions will have to be used. --steffen ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about “Uppercase” in DerivedCoreProperties.txt
The equivalent of strtolower() and strtoupper() is implemented in all C libraries I know (yes, including glibc) and I have worked with on various OSes (and since very long!), even if their names change (because of the unfortunate lack of standardization about their interaction with C locales). The standardisation of these two functions should have already been made since very long, even if the locales support could be limited to the legacy basic C locale with limited functionality, where these functions would just scan characters through strings to convert them with toupper() and to lower(). But then glibc and other libraries wiould have implemented this standard. For now, we still need complex "config" scripts to detect the correct headers to include, or to provide a basic implementation via various macros. The standard C++ "string" package could have then used this standard internally in the methods exposed in its API. I cannot understand this simple effort was never done on such basic functionality needed and used in almost all softwares and OSes. 2014-11-10 19:55 GMT+01:00 Steffen Nurpmeso : > Philippe Verdy wrote: > |Successors to convert strings instead of just isolated "characters" > (sorry, > |they are NOT what we need to handle "texts", they are not even equivalent > |to Unicode characters, they are just code units, most often 8-bit with > |"char" or 16-bit only with "wchar_t" !) already exist in all C libraries > |(including glibc), under different names unfortunately (this is the main > |cause why there are complex header files trying to find the appropriate > |name, and providing a "default" basic implementation that just scans > |individual characters to filter them with tolower and toupper: this is a > |bad practice, > > glibc is the _only_ standard C library i know of that supports its > own homebrew functionality regarding the issue (and in a way that > i personally don't want to and will never work with). > Even the newest ISO C doesn't give just any hand, so that no ISO C > programmer can expect to use any standard facility before 2020, if > that is the time, and then operating systems have to adhere to > that standard, and then programmers have to be convinced to use > those functions. > Until then different solutions will have to be used. > > --steffen > ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
RE: Terms for rotations
> > http://www.unicode.org/L2/L2012/12321-n4342-signwriting.pdf > > > > That should give you some ideas about possible alternative approaches > > for the material you are dealing with. > > > > --Ken > > Could the characters SWR2 to SWR8 be applied to chess symbols or should > new rotation modifiers be created for them? They aren't currently defined to do so -- and there is certainly a danger in opening up the applicability to other sets of symbols, as that would start down the road of trying to turn them into generic rotation mechanisms. I'm inclined here to trust Garth's assessment that for a relatively small set of rotated chess symbols, the simpler solution is just to enumerate the set of rotated forms needed for these odd chess notations as unitary symbols. I just wanted to make sure that the precedent for SignWriting was part of the consideration, given the fact that a notation involving rotation of symbols was the topic. --Ken ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about “Uppercase” in DerivedCoreProperties.txt
Successors to convert strings instead of just isolated "characters" (sorry, they are NOT what we need to handle "texts", they are not even equivalent to Unicode characters, they are just code units, most often 8-bit with "char" or 16-bit only with "wchar_t" !) already exist in all C libraries (including glibc), under different names unfortunately (this is the main cause why there are complex header files trying to find the appropriate name, and providing a "default" basic implementation that just scans individual characters to filter them with tolower and toupper: this is a bad practice, Good libraries should all contain a safe implementation of case conversion of strings, and softwares should use them (and not reinvent this old bad trick, just because this works with basic English). 2014-11-10 13:41 GMT+01:00 Steffen Nurpmeso : > Philippe Verdy wrote: > |glibc is not more borken and any other C library implementing toupper and > |tolower from the legacy "ctype" standard library. These are old APIs that > |are just widely used and still have valid contexts were they are simple > and > |safe to use. But they are not meant to convert text. > > Hah! Legacy is good.. I'd wish a usable successor were already > standardized by ISO C. > > --steffen > ___ > Unicode mailing list > Unicode@unicode.org > http://unicode.org/mailman/listinfo/unicode > ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about "Uppercase" in DerivedCoreProperties.txt
Philippe Verdy wrote: > glibc is not more borken and any other C library implementing toupper > and tolower from the legacy "ctype" standard library. These are old > APIs that are just widely used and still have valid contexts were they > are simple and safe to use. But they are not meant to convert text. Well, of course they are *meant* to convert text. They're just not very good at it. -- Doug Ewell | Thornton, CO, USA | http://ewellic.org ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
Re: Question about “Uppercase” in DerivedCoreProperties.txt
Philippe Verdy wrote: |glibc is not more borken and any other C library implementing toupper and |tolower from the legacy "ctype" standard library. These are old APIs that |are just widely used and still have valid contexts were they are simple and |safe to use. But they are not meant to convert text. Hah! Legacy is good.. I'd wish a usable successor were already standardized by ISO C. --steffen ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
