Show me a way to render text than FreeType..

Started by
8 comments, last by FireInDark 11 years, 8 months ago
As shown in the topic , I've take a look at FreeType for text rendering in my project.
But it is not so easy to use thus some one has explained some thing of it for me at gamedev..

And just right now I searched out pango and cairo ..
I know nothing about them two except pango can be used to render texts in cairo (ofcuse FT)

Now I just need to rendering texts, get the pixel data and some info about the text's image (such as the position,the width,and the height of every text's bounding box)

I need to render the texts and need select the text by mouse ..

Question :
1.will the pango lib show me the pixels data poingter in memory and tell me the infos I need
2.any other lib for text renering rather than Pango and FreeType..

Any info you can tell is welcom ..thanks.
Advertisement
So far as I know, most things are actually based on FreeType. I've personally used SDL_ttf, and it is as easy as it gets. The result of rendering is an SDL_Surface, which has got exactly what you need. Now, to access individual pixels, you have to make certain the surface is in RAM and not VRAM. I think that is the default on all platforms with SDL 1.2 now, but I am not sure. Then, there is the problem with accessing individual pixels - that is depth and stuff. There is a very old example on the aging SDL tutorial (look up getpixel), and there is some stuff again at lazy foo about pixels and SDL_Surface.

On Windows, you can use DirectWriteto render to a bitmap. From what I've seen, DirectWrite is fairly complicated and requires you to use Direct2D for the actual rendering, which is yet another pain in the ass. But it does seem to produce high-quality text.

Universally, you can simply use a spritesheet that contains pre-rendered glyphs. If the original font were a monospace font, and the ordering of the glyphs predefined, it is trivial to selectively render the desired glyphs by copying them to another destination. There are a lot of bitmap font generators, such as the AngelCode BMFont, Fancy Bitmap Font Generator, fontbuilder, and Codehead's Bitmap Font Generator. Since the font is monospace, glyphs are guaranteed to have the same dimentions. You know how many characters are located per column and how many rows you have, so getting a clip rectangle is just multiplication (that is, if you logically view the spritesheet as a matrix, you can get any cell via simple math). Since you know where each letter is, you can calculate to which cell a glyph belongs. Once you've calculated the clip rectangle, it is simply a matter of copying it over to where you want to render the glyph on your scene. Also, since all characters have predefined width and height, you can determine the size of a string you want to render.

I don't know what libraries you use, so it really boils down to your preferences. The thing that will literally draw 0 dependencies is the bitmap font approach, but it is also the least flexible.

To directly answer the question about pango. I have never used the API, but it seems they have documentation. I urge you to consult it. Two minutes spent with the documentation partially answer the question: you need to obtain font description, and then use either pango_font_metrics_get_approximate_char_width, or pango_font_metrics_get_approximate_digit_width. Honestly, I'd rather poke my eye out than working with this API, as it might as well depend on some gtk+ library, plus it is freakishly ugly. As far as accessing the pixel data of rendered strings - that depends on the renderer. I do not think it is worth to use this, as it pulls in a ton of dependencies.

Finally, without any real information as to target platforms, libraries you use, etc, there is no way on Earth I can be more helpful than that. Finally, it would help you greatly if you learn some of the typography terminology. Regardless of API, the theory is always the same, just getting the metrics is slightly different. I learned about it from Charlez Petzold's book on Windows programming, and the best free resource I could find is this article. Skip over the API stuff, and concentrate on the theory.
You can also use non-monospace fonts with some of those exporters. I've currently been using BMFont, which allows you to export the width / height / kerning info for each character, as well as a few more things.

Writing a routine to use this info to blat out strings once you have your font 'texture atlas' is not-super complicated. However, once you start doing line wrapping and justification, and adding more than just the basics it gets a bit more tricky.

If you can bear it though, the effort integrating / learning freetype or similar is probably for the best, unless you want to do it for learning's sake.

On windows, using the latest MS api should give you the best quality, using their 'cleartype' system, which uses subpixel rendering. Freetype has subpixel rendering turned off by default I believe, to avoid the risks of MS patents.
OK?
Thanks for all of you two..

If just for using in this project ,I can render text with GDI and FT simply ..
And I can make font bitmap myself.
But for a long time I used to find a way to render text ,it is so important - than any thing in all softwares needing GUI- I must have a right way ..

I've tried to use bitmap fonts ,and also to load TTF and other font files but I can't get how to use the data in those file to render it to text image..
Any help?
I think both of us replied to this. Like I said, if you read a bit more about text and typography, it will be very helpful for you.

People coming from command-line background think that text is easy (e.g. printf/puts). In fact, it is quite the opposite. Dealing with text can be one of the more complicated things you will have to do. There is the multitude of ways to encode text, and the whole confusion that is called unicode (at least three ways to encode the same thing, really?).

Anyways, what concerns you is how to render text on the screen. You didn't mention neither language, nor graphics API except for GDI. Therefore, I will simply assume you use GDI and C++.

