Re: [HACKERS] shift_sjis_2004 related autority files are remaining

Hi, At Sun, 25 Jun 2017 09:20:10 +0900 (JST), Tatsuo Ishii wrote in <20170625.092010.542143642647288693.t-is...@sraoss.co.jp> > > I don't have a clear opinion on this particular issue, but I think we > > should have clarity on why particular files or code exist. So why do >

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> I don't have a clear opinion on this particular issue, but I think we > should have clarity on why particular files or code exist. So why do > these files exist and the others don't? Is it just the license? I think so. Many of those files are from http://ftp.unicode.org. There's no license

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On 6/23/17 11:15, Tatsuo Ishii wrote: >> For clarity, I personally perfer to keep all the source text file >> in the repository, especially so that we can detect changes of >> them. But since we decide that at least most of them not to be >> there (from a reason of license), I just don't see a

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> For clarity, I personally perfer to keep all the source text file > in the repository, especially so that we can detect changes of > them. But since we decide that at least most of them not to be > there (from a reason of license), I just don't see a reason to > keep only the rest even without

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

At Fri, 23 Jun 2017 10:04:26 +0900 (JST), Tatsuo Ishii wrote in <20170623.100426.157023025943107410.t-is...@sraoss.co.jp> > > Hm. I am wondering about licensing issues here to keep those files in > > the tree. I am no lawyer. > > Of course. Regarding euc-jis-2004-std.txt and

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> Hm. I am wondering about licensing issues here to keep those files in > the tree. I am no lawyer. Of course. Regarding euc-jis-2004-std.txt and sjis-0213-2004-std.txt, it seems safe to keep them. > ## Date: 13 May 2006 > ## License: > ##Copyright (C) 2001 earth...@tama.or.jp, All Rights

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Jun 23, 2017 at 9:39 AM, Tatsuo Ishii wrote: > I think we should keep the original .txt files because: Hm. I am wondering about licensing issues here to keep those files in the tree. I am no lawyer. > - It allows to track the changes in the original file if we decide

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

>> Why do you believe so? > > Unicode/Makefile includes that: > euc-jis-2004-std.txt sjis-0213-2004-std.txt: > $(DOWNLOAD) http://x0213.org/codetable/$(@F) > > So those files ought to be downloaded when rebuilding the maps, and > they should not be in the tree. In short, I think that

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Jun 23, 2017 at 8:12 AM, Tatsuo Ishii wrote: >> Hi, I happned to notice that backend/utils/mb/Unicode directory >> contains two encoding authority files, which I believe are not to >> be there. (Worked on that with Horiguchi-san a couple of weeks back.) >>

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> Hi, I happned to notice that backend/utils/mb/Unicode directory > contains two encoding authority files, which I believe are not to > be there. > > euc-jis-2004-std.txt > sjis-0213-2004-std.txt Why do you believe so? -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Apr 7, 2017 at 1:59 AM, Kyotaro HORIGUCHI wrote: > Hi, I happned to notice that backend/utils/mb/Unicode directory > contains two encoding authority files, which I believe are not to > be there. > > euc-jis-2004-std.txt > sjis-0213-2004-std.txt > > And

[HACKERS] shift_sjis_2004 related autority files are remaining

Hi, I happned to notice that backend/utils/mb/Unicode directory contains two encoding authority files, which I believe are not to be there. euc-jis-2004-std.txt sjis-0213-2004-std.txt And what is more astonishing, make distclean didn't its work. | $ make distclean | rm -f The Makefile there