Hi, thanks for the reply Pabs.
On Mon, Sep 21, 2020 at 03:02:14AM +0000, Paul Wise wrote: > On Sun, Sep 20, 2020 at 10:50 PM Carlos Henrique Lima Melara wrote: > > > I've been working in a package (QA) that show diff between documents. And a > > selling point is working with different encodings (see the long description > > bellow). > > This feature is unfortunately quite hard to use, it seems like unless > you specify *both* line ending and encoding, docdiff uses Ruby > features that (now?) require UTF-8 encoding while automatically > determining the line ending and encoding, which sort of defeats the > point of the automatic line ending and encoding detection in the first > place. If the 2020 release of docdiff 0.6.0 (which fixed a bunch of > encoding issues) doesn't fix this then you might want to file an issue > about it on GitHub. I'm not an ruby programmer so I'll take a look and investigate this. > Also it looks like another maintainer is intending to upload the > Debian package too, you might want to coordinate with them if you > aren't already doing that. Yes, I've talked to Paulo, thanks for the reminder. > I also note the latest release adds support for one more encoding, so > it does seem like upstream thinks this is an important feature. > > https://github.com/hisashim/docdif/releases > https://github.com/hisashim/docdiff/issues/25 > https://github.com/hisashim/docdiff/issues/new > > > The upstream provides some examples which are pairs of files with small > > changes > > between them. This leads to my question. One of these pairs use local > > japanese > > encoding which makes the lintian scream: > > > 2. Installing the files in spite of lintian warning. > > Please note that when choosing item 2 you should also apply a lintian > override with a comment about why these files are present. > > > 3. Convert them to UTF-8 even with UTF-8 files already provided. > > I think this isn't useful so I would discard that option. > > > My question is what is the best course of action in this situation? > > For example files that can be used to demonstrate features of the > program, I see no reason to remove the files. OTOH I also see no > reason to include example files for a relatively obscure feature. OTOH > I see no reason to discriminate against users of obscure encodings. > Also, upstream probably has a reason for keeping those files. Probably > there isn't really a best course of action, so I'd lean towards the > status quo for now, with a lintian override. > > > Also I'd like to know what is the status of these local encodings in > > Debian, is there any place still using it? > > It sounds like as of 2017, non-UTF-8 Japanese encodings are still in a > small amount of use and kakaku.com still seems to use Shift-JIS. > > https://en.wikipedia.org/wiki/Japanese_character_encoding So, considering everthing, I think the better solution for now is to install the files and add a lintian-override. Again, thanks for the reply. Cheers, Charles
