1.) Yes. When Java was first introduced the char type was based on Unicode 88 and they did not change this when Unicode 2.0 came out. In order to support the additional codepoints in Unicode 2.0 Java uses surrogate pairs, two chars.
In a True Type Font file characters are looked up via their Unicode code point. You could just use a char for this as the int value of a char is its Unicode codepoint, but that leaves out the additional characters supported by Unicode 2.0.
In order to support this jME-TrueTypeFont loads the string into a StringBuilder and uses the StringBuilder.codepointAt method which supports Unicode 2.0 by looking for surrogate pairs and returning the appropriate Unicode 2.0 code point.
2.) jME-TrueTypeFont uses one texture for each instance. The default maximum resolution is 2048x2048, but you can change this to whatever you want so long as the graphics card supports it.
Okay, nice that part 1.) is handled so well. I think we should inject some of that ānew codeā into BitmapText too - since the glyphs itself are stored in an IntMap already.
About the second thing ā¦ Iāve crossed the border that my gfx card sets (usually 8k x 8k for not-so-old middle-class card) with full set of the āHanazonoā-derived font quite quickly. That uses almost all known Kanji (Chinese glyphs). Even when packing them into the four channels (R = one set of glyphs, G = next set of glyphs, B = next set of glyphs, A = next set of glyphs) you need the second texture quite quickly. Especially if you use 44 pixels high glyphs (needed if you want the Kanji to be rendered in different styles like āboldā and āitalicā or just to get the higher resolution for headlines etc.).
Iām sure Iāll work a solution for ultra large character sets at some point in the future, but for now I guess thatās not supported. jME-TrueTypeFont will load characters up until it can no longer grow the texture to fit more characters. At 44 pixels high and a 2k texture thatās at least 2,166 characters.
I say at least because jME-TTF packs characters diffidently than the SDKs built-in bitmap font creator. The built-in creator spaces characters evenly along each line, each character gets the same amount of space in the atlas regardless of whether itās an āIā or āGā. jME-TTF can fit more characters in the same space because each character is given an amount of space based on the width of the character so an āIā takes up less space in the atlas than a āGā.
Thatās how it should be. I use the BMFont.exe from AngelCode. I have, however, implemented my own glyph-packing which respects the width and even the height (sorts all glyphs by their height in descending order, then places them in lines that suit their height).
jME-TrueTypeFont couldnāt really sort all glyphs by height when creating the atlas since glyphs are being added to the atlas on an as needed basis rather than all at once. I would say if you absolutely need every single glyph in a giant font with thousands of glyphs then jME-TrueTypeFont might not be the best solution, stick with BitmapFont.
That and a few other things like combo boxes and on the fly creation of gradient backgrounds with rounded corners and borders. Anyway, yeah just the one on Google Drive.
jME-TrueTypeFont has been updated to version 1.28 which fixes a bug where some Android devices would throw a VerifyError upon loading a font. Apparently some Android devices still look for java.awt.font even if itās in an if statement that wonāt test true. Separating it out into a separate class that is only loaded when run on desktop solved the issue.
For anyone using LemurDynamo it has also seen a few updates and now stands at Beta 15. Fixed a few issues with layers, an issue where fontās wouldnāt keep the alpha setting set through setAlpha() if setText() was called afterwards and updated the shader for GradientBackgroundComponents for better support of Android devices that donāt support high precision floating point variables, though if they donāt support high precision and do support standard derivatives there may still be an issue compiling the shader due to a problem with jMEās GLRenderer where it inserts precision mediump float; above the extension declaration.
Okay I finally got around to looking into this and the jmescher library, which is licensed under the New BSD license, depends upon the javax.vecmath library which is licensed under, you guessed it, GPL.
First, Stallman has always been against the classpath exception.
Second, if they are importing the classes then they get no classpath exception, anyway. No more so than a C app would get a ādynamic libraryā exception. Thatās what LGPL is for. If tiās not LGPL then you canāt use it without also being GPL. Period.
" When GNU Classpath is used unmodified as the
core class library for a virtual machine, compiler for the java languge,
or for a program written in the java programming language it does not
affect the licensing for distributing those programs directly."
Yes I think that means jmesherās lib is licensed incorrectly.
But, Iām not ready to lose hope yetā¦ with a casual look over the source, Iām only seeing a few classes from javax.vecmath being used andā¦ Iām thinking they probably aināt all that tough to replace:
Looks like some easily torn out and replaced piss ant classes to me. Iām going to try replacing that entire dependency (with jMEās versions for some ) this weekend if nobody else does it first.
Or we could see if the author will do it to fix the license issue. New BSD is forkable in any caseā¦
) this weekend if nobody else does it first.
New BSD is forkable in any caseā¦