Web lists-archives.com

Re: [Mingw-users] putwchar not working




It might also be worth mentioning that by changing the font of the cygwin terminal from the options item on the system menu to courier new the utf8 representation of my name in Arabic gets printed correctly [from right to left and right letter shapes]...
 
hisham...


On Sunday, September 11, 2016 8:31 AM, Hisham Sueyllam <sueyllam@xxxxxxxxx> wrote:


Just one correction mingw64 gives the same as mingw32, the correct display from right to left and correct letter shapes happened in msys2 terminal so I guess the same terminal with mingw32 would also work...
 
hisham...


On Sunday, September 11, 2016 7:44 AM, Hisham Sueyllam <sueyllam@xxxxxxxxx> wrote:


Well I hate to flood the mail but I thought you may find it interesting, since changing the font did the trick for mingw64, I thought do the same for the command prompt I use to run mingw32 programs. So from the system menu of the command prompt I also changed the font to courier new. Unfortunately, the program in the previous message still displayed garbage, but remembering that the code page is 720, I tried the following, with my arabic first name coded using code page 720 instead of utf8 as in the previous program:

//#include <windows.h>
#include <stdio.h>
//#include <wchar.h>
//#include <conio.h>
//#include <locale.h>

int main() {
  char s[] = "\xEC\xAC\x9F\xEA\n";
  printf("%s", s);
  return 0;
}

and it almost worked. I said almost because it printed the 4 letters which constitute my first name correctly but with 2 missing items:
1- They are from left to right (Arabic is written from right to left for those who do not know)
2- The letters have the wrong shape (Also for those unfamiliar with Arabic, the shape of the letter depends on its position in the word: beginning, end, or in the middle)
See the attached image and compare the outpout with the one in the previous message attachment...
Well, I am not boasting mingw64 but both those 2 buggy apperances were not present, my name was printed as it should from right to left...
 
hisham...


On Sunday, September 11, 2016 7:06 AM, Hisham Sueyllam <sueyllam@xxxxxxxxx> wrote:


Well, as an experiment I tried the mingw64, and it works fine and prints unicode both Arabic and English in the command window, as shown in the attached png image.
Here is the listing of the program that worked, it prints an 'a' next to my first name in Arabic, to show that it prints both latin and other non-latin (Actually my guess any valid utf8 character, or may be just the BMP).
Note however that from the options menu I changed the font from Lucida console (the default and which did not work) to courier new.

So I am not sure how they did it in the mingw64,project  but clearly this takes the blame off Microsoft...

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <wchar.h>
#include <locale.h>
int main(void)
{
    char s1[] = "a\uFEEB\uFEB8\uFE8E\uFEE1"; // or "a\u\U"
    char s2[] = u8"a\uFEEB\uFEB8\uFE8E\uFEE1";
    //setlocale(LC_ALL, "en_US.utf8");
    printf("%s\n", s1);
    printf("%s\n", s2);
return 0;
}

 
hisham...


On Friday, September 9, 2016 6:08 PM, Eli Zaretskii <eliz@xxxxxxx> wrote:


> From: Yongwei Wu <wuyongwei@xxxxxxxxx>
> Date: Fri, 9 Sep 2016 22:41:53 +0800
> Cc: "mingw-users@xxxxxxxxxxxxxxxxxxxxx" <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
>
> > Maybe for you personally it isn't.  But being able to support just the
> > BMP in the year 2016 is a huge disadvantage IME.  We have already a
> > lot of character sets entirely in Unicode blocks beyond the BMP, and
> > each new version of the Unicode standard adds more.  Moreover, Windows
> > itself adds fonts to support these new character sets with each new
> > Windows version.  Being unable to support that is far from a Good
> > Thing.
>
> It is a luxury to talk about this, when we have problems dealing with the BMP.

When using the wide APIs, there are no such problems.

> > The upshot of all this is that any program which needs to support
> > non-ASCII characters in a sound way has no choice but to avoid the CRT
> > functions entirely, and instead use the "wide" Win32 APIs (such as
> > WriteConsoleW) directly and convert characters from and to UTF-16 by
> > hand, using MultiByteToWideChar and WideCharToMultiByte.  Any program
> > that relies on CRT functions for that is fundamentally broken on
> > Windows, and the main reason is NOT the MinGW libraries.
>
> I see your point, but I need to point out that it means completely
> different porting efforts, if the original application uses putchar
> etc. Just take the example of GCC: Oh, it outputs garbage information
> if it detects the environment is Chinese! I have to force the language
> to English to make it work. (I am not sure whether the current version
> of MinGW GCC ships with Chinese localization, since I am mainly on Mac
> now. It used to be the case....)
>
> Do you want to tell the GCC guys that they need to replace all
> occurrences of putchar etc.? (Maybe the easier approach is rid MinGW
> of all localization.)

Localization the gettext way has a very limited utility on Windows
anyway, because most Posix programs nowadays assume UTF-8, which is
compatible with "char *" strings, something that on Windows is
possible only with single-byte codepages and a small number of
codepages that support DBCS.  If we want localization on Windows that
really works, the only practical way is to provide replacements for
setlocale and all the multibyte and wide-character functions in the
CRT to support UTF-8 and work with 32-bit wchar_t data type.  Anything
less than that is no more than an illusion of non-ASCII support, and
breaks as soon as you try it in a locale outside Western Europe.

So if we want to fix MSVCRT in this area, we need to come up with a
much larger library than just a replacement for putwchar.  If someone
volunteers to do that job, I think it would allow the MinGW project to
become a much better environment for porting Posix programs that deal
with non-ASCII than it is today, including localization in the likes

of GCC.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe








------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe