Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't input none-english characters using VisText #277

Open
dotw opened this issue Nov 20, 2017 · 6 comments
Open

can't input none-english characters using VisText #277

dotw opened this issue Nov 20, 2017 · 6 comments
Labels

Comments

@dotw
Copy link

dotw commented Nov 20, 2017

I can't change the text from English character to none-English characters when drag a VisText component from ttf font. Can you guide me which class is controlling this? I want to enhance this to support Chinese characters. Thanks.

@dotw
Copy link
Author

dotw commented Nov 24, 2017

I have figured it out. See this pull request. #278

@metaphore
Copy link
Contributor

metaphore commented Nov 28, 2017

Although this is a real problem, because VisUI uses prerendered bitmap font and cannot display glyphs like Chinese, I think this solution should be kept outside of the library.
My first point is FreeTypeFont dependency itself. VisUI won't be able to work under "limited" backends like GWT anymore which I find very important.
The second one is there is nothing wrong with VisUI widgets in a first place, they are fully capable of rendering anything what is supported by underlying font. And the limitation practically comes only from VisUI default skin, which can be easily replaced/customized by a user.

But I see your issue mostly addressed the VisEditor (which I personally don't use), rather then VisUI library, so this could be a really important topic you raised. But since it breaks underlying independent widget library, unfortunately, I can't agree with the solution. @dotw probably you can go with another approach that is just localized inside VisEditor and does not add FreeTypeFont dependency to the VisUI?

I've actually came across the same problem with VisUI some time ago and solved it by injecting lazy generating FreeTypeFont into the skin, check this out:
image

@kotcrab
Copy link
Owner

kotcrab commented Nov 28, 2017

Great response from @metaphore. FreeType dependency can't be added to VisUI because we need to support GWT.

VisEditor was deprecated, I'm not accepting any PRs for it. That's why it's disabled in settings.gradle.
You can continue working on it in your fork if you want.

I like the solution of injecting FreeTypeFont into the skin most. It's not really hard to do from library user code but it might be a good candidate for vis-ui-contrib as a helper method of some kind.

@dotw
Copy link
Author

dotw commented Dec 7, 2017

@metaphore Use image to replace the font is not acceptable. Not like english characters. English has only 26 characters, but Chinese are thousands. It's not acceptable to combine these characters in png files. Think about how large the png file will be.
I can understand the editor wants to support GWT without the dependency of FreeType, but please thinking the question using the user perspective, we have users, like me, don't care about GWT. I only care about android & iOS using libgdx, and furthermore, my app already has dependencies with freetype. Do we ignore these requirements or provide options to them?
@kotcrab thanks for the great codes. I'll go with my fork.

@metaphore
Copy link
Contributor

@dotw looks like you get me completely wrong, please reread my message.
The point was to leave your changes outside of VisUI widget library and use different approach to bring FreeTypeFont only into the editor. I also described the way it could be done.

@dotw
Copy link
Author

dotw commented Dec 8, 2017

@metaphore, i'm so sorry. i didn't realize bring free type into VisUI. thanks for your reminder again.

@kotcrab kotcrab added the ui label Dec 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants