Re: What happened to Unicode CLDR's site?
On 4 Oct 2016, at 8:51, Cristian Secară wrote: > În data de Tue, 4 Oct 2016 19:50:05 +0800, gfb hjjhjh a scris: > >> Why is the site suspended by Google and how to access it now? > > Just curious: Unicode = Google ? (physically) well, does not look Google to me… but see below // dig unicode.org NS ;; ANSWER SECTION: unicode.org.86400 IN NS nserver.euro.apple.com. unicode.org.86400 IN NS nserver2.apple.com. unicode.org.86400 IN NS nserver3.apple.com. unicode.org.86400 IN NS nserver.apple.com. unicode.org.86400 IN NS nserver.asia.apple.com. unicode.org.86400 IN NS nserver4.apple.com. /// dig unicode.org A ;; ANSWER SECTION: unicode.org.2757IN A 216.97.88.9 whois 216.97.88.9 NetRange: 216.97.0.0 - 216.97.127.255 CIDR: 216.97.0.0/17 NetName:CORESPACE-4 NetHandle: NET-216-97-0-0-1 Parent: NET216 (NET-216-0-0-0-0) NetType:Direct Allocation OriginAS: AS54489 Organization: CoreSpace, Inc. (CORES-27) RegDate:2000-08-23 Updated:2013-02-21 Ref:https://whois.arin.net/rest/net/NET-216-97-0-0-1 OrgName:CoreSpace, Inc. OrgId: CORES-27 Address:7505 John W. Carpenter Freeway City: Dallas StateProv: TX PostalCode: 75247 Country:US RegDate:2009-08-10 Updated:2012-04-30 Ref:https://whois.arin.net/rest/org/CORES-27 // BUT: dig cldr.unicode.org A ;; ANSWER SECTION: cldr.unicode.org. 37687 IN CNAME ghs.google.com. ghs.google.com. 86400 IN CNAME ghs.l.google.com. ghs.l.google.com. 230 IN A 173.194.208.121 so cldr seems to be hosted by Google. Marc. > > I am asking this because by entering directly http://cldr.unicode.org > the error result belongs to Google and not to unicode.org. > > ? > > Cristi > > -- > Cristian Secară > http://www.secărică.ro
Re: Proposal for German capital letter "ß"
On 9 Dec 2015, at 23:32, Martin J. Dürst wrote: On 2015/12/10 09:30, Mark E. Shoulson wrote: I remember when we went through all this the first time around, encoding ẞ in the first place. People were saying "But the Duden says no!!!" And someone then pointed out, "Please close your Duden and cast your gaze upon ITS FRONT COVER, where you will find written in inch-high capitals plain as day, "DER GROẞE DUDEN" (http://www.typografie.info/temp/GrosseDuden.jpg) So in terms of prescription vs description, the Duden pretty much torpedoes itself. This is an interesting example of a phenomenon that turns up in many other contexts, too. A similar example is the use of accents on upper-case letters in French in France where 'officially', upper-case letters are written without accents. while in Québec, upper-case letters are written _with_ accents. l10n… Marc. When working on internationalization, it's always good to keep eyes open and not just only follow the rules. However, the example is also somewhat misleading. The book in the picture is clearly quite old. The Duden that was cited is new. I checked with "Der Grosse Duden" on Amazon, but all the books I found had the officially correct spelling. On the other hand, I remember that when the upper-case sharp s came up for discussion in Unicode, source material showed that it was somewhat popular quite some time ago (possibly close in age with the old Duden picture). So we would have to go back and check the book in the picture to see what it says about ß to be able to claim that Duden was (at some point in time) inconsistent with itself. Regards, Martin.
Re: Unicode in passwords
On 5 Oct 2015, at 8:14, Shriramana Sharma wrote: I recently came across this bug report where a filesystem encrypted with a Cyrillic script password could not be decrypted at boot time: https://bugzilla.redhat.com/show_bug.cgi?id=681250 And? From what I understand, this is related to the fact that the OS has two levels of boot/console/installation scripts and the first level is very basic regarding i18n (i.e. us-ascii only guaranteed to work). Marc. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Unicode in passwords
On 5 Oct 2015, at 9:42, Shriramana Sharma wrote: On 10/5/15, Marc Blanchet <marc.blanc...@viagenie.ca> wrote: On 5 Oct 2015, at 8:14, Shriramana Sharma wrote: https://bugzilla.redhat.com/show_bug.cgi?id=681250 And? Well the OP did say: I'm researching potential problems and best practices for password policies that allow non-Latin-1 Unicode characters. The link seemed valid food for the research as was offerred FWIW. sure. but roughly one could conclude from the bug report that only allow us-ascii is safe, which may not be what could be « best practices » depending on the point of view… Marc. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Unicode in passwords
On 5 Oct 2015, at 10:47, Shriramana Sharma wrote: I had hoped it would be obvious my reply was not intended to the "best practices" part of the OP, but to the "potential problems" part of it... sure. my comment was also just informative, not targeting to your comment, but targeting the fact that « best practices » may not be « us-ascii » only if you want to be i18n. Marc. In any case, I have nothing further to say on this topic. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Unicode in passwords
On 30 Sep 2015, at 12:33, John O'Conner wrote: I'm researching potential problems and best practices for password policies that allow non-Latin-1 Unicode characters. My searching of the unicode.org site showed me a general security considerations document (UTR #36) but nothing specific for password policies using Unicode. Can you recommend any documents to help me understand potential issues (if any) for password policies and validation methods that allow characters from more "exotic" portions of the Unicode space? the IETF have been doing work related to this exact issue. You might want to look at RFC7564 (generic framework) and RFC7613 (username and passwords, used in various IETF protocols). Marc. Best regards, John O'Conner
Re: The NEW Keyboard Layout—IEAOU
Le 2015-01-26 à 11:13, philip chastney philip_chast...@yahoo.com a écrit : as anybody who has tried to type with a cat on their lap will confirm, there are times when a left- or right-handed bias in the keyboard layout is a positive advantage I would then suggest the name of the keyboard to be MEOW Marc. /phil On Mon, 26/1/15, Martin J. Dürst due...@it.aoyama.ac.jp wrote: Subject: Re: The NEW Keyboard Layout—IEAOU To: Robert Wheelock rwhlk...@gmail.com, unicode@unicode.org unicode@unicode.org Date: Monday, 26 January, 2015, 1:22 AM What's better on this keyboard when compared to the Dvorak layout? At first sight, it looks heavily right-handed, all the letters that the Dvorak keyboard has on the homerow are on the right hand. Regards, Martin. P.S.: I'm a happy Dvorak user. On 2015/01/26 06:54, Robert Wheelock wrote: Hello! I came up with a BRAND-NEW keyboard layout designed to make typing easier——named the IEAOU (ee-eh-ah-oh-oo) System—based on letter frequencies. The letters in the new IEAOU layout are arranged as follows: (TOP): Digits / Punctuation / Accents (MEDIAL): Q Y :|; W |' L N D T S H +|= \|! (HOME): X K G F ´|` P I E A O U (BOTTOM): C J Z V B M R |, |. ?|/ Please respond to air what you’d think of it. Thank You! ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode ___ 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: The Ruble sign has been approved
Le 2013-12-12 à 13:42, Asmus Freytag asm...@ix.netcom.com a écrit : The Euro was the first currency symbol added which was presented to the world as a logo. In the context of encoding the character, the UTC and WG2 (quite correctly) at the time made clear that what was being encoded was a generic character code that encompasses all font designs and that use of the character code would not guarantee an appearance matching the logo design. The bureaucrats were a bit hesitant at first, but very soon actual typefaces appeared and it turned out to be no problem at all having the currency symbol harmonize with the font. Same for iso-8859-15 which included the Euro. However, I don't remember if 8859-15 was done in parallel or after. Most likely after. Marc. There is no question that UTC is fully entitled to define the range of glyph representations encompassed by a character code. For example for most letters they encompass any traditional or decorative rendering, while for something like the ESTIMATED symbol, it is understood that the intent is to encode a rather specific depiction of a lower case 'e'. For currency symbols, the precedent established by long standing symbols like the $ and confirmed for the euro is that a symbol shape harmonizing with the font falls inside the glyph variation encompassed by the character code. Only if that precedent were to be disregarded for some future symbol would it be necessary for UTC to include guidance. A./ On 12/12/2013 9:29 AM, Philippe Verdy wrote: In my opinion, this is going too far for the UTC. Such guidance can only come from Russian authorities for the application of its law, where it is relevant to apply it. Even for the Euro, there's ample variations allowed in Unicode, that does not affect conformance, even if there may be further restrictions on them in specific contexts. We are out of scope of TUS, unless there's a clear standard coming from law or from a national standard body, defining a clear context of use where a more precise shape design would be normatively used (and should then be present in fonts in one of the implemented variants). 2013/12/12 William_J_G Overington wjgo_10...@btinternet.com Michael Everson ever...@evertype.com wrote: I’m already on it. Excellent. Would it be possible please for encoding to include specific official guidance, going back to a source with provenance, as to whether a glyph for the symbol in a serif font should or should not have serifs? William Overington 12 December 2013
Re: Interoperability is getting better ... What does that mean?
Le 2012-12-30 à 17:41, Jukka K. Korpela a écrit : 2012-12-30 23:22, Costello, Roger L. wrote: I have heard it stated that, in the context of character encoding and decoding: Interoperability is getting better. Where? It seems that this is what *you* are saying. Do you have data to back up the assertion that interoperability is getting better? Do you? Below is a summary of my understanding of interoperability. This seems to revolve around just the encoding of web pages, specifically the problem that sometimes the encoding has not been properly declared. I haven’t seen any data on the relative frequency of such problems, and I don’t know what such data would be useful for. But in my experience, such problems have been become more common, mainly because people using different encodings. One reason is that people think UTF-8 is favored but don’t quite know how to use it, e.g. declaring UTF-8 but using an authoring tool that does no actually produce UTF-8 encoded data. not my experience. I agree with Asmus that overall, things are getting better. Marc. Yucca
Re: Supporting this is going to be loads of fun...
At/À 12:17 2000-11-09 -0800, Paul Deuter you wrote/vous écriviez: http://www.infoworld.com/articles/hn/xml/00/11/08/001108hnmultilingual.xmlhttp://www.infoworld.com/articles/hn/xml/00/11/08/001108hnmultilingual.xml Can someone tell me how domain names with international characters will be encoded? Is this well understood? Or is it that everyone will choose their own encoding and software developers will be left to support a hodgepodge of encodings? the ietf idn wg is responsible to come up with a solution. many proposals are on the table, some come from unicode people. see http://www.i-d-n.net Marc. I wouldn't mind hearing what the Unicode folks think about multi-lingual domain names. -Paul mailto:[EMAIL PROTECTED][EMAIL PROTECTED] http://www.infoworld.com/articles/hn/xml/00/11/08/001108hnmultilingual.xml Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca -- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.
