NetBeans 15 Hindi Character Display Issue - netbeans

I upgraded NetBeans from Version 11 to 15. Version 15 is not displaying Hindi characters.
But Version 15 displays other language characters:
Under options, I have the same Fonts & Colors settings defined as Version 11.
Does anyone know how to fix this problem?
Thanks,
Brandon

If you set the font for the NetBeans Edit window to Unifont using Tools > Options > Fonts & Colors > Font then it will render Latin, Japanese and Hindi characters. You don't specify the language(s) you are using, but here is a trivial sample application in Java:
package pkg;
public class HindiJapanese {
public static void main(String[] args) { // Edit window uses Unifont font.
System.out.println("Hello World!");
System.out.println("Hello world in Hindi: नमस्ते दुनिया");
System.out.println("Hello world in Japanese: こんにちは世界");
}
}
You will also need to set the font for the Output window to Unifont using Tools > Options > Miscellaneous > Output > Font before running that code:
Update: Everything still works when using JDK 19 and Arial Unicode MS font, although that font is not fixed width:
Notes:
My environment is a NetBeans 15 Java Ant project on Windows 10 using JDK 11.0.12, though the edit window font setting is language independent.
In Control Panel the checkbox for Beta: Use Unicode UTF-8 for worldwide language support (Region > Administrative > Change system locale....) was not checked.
Unifont is an impressive font. It is bundled with NetBeans, it can render all characters in the BMP, and was the only fixed width font I could find to render Latin, Japanese and Hindi text. Though not great visually, it seems acceptable for software development requiring different character sets from multiple languages.
I can't vouch for the quality of the rendering of the Japanese and Hindi glyphs. See the Status section of this article for more information on Unifont, and some cautions on its limitations.
While not directly related to your question, you might consider moving that language specific data out of your source code and into resource files if possible.

Related

jasperreport font extension PMingLiu show strange character

I have downloaded PMingLiu.ttf from
https://www.wfonts.com/font/pmingliu
and then install through Jaspersoft studio widnow > perference, then I set a textfield font to the new installed font (PMingLiu)
when preview, the characters changes to strange characters, why?
If choose PMingLiu beneath the dash (PMingLiu installed in my operating system), then the character can show properly, but cannot show in exported pdf, or I must use the PMingLiu in my Windows system and use that ttf as font extensions?

Inside Visual Studio Code (macOS), Cyrillic typefaces are shown with a different font, why?

When VSCode deals with two languages inside of the editor (the main font has the support of Cyrillic alphabet though), the Russian language shown with a different font, how to get the same font for Russian and English as well?
Example:
<title>"Писатели Якутии"</title>
Is it because your main font does not contain the required UTF subset, so a fall back font is used, or what? If it is true, how to add the required UTF subset to VSCode?
System: macOS Mojave, the latest version of Visual Studio Code.
The answer is, thanks to Reddit:
1) Just use a font with the Cyrillic alphabet as my main font;
2) Add preferred Cyrillic font second in the list of fonts in fontFamily, as in:
"editor.fontFamily": "fontOne, fontTwo",

The same Unicode character sometimes appears as solid black and sometimes a colored icon

I offer a team calendar via Google Calendar to our sports club. It contain all match appointments for several teams and sports (like soccer, tennis, dart...).
I put Unicode icons at the beginning of the subject like a dartboard and a house for a dart match at our home location and a car for outside.
Like this: 🎯🏠 DC Flight Control - Team Dart Donkies
On Smartphones the icons appears as a colored image.
In browsers on a Win7 system as a solid black icon.
On my Win10 system also as colored image.
Same Google-Account, same view, same Google-Settings...
Is this a windows depending thing? Anybody can explain?
It's a font-depending thing
Windows 7 was so old and existed long before emojis came into existence and became common, therefore it doesn't have the appropriate font to display the colored emojis. And even if you install some newer fonts then it still can't render the colored characters because its font renderer doesn't support such a new feature. Initial support for color fonts was added since Windows 8.1, but only fonts with COLR/CPAL tables. Other colored font formats were later supported in Windows 10
An update for the Segoe UI Symbol font in Windows 7 and in Windows Server 2008 R2 brought a subset of the monochrome Unicode set to those operating systems. […] Windows 8 and higher supports the full Unicode emoji characters through Microsoft's Segoe UI family of fonts. […] As of Windows 8.1 Preview, Segoe UI Emoji font supplies full-color pictographs
https://en.wikipedia.org/wiki/Emoji#Microsoft_Windows
The same thing occurs on Linux where only a few modern distros have emoji support by default. Ubuntu has only included colored fonts since version 18.04, which means if you use the young 2-year-old Ubuntu 17.10 you'll see the black characters
Some applications like Firefox use their own font renderer and therefore can show colored emojis even on non-supported OSes. For example Firefox can display those characters on Windows 7 and Linux but Chrome and IE can't (not sure if Chrome was updated to support that or not):
Added a built-in Emoji set for operating systems without native Emoji fonts (Windows 8.0 and lower and Linux)
Firefox 50.0 release notes
It's also possible that someone hates colored characters and disable it completely

