A problem while Chinese inputing

[THZrry]

Hello.
I don't know how to describe this. I think I may tell how could Chinese input, and then I may describe this more clearly.

We use pinyin to tell Chinese characters' pronuncations, and pinyin is formed like English.
When Chinese typing by pinyin, there will be a bar with matching words. Some input methods like Sogou will display typed pinyin too, while some like Windows pinyin not.

I just use Windows pinyin, and when I try to input chinese, I can see the bar with matching words, but my typed pinyin disappears. It is still available but not viewable. I don't know if japanese input will behave like that, but i think it's not convinent.

I can't see the romanji characters, and other case:

These are two cases of typing Chinese. I have read an Chinese article about this, maybe it will help. Moreover, here're some Chinese words to test:
你好：n(i)h(ao)，Hello
再见：z(ai)j(ian)，Goodbye
中文：zh(ong)w(en)，Chinese(language)
编辑器：b(ian)j(i)q(i)，Editor
手机：sh(ou)j(i)，mobile phones
电脑：d(ian)n(ao)，computers
Letters in parentheses are skipable.

[SpartanJ]

I think I must have broken IME support in 0.5.1, because this was explicitly developed in 0.5.0 and it was working. Here's the screenshot I posted for the release.

[SpartanJ]

Yes, I broke it while fixing another issue.

[THZrry]

I have tried the old version, it's right...
Maybe this issue can be closed.

[SpartanJ]

Nono, I need to fix it for the next version haha. The fix is trivial on macOS and Linux but Windows SDL2 implementation of IME has some bug that is problematic. I'll have to make some tests on Windows.

[SpartanJ]

Regression fixed, it will be part of the next minor release.

[ghost]

Maybe related: #163

[SpartanJ]

Maybe related: #163

You mean you were referring to the same thing o that they are similar? If they are not the same thing can you please show me what is the expected result and what you get? Maybe a video or a couple of screenshots of ecode vs any other editor working properly.

Thanks

[ghost]

Regression fixed, it will be part of the next minor release.

I build from source using the latest code. It doesn't fix my problem.

@THZrry Does it work for you?

[SpartanJ]

Please clarify your problem. Based on what you said you're talking about a different problem.

[ghost]

Please clarify your problem. Based on what you said you're talking about a different problem.

I don't know. My language is not Chinese. It's based on Latin script with a ton of tone marks.

Update: Tested on Pragtical. Same problem. I should test on Pragtical and Lite XL before reporting a problem. This is my fault. It seems Lite based editors can't handle languages with many tone marks like my language. I'm fine with that.

[SpartanJ]

Oh, then it's just a font problem. The thing is that ecode provides fonts for all major latin languages and chinese, korean and japanese, for other languages you'll probably need a new fallback font, if you tell me the language I can help you finding a font. I don't provide all the fonts because the package would need to be huge, usually editors don't provide the fonts, but they'll try to locate the font locally and use it, that's what is pending in ecode (and eepp GUI), I need to check how major GUIs solve it (my guess this is a hardcoded list).

[ghost]

Oh, then it's just a font problem. The thing is that ecode provides fonts for all major latin languages and chinese, korean and japanese, for other languages you'll probably need a new fallback font, if you tell me the language I can help you finding a font. I don't provide all the fonts because the package would need to be huge, usually editors don't provide the fonts, but they'll try to locate the font locally and use it, that's what is pending in ecode (and eepp GUI), I need to check how major GUIs solve it (my guess this is a hardcoded list).

Why don't you think a bit differently? Both ecode, Pragtical, and Lite XL are using SDL2. It could be a problem with SDL2 itself. BTW, I'm sure it's not just a font problem. The very same font worked fine in applications using other GUI frameworks (Win32 API, Java Swing, GTK+, etc.). It's only problematic with applications using SDL2.

p/s: I have tried to do everything I can with the fonts. It doesn't help.

[SpartanJ]

Why don't you think a bit differently?

Mmh maybe because you're not giving me enough information. I still don't even know what's the language you're trying to input and how you're trying to input it, you use IME to insert the characters? Does sometimes render a glyph (even if it's wrong) or you never can insert it? Which OS you're trying to use? Can you send me a video or some screenshots?

[THZrry]

I have checked the font files.

Ecode shows Chinese ( and other non-ASCII chars? ) by fallback font. LiteXL also supports Chinese but not offical. See this lite-xl/lite-xl#944 You can make lite-xl show Chinese by specificing fallback font or changing default font instead.

So if the fallback font is even helpless for some characters, will Ecode use system fonts?

[SpartanJ]

So if the fallback font is even helpless for some characters, will Ecode use system fonts?

Not for the moment, I need to investigate how to locate them on each OS. That's pending.

[THZrry]

That's definitely a hard work. Maybe this can be left for now, because there's one existing way to change a font file.

[ghost]

So if the fallback font is even helpless for some characters, will Ecode use system fonts?

Not for the moment, I need to investigate how to locate them on each OS. That's pending.

What do you think about using fontconfig and freetype2? This will also solve the problem with sub-pixel hinting.

[SpartanJ]

What do you think about using fontconfig and freetype2? This will also solve the problem with sub-pixel hinting.

Regarding fontconfig, it's a possible alternative. I always first try to solve it internally, otherwise I'll try to use an easy to build and small open-source library. So I need to analyze if fits our needs.

Regarding freetype2. ecode does use freetype2 for all its font rendering. sub-pixel hinting is not solved by freetype2. freetype2 will provide you the glyphs but the hinting must be done by the software, since sub-pixel hinting depends on the background color, that's the main complexity. On the ecode case sub-pixel hinting would require to render everything into a frame-buffer and implement the hinting with a pixel-shader, the required changes are not trivial and it's also computationally expensive.

BTW I still have very little information about your issue. If you can provide more information that would be really helpful. Thanks

[ghost]

sub-pixel hinting is not solved by freetype2.

Can you elaborate more? Because as I know, freetype2 does sub-pixel hinting. Do you know about a software named MacType? It's using freetype2 to replace Windows' native renderer. I still think freetype2 offers all of the features you need.

[SpartanJ]

With freetype you'll basically hint the glyph renderer to render with LCD filters into a pixel-buffer, but all the real logic and rendering goes after that, if you're really interested read this article which goes very much in depth about the whole process.