ProgressBarStyle.ASCII does not print only one line. about progressbar

[ctongfei]

It seems that D2Coding does not support the block drawing characters. You could use another font that does (and also has CJK support, e.g. https://github.com/be5invis/Sarasa-Gothic)

I think the way forward is to include a fix to correctly compute the space of width-2 characters (Hangul / Hiragana / Katakana / Chinese characters / etc.)
Thanks for raising this issue! I'll fix this in a later release, but probably not in the coming few weeks.

[ctongfei]

Released in version 0.9.1.

[ctongfei]

Thanks @ImSejin !
Two questions here:

• What font are you using? The block character problem may arise if your font does not support specific Unicode box drawing characters.
• Try removing the Hangul characters? I guess that since each Hangul takes the space of 2 Latin characters, the width of the progress bar may be wrongly computed. If removing Hangul characters work, then it shows that there should be a general fix towards CJK chars.

[ImSejin]

I use the font 'D2Coding' that monospace font for developers.
(font docs/download page: github.com/naver/d2codingfont)

As you said, I try removing Hangul characters, then it works! Thank you.
Do you have plan to support characters that takes the space of 2 Latin characters?

In the case of ProgressBarStyle.COLORFUL_UNICODE_BLOCK, character '?' is still showed as you expected.

In my case,

• ASCII: not support Hangul characters (I really want to use Hangul.)
• UNICODE_BLOCK: not support specific Unicode box drawing characters
• COLORFUL_UNICODE_BLOCK: not support specific Unicode box drawing characters

How should I do? 😢

[ImSejin]

Thanks a lot! Have a nice day.

[ctongfei]

The principled way to deal with this is to use the Unicode's EastAsianWidth property for each char.

The display width for a char is 1 if it belongs to one of the property N, Na, or H, and 2 if it belongs to W or F.
The display width for any char in class A (ambiguous) is 2 in an East Asian locale but 1 otherwise.

The proposed solution for this is to include a displayWidth(String s, Boolean inEastAsianContext) method that computes the string length instead of just using String::length, similar to C's wcswidth function.

[1] https://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
[2] http://www.unicode.org/reports/tr11/tr11-36.html

[ImSejin]

That's cool!
I will wait for the next update.

[fangyuzhong2016]

Hi，I also found this problem, but it is not Korean, but Chinese characters. If the printed information exceeds the maximum length of the console, it will wrap. The root cause is to recalculate the length of the string displayed on the console, instead of directly calling String.length to simply count the number of characters as the length.I checked some materials and used the ICU4J.jar library to calculate the string display length. You can refer to the following code:

<dependency>
           <groupId>com.ibm.icu</groupId>
           <artifactId>icu4j</artifactId>
           <version>68.1</version>
</dependency>

   public int getStringWidth(String showText){
       int width = 0;
      char[] showTextChars = showText.toCharArray();
       for (char showTextChar : showTextChars) {
           width += getCharWidth(showTextChar);
       }
      return width;
   }
  public int getCharWidth(char c){
       int width = 1;
       switch (UCharacter.getIntPropertyValue(c, UProperty.EAST_ASIAN_WIDTH)) {
           case UCharacter.EastAsianWidth.WIDE:
           case UCharacter.EastAsianWidth.FULLWIDTH:
               width = 2;
               break;
           default:
               break;
       }
       return width;
   }

[ctongfei]

@fangyuzhong2016 I'm aware of the problem of East Asian characters and this will be fixed in the next version. Thanks!

P.S. In your usage of progressbar, it seems that you have set the max to be 100, but you show the actual number in the extraMessage. You can actually set the actual size with maxHint and it'll behave like this:

正在导入图层 100% [==============================] 69096/69096 (0:00:07 / 0:00:00)

[ctongfei]

Fixed (did not pull in icu4j since I don't want to pull in such a large library).