Why does Firefox squeeze Windows' heart, but not Ubuntu's?

I'm trying to display the heart ♥ Unicode character (U+2665 BLACK HEART SUIT) in this jsfiddle.
Even though I've specified the Droid Sans font, the different browsers are displaying the same character differently. So, I'm assuming that the Droid Sans font doesn't include the ♥ character and the browser must fallback to some other font to display this character. But how does the browser determine which font to use for Unicode characters; as it turns out (from screenshots) that it's not operating system specific as Firefox and Chromium both on Ubuntu display it differently; and also it is not browser specific as Firefox displays it differently on Ubuntu and Windows 7.
So my questions are - How does a browser determine which font to use to display Unicode characters; how can I find out which font is being used by the browser to display Unicode characters; and how can I ensure a consistent look cross-browser?
PS: (Firefox specific) Even though Droid Sans doesn't include the ♥ character, Firefox displays it as in screenshot only when the selected font is Droid Sans. For any other font, Firefox picks up the DejaVu Sans font to display the ♥ character (on Ubuntu, confirmed by hit and trial).
The Droid Sans font does not contain U+2665 BLACK HEART SUIT, so declaring the font is rather irrelevant here. I cannot reproduce the observation in your “PS”, so I’m not trying to explain it.
(A quick way to check character coverage in a font is to download and install the LastResort font. It contains a generic, easily recognizable rendering for all characters, so by using font-family: foo, LastResort on your test text you will quickly find out whether a particular character exists in font “foo”.)
The use of fallback fonts is browser-dependent. Browsers may have settings for this. But the point is that you, as an author, cannot know what happens on other people’s browsers, when your characters cannot be found in the list of fonts you specify (as installed, if installed, in the user’s computer).

Why do Firefox and Chrome render "ಠ_ಠ" (U+0CA0) differently, even if I set both on UTF-8?

The character in question is ಠ (U+0CA0; ಠ). Here are three screenshots:
Chrome 17 for Mac
Firefox 7 for Mac
Firefox > 4 for Windows
All browsers I tried had UTF-8 as encoding. Here it is copy-pasted : ಠ_ಠ, but I have no idea how you are seeing it.
This is probably due to the different platforms and browsers having different default fonts and font implementations.
The font-family on SO is:
Arial,Liberation Sans,DejaVu Sans,sans-serif
So different fonts will apply on different platforms.
In your Mac examples, the different browsers display a "missing" glyph differently - Chrome with a simple square, FF with the hex Unicode of the missing glyph rendered within the box (in this case 0CA0).
The glyph is not covered by the font used by the webbrowser to display the page which is either the browser default font or the font specified by CSS on the page. You need to make sure that you specify a font by CSS which has most likely guaranteed this glyph in all environments. Arial, for example.
This problem is not related to the character encoding used. A problem in the character encoding used would rather have resulted in Mojibake, not in empty boxes or boxes with hexcode representing the Unicode codepoint which basically identify an unavailable glyph in the font used.
What you posted does not contain U+3232 PARENTHESIZED IDEOGRAPH HAVE “㈲” but a three-character sequence U+0CA0 U+005F U+0CA0, i.e. LOW LINE between two KANNADA LETTER TTHA characters. I don’t know what happened and where. Posting a URL might help.
There are differences in rendering across computers due to different font repertoires. The first two renderings in your screenshot indicate lack of glyphs, i.e. no font in the system contains the character U+0CA0.
Firefox and Chrome (unlike IE) tend to scan thru all available fonts to find the character. But rare special characters often have unsatisfactory implementations in fonts, so for best results, check out the list of fonts supporting the character and specify them in your font-family declaration in order of preference. This also helps poor IE to find a suitable font when available.
If the character you want is really U+3232, then check out
http://www.fileformat.info/info/unicode/char/3232/fontsupport.htm
It most probably does not cover all fonts, since new fonts emerge. But for this character, Arial Unicode MS is probably the font that will be used in the great majority of browsing situations – and if it is not available, an indicator of missing glyph is seen.