In SQL Developer's (version 21.2.1.204 under Windows 10) Preferences, under Code Editor \ Fonts, several expected entries do not show up in the list of available fonts even though the limitation to monospaced fonts is lifted, and Environment \ Encoding is set to 'UTF-8'. Among these are "Arial Unicode MS" and Google's Noto fonts.
According to this post...
how to make sql developer display non-English character correctly instread of displaying squares?
... and others, at least "Arial Unicode MS" should be available.
And yes, these fonts are installed and work fine in all other applications that allow font selection.
What's going on?
I have been able to verify on another workstation that fonts installed with local admin privileges ("for all users") DO show up in SQL Developer. I guess this means the original question can be considered as "answered", though a real solution is pending.
Related
I have an app that is trying to display U+23CE (⏎). This is a terminal app, so we are using "Consolas"/"Cascadia"/"Courier". As far as I can see, none of these fonts have this character. And yet, in Visual Studio, when I am debugging this app, it actually displays it correctly in the debugger. Also, when displayed by the new Windows Terminal, it displays correctly. But when I use the app I am working with (actually Putty), it displays the "I don't know this character" glyph.
Putty is a classic Win32 app using ExtTextOutW() to draw that text. I have checked that the correct font is bound to the HDC.
I am assuming that Visual Studio and Windows Terminal are using DirectWrite or other more modern text output logic, but ultimately they have to be getting these unknown glyphs from somewhere.
UPDATE:
I found a font with that character ("Segue UI Symbol"), and if I set Putty to use that font, it displays the missing character (woohoo). Sadly, this is a proportional font, so it looks terrible, and this is not the solution.
#dvix pointed me at a Microsoft page discussing this exact topic, but its not clear which things are done by Windows and which by an app developer. I tried linking "Courier New" (Putty's default) to "Segoe Symbol"", but it made no difference. Does the Putty code need to do all the work itself? Detect an unknown character, read the Registry, and substitute the font for that one char? That is certainly doable, but a pain.
Windows can be directed to "borrow" missing glyphs in a font from another font that carries them using font linking. This applies to both consoles and GUI apps that use GDI (DrawText, ExtTextOut) to render text in Windows 2000 and later.
For example, the following registry entry will link the Consolas font to Segoe UI Symbol (the following can be saved as a .reg file and merged into the registry, will take effect at the next logon).
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
"Consolas"=hex(7):53,45,47,55,49,53,59,4d,2e,54,54,46,2c,53,65,\
67,6f,65,20,55,49,20,53,79,6d,62,6f,6c,00,00
; "Consolas"=REG_MULTI_SZ:"SEGUISYM.TTF,Segoe UI Symbol"
One handy tool to explore coverage of the different fonts is BabelMap. For example this is the list of fonts that carry U+23CE (⏎) on a fairly clean Win10 system.
Another feature of BabelMap is the option to create temporary user-defined composite fonts on the fly, as opposed to the ones "statically" defined in the registry. This is presumably done using the MLang
IMLangFontLink interface, more about that in Raymond Chen's How to display a string without those ugly boxes and Michael Kaplan's Font substitution and linking #2.
I want to type and print in windows 10 CMD sinhala unicode characters. but it just display question mark surrounded by a square for each sinhala character i type.
Is there any mechanism to display exact unicode characters in windows console?
Try modifying the registry settings for the cmd console (run regedit). Unfortunately, I am uncertain exactly which value you should enter for the font family, since it is a number.
The screen shot below shows my registry settings for a font of 'Courier New', which somehow translates to 30 (hexidecimal, 48 in base 10) in the registry. Hopefully you can experiment some and determine what number corresponds to a Sinhala font you have installed on your machine.
Additionally, you can select fonts using the cmd window's property dialog, illustrated in the screen shot below. Possibly you already have a font installed that you can use:
You've probably already done 1-3 since you can already type Sinhala, but you need a supporting font. Try the following:
Go to Region & language settings.
Add a language and select, Sinhala.
Click the language, Select Options, and you can select a keyboard type.
For Chinese, I was able to add a language pack, which gave me console fonts that support Chinese. I don't see that option for Sinhala. You may have to manually install a monospace font that support Sinhala. I couldn't find one, but if you do, this answer explains how to install it.
Reference text: どうもありがとうございました
Copied to:
Notepad/Notepad++: displays it with no problems
LibreOffice Writer: it changes the font family to work, if you convert to Lucida Console, square boxes appear
Windows: displays it with no problems
Console: it needs the correct chcp and a font family (Lucida Console displays square boxes here too) which can display them if I am right
Is it possible to explain why Notepad can display any text in any font family and LibreOffice + Console cannot? Where is(are) the difference(s)? Is it possible to have the same behaviour on the console as the Notepad does for example?
Some Windows fonts have glyphs for many different scripts, some cover a few scripts, and many cover just one. (Fonts which support many scripts are sometimes called "Unicode fonts," which can be a misleading term. In other OSes, these kinds of fonts are more prevalent. Windows itself doesn't ship with any, though I think you get one or two with the Office suite.)
When you try to output text in multiple scripts using standard Windows functions using one of the well-known fonts, then Windows uses font fallback and/or font linking, which automatically switches between fonts as needed to output the whole string. Most programs, like Notepad and Notepad++, thus get coverage automatically.
I haven't read the LibreOffice code, but I suspect that when you select a font for a span of text, it sticks with that font, effectively preventing Windows's font fallback and font linking mechanisms from helping. This isn't surprising, since a WYSIWYG editor is likely to use lower-level APIs for outputting text in order to have more typographic control. But using the lower-level APIs means you don't get fallback and linking for free, so you'd have to implement it yourself, and that's a lot of extra work that may not be important to very many users.
The Windows console has a lot of legacy and limitations that persist for backward compatibility with older programs. The console mostly emulates DOS systems, which didn't have any sort of Unicode support and instead relied on "Code Pages," which are, roughly speaking, alternate mappings between character values and glyphs. Code Pages are geared at just one (or maybe two) scripts, so if you need characters from another script, you were basically out of luck. I think modern versions of Windows have hacked in some support for a pseudo code page that supports UTF-8, but I've never gotten it to work well and it, too, has limitations.
I am working on a data set that contains Chinese characters. Stata displays these as gibberish and I need to be able to read these. I could not find a Chinese language pack for Stata. Does something like this exist?
I am using Windows 7 Professional and StataSE 13 (64 bit).
Go to Control Panel->Language->Advanced Settings.
Click into Apply language settings to the welcome screen, system accounts, and new user accounts.
In Administrative tab, under language for non-Unicode programs, change it to Chinese (Simplified). You might need to change system locale if your computer wasn’t initially set to be located in China.
For those who arrive here via Google. There have been substantial improvements since this question was answered:
See here for more information on setting locale in Stata 15 and later.
"If your computer language is set to Chinese (zh_CN) and its region is set to China, Stata will automatically default to its Simplified Chinese setting. To change languages manually using Windows or Unix, select Edit > Preferences > User-interface language... using Mac, select Stata 16 > Preferences > User-interface language... You can also change the language using the set locale_ui command."
Some of my Arabic users are reporting problems back to me with my application giving errors.
Common for them seem to be they are using Hijri calendar and TDateTimePicker control causing problems (but quite possibly it is the entire TDateTime and RTL that has problems, I am not sure)
The Hijri Calendar has a different year start/end which is not well suited for my application. (AFAIK, Hijri first became available in Windows7.)
I have problem reproducing the error because
1) I can't read Arabic making it much harder
2) I can only pick Hijri when Windows is set to Arabic (otherwise it is not a visible option)
Anyone here with the same problems? I Use Delphi 2010
Can I force my application into using standard calendar? (as solution) or can I force Windows to Hijri calendar on English Windows? (for testing)
In XP anyways, if you already have not done so, on Control Panel's Regional and Languages options dialog, go to the Languages page and first check the Supplemental Language Support checkboxes (Install files for complex script and right-to-left languages (including Thai)". For fun, check the East Asian languages one too, for later when you're going to want to check that chinese characters work properly.
Then, from the Control Panel, "Regional and Language Options" go to the "Advanced" tab and change the "Language for non Unicode programs" to an Arabic language.
Next you can go to date/calendar options and change to calendar type:
Hirji Calendar in arabic looks like this:
التقويم الهجري
Original source MSDN:
http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx
Additional pro tip: If you aren't already doing so, start using VMs for internationalization testing. Do you really want to do all this to your main workstation? Not me. I do this stuff in VMs.
You can use the Windows API function SetLocaleInfo, this would change the user's settings in the windows control panel which may be undesirable.