Hi,
thanks for the reply Pabs.
On Mon, Sep 21, 2020 at 03:02:14AM +, 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
