Arabic Installer
Xena Donovan
The question is whether MP3tag still supports Windows XP ...
I remember that when I used MP3tag and XP that some system generated text boxes could not cope with special characters and showed squares instead.
In my case, however, the installer fails to detect Estonian, and proceeds with some arbitrary language. I assume that Estonian is not included in the list of supported languages of this installer. But then it should either use English as the default (or German, it's up to the author) or offer the user to choose the preferred language.
This is not the question of this topic. According to the download page Windows XP SP3 is officially supported. If you notice any bugs on such a system which does not appear elsewhere, please report it in a separate topic.
I've noticed that the text itself appears exactly the same in both cases (judging by the number of letters, repetitions and double-letters in the same locations), only character sets are different. After some experimenting with Google Translate and character encodings, I think the original text is in Arabic. (Because the last sentence should read "Click Next to continue.")
This means that Thai language was also not detected/supported by the installer. As the result in both cases, installer chose Arabic (perhaps because it is the first language in the list where language names are sorted alphabetically).
It seems like the original Arabic text the installer is trying to display is written in the Windows-1256 (Arabic) code page. Perhaps this would be the default code page on Arabic Windows PCs. However, because in my PC the default is the Windows-1257 (Baltic) code page, I see the gibberish pictured above. And the other customer (Illuminator, in the referred post) has the TIS-620 (Thai) character encoding set as default on their PC. So the characters appear different (Thai script), but in fact the text is completely unreadable because it is originally in Arabic.
It will be easier to talk about this when I have uploaded the related changes to the language-selector package. Then people will be able to simply update and test for themselves, and possible modifications can be made. But before I do that, there is a pending item which @xlmnxp is investigating: Should we use the basic Noto Sans Arabic font or the Noto Sans Arabic UI variant.
What about when I am using a German locale and want to have a better Arabic font overall without installing another language? For example, in Kubuntu 20.04 I was using a German local and did not install any other language, and the Arabic font in Facebook in Firefox was much better by default than in Ubuntu.
The project with improving Arabic rendering is not completed yet. We should fix it so an Arabic install of Ubuntu comes with the better fonts rendering by default, and the changes should also be backported to Ubuntu 20.04.
Can we apply that on installer?
I mean when use choose Arabic as Installation language
Ubuntu should use the better Arabic rendered
لقطة شاشة من 2020-08-18 00-45-37.png793594 286 KB
I am on 20.04 Pop_OS! all seems to be working as expected, perhaps a small note would be that arrows still point left to right instead of right to left when switching the language, but I guess that is not font relevant in any way.
I've install arch linux on vm and it seems to work fine so i ve instal dwm and a browse (firefox) .the problem is when i go to a web site the contine arabic characters it show up like in the photo
the image
Any suggestion on how i can solve it .
You may want one of these, though glyphs on www.aljazeera.net show up just fine for me and I don't have a specifically arabic font installed, but I do have ttf-dejavu which provides pretty wide unicode glyph coverage.
Switch the font. If you use Inter or any other similar font which doesn't provide characters for Arabic and Chinese you will have to ditch it. I recommend the Noto fonts as they support almost all the characters available.
The JRE and JDK Installers are localized to the languages specified in the User Interface Translation table. The installers will use the use the system's default locale setting to determine which of the supported languages to use at the time of installation. If the system's default locale is not supported by the installer, the installer will be displayed in English.
The support for locale-sensitive behavior in the java.util and java.text packages is almost entirely platform independent, so all locales are supported in the same way and simultaneously, independent of the host operating system and its localization. The only platform dependent functionality is the setting of the initial default locale and the initial default time zone based on the host operating system's locale and time zone.
Numbering systems can be specified by a language tag with a numbering system ID, such as th-TH-u-nu-thai. The following are the available numbering system IDs for specifying a numbering system. No algorithmic numbering systems defined in Unicode Locale Data Markup Language (LDML) are supported.
HOST: This provider enables the default locale(s) (Locale.Category.FORMAT and/or Locale.Category.DISPLAY) utilizing the underlying operating system. This provider is available on Windows platform and Mac OS X platform.
For the Java Foundation Classes (AWT, Swing, 2D, input method framework, drag and drop) and JavaFX, locales can generally be characterized by just the writing system; there are no country or language specific distinctions. Writing system support in the JFC/JavaFX depends to some extent on the host operating system, and full support for simultaneous use of multiple languages is not always possible.
Support for text input consists of two parts: interpretation of keyboard layouts, and text composition using input methods. For interpretation of keyboard layouts, the JDK relies entirely on the host operating system. For text composition using input methods, JDK supports native input methods using the host operating system's input method manager as well as input methods developed in the Java programming language (excluding JavaFX environment).
Locale support in input methods implemented in the Java programming language depends solely on the set of installed input methods, not on the host operating system and its localization. However, support for the use of input methods implemented in the Java programming language with peered components is implementation dependent - see below.
Input methods implemented in the Java programming language are supported in lightweight components (such as Swing text components), but not in peered components (such as AWT text components) or JavaFX nodes.
When using physical fonts, we need to distinguish between simple and complex writing systems. Simple writing systems have a one-to-one mapping from characters to glyphs, and glyphs are placed on the baseline continuously from left to right. Complex writing systems may use different glyphs for the same character based on context, may form ligatures, may be written from right to left, and may reorder glyphs during line layout, or may have other rules for placing glyphs (in particular for combining marks).
The 2D text rendering system supports any combination of simple writing systems and the complex writing systems listed in the table above. Within these limitations, the range of supported writing systems is determined by the font. A single TrueType font might provide glyphs covering the entire Unicode character set and a Unicode based character-to-glyph mapping. Given such a font, 2D can support all simple writing systems as well as the complex writing systems shown in the table above. Other complex writing systems are not supported.
No precise list of supported font rendering locales can be provided since support is largely dependent on the installed platform fonts, and the complex text rendering capabilities of the native platform. However in general this means the capabilities of JavaFX should be similar to those of the platform itself, and for the supported modern desktop platforms this should match or exceed those of the equivalent JFC/Swing text rendering.
The automatic implicit addition of fallback fonts to all FX fonts other than application embedded fonts means that the application should benefit from the broadest locale support no matter which FX font is in use.
Text rendering using the AWT and 2D printing API works to the same extent as text rendering on the screen. Text rendering using the pluggable services printing API depends on the printing service used; the services provided by the JRE work to the same extent as text rendering on the screen.
Applications that need to transfer arbitrary text independent of the host operating system, can do so using serialization: Create a Transferable which supports only one flavor: DataFlavor.stringFlavor. This flavor represents the serialized representation of a String. Make sure that the target supports stringFlavor as well. When the transfer occurs, the AWT will serialize out the String on one end and deserialize on the other. This is much slower than a native platform text transfer, but it will succeed where native transfers may not.
The user interface elements provided by the JRE 8, include Swing dialogs, messages written by the runtime environment to the standard output and standard error streams, as well as messages produced by the tools provided with the JRE. These languages are also supported in JavaFX. These user interface elements are localized into the following languages:
64591212e2