Ja-jp Font
Leoma Cianchetti
In my sitecore website there is some enhancement requested from client.They want me to update the standard font style for the /ja-jp/ website to Microsoft's Meiryo font. This includes updating all HTML-based stylesheets related to all templates and sublayouts.
Thank you for the detailed report. Certain webfonts are known to be incompatible with 10.4 and 10.5. Unfortunately, due to other limitations, it is not possible to detect them automatically. We maintain a blacklist of bad fonts, and the browser will select an alternative with the same character.
Using the steps in this earlier support ticket, are you able to find the font URL that causes the problem for you? I can make a guess from the Apple URL, but not the Adobe one. If you can provide both, I will add them to the internal blacklist for the next release of TenFourFox.
The Adobe one is a weird case. It's actually being loaded over JavaScript. I suspect the URLs are coming from Typekit, but I'll need to do some additional investigation. This problem is now being tracked as issue 513:
I have found another bad fonts error on google calendar.
Same situation in previous case. Latin alphabets display correctly, only Japanese characters disappear.
Would you mind considering putting these fonts in blacklist?
The number of font URLs is large this time though, I write down below, just in case.
I'm using Fedora 38. And for editing Japanese texts, I use the Google Noto fonts. In LibreOffice, using those fonts gives no problems. However, in LuaTex-Ja, I cannot manage to use the Noto Sans Mono CJK font.
In response to previous questions (see How can I use Noto Sans mono CJK iN LuaTex-Ja? (NEWBIE)) cfr told me that the following command fc-match "Noto Serif CJK JP" should return NotoSerifCJK-Regular.ttc: "Noto Serif CJK JP" "Regular". However, on my PC the same command returns NotoSerifCJK-VF.ttc: "Noto Serif CJK JP" "Regular".
I uninstalled all google-noto-sans-mono-cjk-vf-fonts and google-noto-serif-mono-cjk-vf-fonts and then reinstalled google-noto-sans-cjk-jp-fonts google-noto-serif-cjk-jp-fonts. But fc-match still returns the same answer.
Since in Fedora 38 the use of the static Google-noto CJK fonts is no longer supported, I went looking for old rpm files for CJK. In doing so, I quickly found the following page that clarifies why only Variable Fonts are still installed. Changes/Noto CJK Variable Fonts
Then by successively searching at = for google-noto-cjk-fonts-common, google-noto-sans-cjk-jp-fonts, google-noto-sans-mono-cjk-jp-fonts and google-noto-serif-cjk-jp-fonts I found the sought RPM files.After removing the previously installed fonts (sudo dnf erase google-noto-sans-cjk-vf-fonts google-noto-serif-cjk-vf-fonts) and installing the RPM files I finally managed to successfully compile the MWE.
The command fc-match "Noto Serif CJK JP" now returns NotoSansCJKjp-Regular.otf: "Noto Sans CJK JP" "Regular". So my suspicion that the problem was related to the missing ttc or otf file turned out to be correct.
UPDATE
The command sudo dnf update tries to update the CJK-fonts to the newer cjk-vf fonts. This can be prevented by adding the following line to /etc/dnf/dnf.conf:
exclude=google-noto-cjk-fonts-common google-noto-sans-cjk-jp-fonts google-noto-serif-cjk-vf-fonts
Execution of the dnf command gives a warning but the font files are not updated
It seems that the problem I am facing now is probably not a problem with font settings.
I copied the text in the Window and pasted it into Notepad, but the character encoding itself was already wrong.
I have also experienced that the default character encoding on Windows for Japanese OS is S-JIS, not UTF-8, so if it is run as a console application, the resulting character encoding must be decoded as S-JIS or the character encoding will be destroyed.
The dotnet application now outputs messages in English, so the problem has been avoided for that time.
I think the problem is still there, so I would appreciate it if you could notify me if it is fixed.
had this same problem on Ubuntu until I installed some japanese-font packages, I think. You can try that. Have you checked in the web page inspector what fonts are being rendered, since the page can affect it?
Install something that you have no need for, but would replace your current default font.
I used the example that I found fonts-arphic-uming, it's a Chinese font but it overwrites your default Japanese font:
I highly recommend using something else other than UKai though, as it's a Chinese font and some kanji characters won't load, in which case it will switch to loading the next available Japanese font if available, or simply showing a box for said kanji.
Font Book automatically checks for duplicates when you install a font, and shows a message if the font is already installed. You can choose whether to keep both versions, skip font installation, or replace the existing font with the new font.
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.
c80f0f1006