Font Creator for jMP

Hi!

I have a problem with this tool. In JMP (the platform released in 2014, I think), the font looks OK when I’m deciding it’s size, padding, etc. (the second screen shot in the first post in this thread). But the generated .png has antialiasing, and narrow parts of letters disappear completely. Can I avoid this somehow?

See below. The png is the lower one, obviously. The 3, 5, 9, and s in it have lost some parts.

Also, another problem, not with this tool probably, but maybe you can help anyway: The ‘q’ in the image above reaches higher than the ‘p’. Why? I guess it’s somehow like that in the font, but when I saw it written in Google Fonts I could not notice it.

Did you try raising the image resolution?

@normen Yes, not a big improvement. The problem is that it looks bad when I later, in my game, use a small font size anyway. It’s the antialiasing I don’t want. I saw in the source that antialiasing is explicitly set. But I dunno how to build the whole thing if I change that.

http://www.angelcode.com/products/bmfont/

@pspeed Thanks!

When I tried to convert chinese font. it only produce 256 characters.

There seems to be some sort of bug. This is not the problem itself but if I understand correctly, in here it is hard coded that there are 255 characters (but quickly reading the reader it doesn’t read this value?):
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/sdk/jme3-angelfont/src/com/jme3/gde/angelfont/FontCreator.java#L144

But here, the number of characters aren’t passed forward, thus always creating the default 0 - 256 chars:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/sdk/jme3-angelfont/src/com/jme3/gde/angelfont/AngelFontWizardIterator.java#L80

Theres 255 characters per page. What is the actual issue you’re describing?

Ah ok, I don’t fully understand the code (nor the format). But if you select i.e. Arial. And select char range 0-1024, you only get the 255 characters. As in one page?

Either the GUI is too complicated for me (the tooltip on the char range indicate padding, but I assume this is copy + paste bug). The preview does show the characters being set to the image, but the end result doesn’t contain but the first 255 chars. This is the issue. As I think @SteveLiu tried to say also.

@normen

Transport this subproject to JME engine! or make it into an external lib?

I am thinking if end users could, from within the game application, select a font dynamically from the system and let it be applied wherever the developer allow it?

Basically, the jme3-angelfont sdk sub-project would require to be made into a jar lib to be usable into applications that use the JMonkeyEngine.

Why? so the end user could decide how some (or all) fonts would look like

The user would select all the simple parameters we see on the FontCreator from inside the SDK (font size, texture size etc), but not necessarily using that windowed inteface; it could simply be a single text line with all parameters set.

and do not store them… all happens dynamically

The fnt and png would be created into a cache that could be temporary, so every time the user changes the font option for some part of the application, it would create a cached font named like “TopMenu.fnt/png” and not the actual font name. So, the idea is to let the end user decide what he/she wants, and still do not create a font conversion pipe thru the FontCreator lib. The converted will only exist on the user machine and could even be required to be recreated everytime the application is run.

Basically, this is how non 3D windowed application works I guess, they collect the font from the system, convert to their internal format and apply it, but the converted format is not kept neither exportable.

PS.: Concerning if the fonts will look good or not, that is for the end user to decide; and what fields will be allowed to change fonts, thats for the developer to decide :>

The problem with that (if i understand you correctly) is that the end user (the gamer ?) will maybe not be on desktop and libraries used to generate this font (java.awt.Font, likely. So java.awt ) will not be available.
The thing done here is a rasterisation, it transforms vector images into pixel images. But it implies that the program can read and manipulate vector images, and libraries to do that are either platform-specific (well, java.awt.Font exists both under linux and windows, i think) or very heavy (80 mega) and buggy.

And it’s precisely because jme wants to work under both android and desktop that we don’t use swing awt or other solutions (apache did one pretty cool, can’t find the name) based on that. So, allow a running app to generate fonts deserve the main purpose of these fonts.

P.S.: i use a custom font format for my gui library, and i use awt Font class to generate my file. I don’t know how normen do that and i am not a “pillar” of jme or anything close to that. Maybe all i said was bullshit.

1 Like

Actually it’s not only about the java.awt Class but this:

Imagine you use some cool Fonts in your Game.
Your User would need them locally installed (or maybe it works if you specify a file, but maybe not just with awt).
Also that Rasterization takes quite some time compared to a simple textured plane (which is what a Font is).

If it’s just for the resolutions, do them hi-res and scale down. It should work pretty good actually.
If you still think you need many changing fonts, styles, sizes then have a look at march/april’s WIP Screenshot Thread. Someone is currently working on such a feature.