OK, so you can "load" a font. What is a font? Just a bunch of statistics (height, width, etc), mappings, and, overall, describes *how* and *what* to draw. It would be helpful for you to understand what True Type fonts are. On its own, loading a font doesn't enable you to render them.

Now, what you see on the screen is created by a renderer. Roughly speaking, it takes a font description, a sequence of characters, and draws them onto a surface. That surface may be an image. You can specify what is the format of that image. And therefore, you can obtain its pixels.

Since you said you have managed to load a font with GDI (with CreateFont* and SelectObject) rendering it is very simple. All you need to do is call one of the text drawing functions:
So far as metrics go, you can obtain TEXTMETRIC via GetTextMetricsfor the currently selected font. The line height is roughly tmHeight + tmExternalLeading. The average character width would be tmAveCharWidth. For a monospace font, it will be OK to just use that metric. If you used proportional font, you will need to get OUTLINETEXTMETRICvia GetOutlineTextMetrics.

In order to get the "pixels" (what for?), you will need to render in memory on a bitmap. You do this by rendering on a compatibleDC, which has selected a compatible bitmap. When you are done, you should be able to access to the pixels via GetPixel/SetPixel for individual pixels, and to the whole data via GetDIBits.

And I don't know why you need this at all. If you said what you wanted to do in the first place, it would have been much easier to help.

And I don't know why you need this at all. If you said what you wanted to do in the first place, it would have been much easier to help.


It's sunday you know,I gone to fishing ,so I get your reply till now..

So what I meaned by "load font files" is :
We know that there are datas expressing Bezier curve and lines _maybe we can call them out lines ..OK don't consider about hint now.but how should I got the info about Bezier curve and lines ..and ofcause ,there are datas for layouting ....

Yes I want to render text by the font files myself instead of the work by FT..
I know it's a hard work .but I really want to do it my self..
To be honest I can't express my mind accurately in english.But I think you would know what I want to do by words above..

Thanks for your help...

Yes I want to render text by the font files myself instead of the work by FT..
I know it's a hard work .but I really want to do it my self..
To be honest I can't express my mind accurately in english.But I think you would know what I want to do by words above..
Are you really sure? Ok, perhaps you're sure. I hope you know what you're going to do and why. My current approach involves

  1. Uniscribe. Maps char/wchar_t to glyphs and positions.
  2. Triangle library. Produce triangles out of contours.
  3. Resolution Independant Curve Rendering using Programmable Graphics Hardware.

This gives me a nice "fire and forget" text which, differently from freetype, can be zoomed and transformed without loosing too much detail. It required quite some work (warning) and quality isn't much of a big deal for the time being. Small character text is often a blurry mess. Think about it.

Previously "Krohm"

Using bitmaps for rendering text is the easiest route, as long as you're limiting yourself to the kind of US English used by Jesus when he wrote the bible. Anything else, and you better brush up on typography. Trying to create a bitmap to support every single Unicode codepoint and being able to handle the metrics of combined characters and right-to-left or vertical scripts will reduce your productivity a bit. Add in multiple typefaces, pointsizes, and slant for added kerning fun.

The only library I've ever seen that comes close to doing proper typography is pango.

Stephen M. Webb
Professional Free Software Developer

Thank you very much ..
Replies above are helpful for me .
Text rendering is a hard work,I need to study about it for a long time .Then I can decide.


This gives me a nice "fire and forget" text which, differently from freetype, can be zoomed and transformed without loosing too much detail. It required quite some work (warning) and quality isn't much of a big deal for the time being. Small character text is often a blurry mess. Think about it.


Infact ,I can draw images no matter with CPU or GPU ,no matter GLSL shaders or OpenCL .
If I know the path to draw pixels I can do it..
But now,the hardest for me is how to get the "path data" in font files..
Yes I know the inofmation in fonts files expresses where to draw pixels ,so want I want is getting the right infos ..

Such a charactor "A" there're infomation express the out lines if it in a font file ..

typedef struct _CharRenderingInfo
{
//what we need ?
}CharReneringInfo;

typedef unsigned int uint;
int getTextImage(wchar_t charactor,unsigned char font_size,char* font_file_path,char* out_bit_buffer,uint out_width,uint out_height)
{
fstream file(font_file_path);//First we open the font files .
//OK now we should find the right info data from the file.But :HOW
//We need a struct to express the need info for this our "A"
CharRenderingInfo CRINFO = findInfoFromFontFile(file);//how?
//Here we can render it by the CRINFO

}
If you know any links can explain the data structs in TTF files ,that'll be kind..

The only library I've ever seen that comes close to doing proper typography is pango.


I do have took a look at pango,and tried to use it but there are some problems when compile it.
AND that
"Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries.
Native fonts on Microsoft Windows using Uniscribe for complex-text handling. Rendering can be done via Cairo or directly using the native Win32 API.
Native fonts on MacOS X using ATSUI for complex-text handling, rendering via Cairo.
"

Cause words above I think it's not the right what I want..

Thank you ..

This topic is closed to new replies.

Advertisement