Displaying kanji (unicode chars) in HTML5

[info@softlynx.com]

I have a stack showing many kanji characters. All appear fine in standalone file but when tested with Firefox some kanji are not properly recognized. How can this be corrected for and will future releases of HTML5 fix this?

[richmond62]

A possible solution is to generate a WOFF font with the unicode Kanji set.

[richmond62]

My knowledge of Japanese writing systems outwith the 2 abugidas: Katakana and Hiragana extends only so far
as to understand that Kanji are basically Han Chinese ideographs (although Japanese has some ideographs
that are homegrown).

Now, looking at the Unicode code charts:

https://unicode.org/charts/

makes me realise that it is almost completely impractical to trail all the way through the Han ideograph set to check whether LiveCode
can render them properly in HTML5.

I would, however, like to offer a way of testing things that is comparatively straightforward . . .
-

-

[jacque]

There are a limited number of fonts available on the web, and if you don't specify a compatible one you'll get the browser default which may not include a complete character set. Do a search for compatible web fonts to see if any support all the characters you need, and if you find one, assign it to the stack or to the fields that require it.

@Richmond: custom fonts aren't supported on web (yet?)

Edit: I think the easiest way to test would be to assign a potential font candidate to the stack and see if the text renders for the existing fields.

[richmond62]

@Richmond: custom fonts aren't supported on web (yet?)

Indeed.

But the web does support the whole Unicode Chinese ideograph set, so, unless the OP is using characters in a home-grown
font that are stored in one of the 3 Unicode Private use areas, or, is using a non-Unicode compliant font, they really should not
have any problems.

A way round the Private use areas 'problem' is to wrap a WOFF version of
one's home-grown font into one's HTML code

Fontforge can convert fonts into WOFFs:

https://fontforge.org/en-US/

[richmond62]

https://www.softlynx.com/
-

Standalone.jpg (12.08 KiB) Viewed 3929 times

-

-
To be honest, these 5-digit numbers also look problematic.

[MacOS 13 beta 9]

I am not entirely sure what the point of listing those 80 kanji is (even if they are rendered as glyphs)
if they are NOT taught in KanjiLynx:
-

-
That reference to 'kanji 3' is also meaningless.

[richmond62]

The connexion between the numbers in the "not included" messages and
the unicode glyphs has no rhyme or reason:
-

-
I feel that this software should NOT have been released until a lot more work was done to get
things right.

As far as I can ascertain, NOT a single one of the 80 Kanji which are 'taught in Grade 1' are available
in KanjiLynx: so why are they listed at all?

My conclusions are supported by trying to view the English version of Momotarou:
-

-
The English text is 90% covered by the 'What is Momotarou' text, and the English
text runs out through the bottom of the KanjiLynx window.

Oer:
-

[richmond62]

I do hope you take my criticisms in the way I mean them: NOT as a way to be nasty.

It is obvious that you have already put a lot of work into your program, and I do hope
you are able to bring it up to a high standard.

I have quite some considerable experience working with Unicode and LiveCode,
so I am very happy to help you in any way I can.

[jacque]

Since LC HTML doesn't support custom fonts yet, how would a web app display it? Would this be a server side thing? From what I've read, WOFF is just a repackaged font file. I confess I know little about web font handling.

[richmond62]

'Custom fonts' is slightly OT.

As I have pointed out, the internet (and all current browsers) are Unicode compliant . . . so are perfectly capable of
rendering standard Unicode text, and the Unicode standard contains just about every Han ideograph known.

This is one of my 'go-to' websites when I get stuck with writing systems: https://www.omniglot.com/writing/japanese_kanji.htm

This makes some remarks about Japanese, Unicode and a possible problem with some special Kanji calle gaiji.

Where the OP may be experiencing difficulties is if they are confusing the unicode standard with the JIS X 0213
Japanese Industrial Standard.

---------

However, even before these considerations come into play, as I have previously pointed out:
the OP has to sort out how Kanji are rendered in the desktop version

[see my screenshots above]

If the OP is unable to present Kanji from a font properly cross-platform I, personally, would prepare
images of those Kanji so that they can be used as virtual tiles in standalones.
-

-

[jacque]

'Custom fonts' is slightly OT.

I think you misunderstood my comment. I meant that user-specified fonts are not yet supported on web apps. The OP needs to set the font in the stack to one that all browsers support by default.

If a stack or field is set to use a font that isn't native to the browser, the default font will be used instead, which may not be one that supports the entire desired character set. I saw this in one of my early experiments.

Using an altered WOFF font would qualify as a "custom font" in this case, since it would be part of the compiled app.

[richmond62]

I think you misunderstood my comment.

I did. Sorry. Thank you for the clarification.

HOWEVER, as browsers ALL have access to fonts that cover the whole Unicode 14.0 [not caught up with 15,0 yet]
specs, LC-HTML5 should be able to leverage those.

BUT, as I have already discovered, the OP has not sorted out their renderings (and quite a few other things) in their
desktop standalone (for MacOS at least).

So, just at the moment, it is difficult to determine where the fault lies: with the OP or LC.

[richmond62]

I would assume that this:
-

-
SHOULD look a bit like this:
-

[richmond62]

Mac standalone:
-

-
HTML5 here:

https://www.dropbox.com/s/vkrqbfczhar7u ... a.zip?dl=0

And, re fonts, I set no font for the field: that was Text, whatever that is supposed to mean.
-

-
Cripes . . .

[jacque]

And, re fonts, I set no font for the field: that was Text, whatever that is

The italicized items in the LC font list are a way to select the generic equivalent on the currently running OS. The text font would be the font used by default by the browser in this case. Users will see the same thing as having no specified font selected. If you don't select a font specifically, LC tries to fill in the most accurate generic.

In the past we had no way to specify a default system font. The workaround was to specify a nonsense string so the engine would fall back to the default font. These newer additions allow us to specify we want the OS fonts directly.

If the OP hasn't specified a browser-compatible font, LC will likely use a generic text font which may not contain all the required glyphs.