There are also other projects, which simply transform a given text into triangles so you can render them. This obviously takes much more rendering performance but is resolution independent.
See OpenGL Programming/Modern OpenGL Tutorial Text Rendering 01 - Wikibooks, open books for an open world for some low level stuff.

1 Like

Basically I am trying to give the end user more freedom/configurability on the application.

I know the SDK is not the Engine, but I like to think some cool features the SDK has alone could one day be made into engine pluggins, even if platform dependent.

@bubuche
It would still be good if we had the Font Creator as a JME Engine “Desktop” Plugin, and we would still provide fallback/placeholder fonts if planning on android release.

@Darkchaos
Very interesting seem like what I am asking, but couldnt find a download for it yet tho, would be cool if it gets released soon :slight_smile:

Yes, I was concerned about resolutions, I ended selecting the largest size possible fitting in 512x512. And when scaled down it still look great.

That c++ project, may be it could let we cache pre-rendered to the requested size, would do the trick concerning performance. And a java wrapper would be interesting, still looking for it :slight_smile:

My font rendering library is available for download by the way:

1 Like

Actually if you want something like that you could as well look into the font creator made by normen, understand the format of the xml file (shouldn’t be hard) and write something in PHP that will generate fonts on ask, then put this script on a host somewhere and voilà, you’ll have a font generation for android, desktop and actually everything that can go on the internet without having to recode it for each plateform.
And you can even distribute the script, so people can host it themselves.
I really think that it’s not a good idea to embed something that will be used once at most for most users. It’s like if you want to embed an engine factory in a car, so people can create their own engine if they want. Almost nobody will do that, and nobody will do that twice. It’s not the purpose of a car to do that.

Plus, some font don’t have every glyphs. So, if you replace the font of an application with an other font, you’ll maybe end with some real bugs (missing glyphs being the least, NPE or lost characters (for real, like when you open a binary file with notepad) being the most likely).

… or even just perhaps, Java.

prototyping is easier in php. Also, do you need inheritance, method override, public/private/protected stuff, reflexivity … for something that is basically a batch (every input are there at the beginning of the script that performs a one-shot run) ?
PHP comes with a library that allow easy ttf font manipulation, and writing such an easy xml file is pretty straightforward.
And free servers with php are more common than servers with java (last time i checked, at least).

1 Like

May be, a simple checker could be implemented: if a required glyph has no dots, after the end user selects a font, it will pop a message showing what is missing, so he/she can select another font.

Also, the final object being a texture, may be, a mix of user chosen font plus its missing glyphs from another font could do the trick… but, I know little about each glyph positioning (advance etc), but I believe we can trust on the “gaps filling” font information; just make sure to mix monospaced with monospaced and everything “should” go well (with the proper scaling of course, also to the glyph metrics).

You could use my jME-TrueTypeFontLite library for what you’re wanting to do.

assetManager.registerLoader(TrueTypeLoader.class, "ttf");

Then at some point have the user browse to and select a font file from their hard drive.

File fontFile = new File(userSelectedPath);
assetManager.registerLocator(fontFile.getParent(), FileLocator.class);

TrueTypeKey ttk = new TrueTypeKey(userSelectedPath,
    java.awt.Font.PLAIN, userSelectedPointSizeInt);
TrueTypeFont ttf = (TrueTypeFont)assetManager.loadAsset(ttk);

UI.getAssetManager().unregisterLocator(fontFile.getParent(), FileLocator.class);

the jME-TrueTypeFontLite library doesn’t include methods for determining if a glyph in a particular font file has contours or not, but the source is available so you could write that yourself easily enough:

public boolean hasContours(String character) {
    GlyphVector gv = font.createGlyphVector(frc, character);
    GeneralPath path = (GeneralPath)gv.getOutline();
    PathIterator pi = path.getPathIterator(null);
    if (pi.isDone())
        return false;
    
    return true;
}

Otherwise Google’s sfntly was a nice font reading library to work with, it also supports open type fonts. https://github.com/googlei18n/sfntly

P.S. The jME-TrueTypeFontLite library uses java.awt.Font’s canDisplay() method to determine if a glyph is available in a particular font file, if not a default glyph is used in place of the requested missing glyph. Although I have found some glyphs that java.awt.Font’s canDisplay() method returns true for actually have zero contours. The same was true with Google’s sfntly library, a glyph would be available in the font file, but would have no contours.

1 Like

oh ok! I re-read your post there, you made for your project a light version that doesnt depend on GPLv3 neither LGPL libraries, that will be very useful! jME-TrueTypeFont Rendering Library - #9 by Tryder
thx!