On 2012.05.23 11:25, Xiaofan Chen wrote: >> I think the problem is the © '(c)' sign in the headers, I see >> 2 possible solutions: >> 1) Stick to ASCII only, so replace '©' with '(c)' >> 2) Convert the files to UTF-8 in our git repo and tarbals >> >> So what do you think is the best solution? > > I vote for (1). > > We had similar issues in libusbk and (1) is what we choose. > http://code.google.com/p/usb-travis/source/browse/trunk/libusbK/license/AUTHORS-libusbK.txt
I strongly vote for 2, and, at the risk of displeasing some people, I'll go further than that by saying that anybody who sticks to lower ASCII or obsolete codepages, in 2012, instead of using UTF-8/Unicode is not seeing the big picture. OS and tools support for Unicode/UTF-8 _is_ mature and has been for quite some time. By limiting yourself to lower ASCII or a specific codepage you're shooting yourself in the foot. Be it to mention authors of a specific section of code by name or a reference, we _need_ internationalized characters, which can intervene at any location in our source, so lower ASCII is not an option. And since we want to be able to point to a Korean reference in the same breath as an Arabic one if needed, limiting ourselves to a single codepage will not do either. Therefore UTF-8 is the best option. But more importantly, this one is really a no brainer: 1. A look at the source quickly shows that while the core files use UTF-8 for the copyright sign whereas the samples don't (and surprise-surprise, the issue is with the files that aren't UTF-8...) 2. From the conversion options, it's fairly clear that what Fedora really wants is UTF-8 3. Git blame shows that the samples not being UTF-8 is a mistake from the conversion from '(c)' to '©' that occurred with [1]. During this conversion, all the (c) were supposed to have been changed to UTF-8 ©, but it looks like I screwed up the examples conversion and used ISO-8859-1 instead. To be in line with the intent of the original patch as well as the other source files, this clearly needs to be fixed to UTF-8. Unless someone can produce a convincing argument as to why we would really want to limit ourselves to lower ASCII (NB: supporting obsolete tools is not a convincing argument), I'll make sure to commit a patch that fixes the samples to UTF-8. Regards, /Pete [1] http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commitdiff;h=791b7473ec38155ee3d1d9889f3d0f1b4c8f33f0 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
