bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] patch: Improve the rolling file name length for downloadi


From: YX Hao
Subject: Re: [Bug-wget] patch: Improve the rolling file name length for downloading progress image when without NLS
Date: Fri, 17 Feb 2017 19:40:22 +0800

Hi,

>From:  Tim Ruehsen 
>Date:  Fri, 17 Feb 2017 10:14:03 +0100 
>  
>could you try the appended patch.
>
>If this doesn't work out for you, we have to base our fixes on this patch,
but
>let's see first.
Yes. I missed 1 line. Anyway, I am trying your new solution patch .

Features: -cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls
+ntlm +opie -psl +ssl/openssl
Still not work:
-8fa18e0-win64-static.zippppp   0%[
                    ^ '\0' in memory makes all following this won't be
updated

>From:  Tim Ruehsen 
>Date:  Fri, 17 Feb 2017 09:48:23 +0100 
>
>@Andries please read further down
>
>So we can completely get rid of USE_NLS_PROGRESS_BAR, since it is a bug
anyways.
>
>Calculating the number of displayed columns from the number of bytes of a 
>string is non-trivial. It is trivial only for charsets/locales where each
byte 
>(or codepoint) will take exactly one column on the display.
>
>With unicode you have to *at least* compose the string first (NFC I guess),
and 
>then count the codepoints. But I am not sure about exceptions.
>
Count the multi-bytes char exactly is difficult. That's why it tries NLS. :p
Without NLS, maybe we can find another way finally. It could cost extra
resource to calculate and judge ...
My rough way in the patch, is just return the bytes, just make sure it won't
over the string's tail. It only makes the string to be displayed not to be
separated. Cons is multi-byte char would be displayed as '?' when it is not
completely copied. Pros is patch is very short ;)
There are too many encodings, which worth a standalone library! I don't know
if there is a better way than NLS ...

>From:  Eli Zaretskii 
>Date:  Fri, 17 Feb 2017 12:05:21 +0200 
>
>I'm not Andries, but AFAIK there's a file in the Unicode Character
>Database (UCD) called EastAsianWidth.txt which provides the width
>information.
>
I think the original not patched code, that for no NLS, should always be too
simple to return the right length when left chars are less than the amount
can be displayed, no matter the chars are single byte or multi-byte. ;)
Complete support would be the best.
Seems a good starting. Let's learn more ...

At last, to explain why there are so many CJK characters, you may wonder. ;p
They are all influenced by Chinese. And one character that you see in
Chinese is a word indeed, has meanings.

Regards, YX Hao





reply via email to

[Prev in Thread] Current Thread [Next in Thread]