Fontmaps

Why is nobody discussing FTGL, have I been missing something?

FTGL is a free cross-platform Open Source C++ library that uses Freetype2 to simplify rendering fonts in OpenGL applications. FTGL supports bitmaps, pixmaps, texture maps, outlines, polygon mesh, and extruded polygon rendering modes.

Quote:

---

Originally Posted by Alfonse Reinheart

You're used to the Windows world, where if "the system" doesn't do something, then it may as well not exist. That's not how things happen outside of the Windows world. In the not-Windows world, you use libraries to get things done.

---

Just for the record I work with both but I do consider them to be wildly different types of operating environments filling ultimately different needs. I use Cygwin a lot with Windows but there is nothing in the Linux world that really encourages the development of monolithic platforms for Linux.

Quote:

---

If you use GTK, you have a dependency on Pango because GTK uses Pango for its text layout. It uses LibXML2 for its XML reading, so you have another dependency there. And so on. That's how things work in the not-Windows world: you pick your libraries and use them. Some of these are provided by the system. Some of these are provided by you.

---

Not to nitpick but I am aware of that. I don't use GTK for the record. But I do appreciate glib. But I've never developed a windowed app for X (so I don't know what is required to integrate with the window managers; full disclosure)

Quote:

---

Functionally, there's no difference between having a dependency on Pango and having a dependency on Uniscribe. The only practical difference is that in the Pango case, you have to link to the library explicitly, while in the Uniscribe case, you don't.

---

Exactly. It's not a project (sourcecode) dependency. It's under the hood.

Quote:

---

OpenGL is supposed to be a relatively thin wrapper around graphics hardware, in order to achieve a reasonable abstraction and allow for a reasonable platform-neutral interface to that hardware. OpenGL's job is not to make it easy to do complex things. It's job is to make it possible to do complex things. If something can be layered on top of OpenGL, then it should be.

---

Well yeah. OpenGL doesn't open any file formats. Fonts are files. So obviously rendering text is not implemented at the level of the OpenGL spec. But nevertheless it's important to make graphics accessible and text mindlessly multilingual. IMO it's pretty ridiculous that a consumer card cannot draw lines in 2012. But even I will admit that line drawing is less integral than drawing text, and there are legitimate, albeit pretty ridiculous, reasons for not implementing line drawing in hardware. Still it should be standard, especially as GPUs and CPUs become more and more integrated in mainboards. We shouldn't be having a discussion about drawing text in 2012. Printf like drawing should not introduce a new library to a project. That's just my opinion.

Quote:

---

You won't find any font rendering functions in D3D either, for similar reasons.

---

Search for D3DX.

Quote:

---

Originally Posted by Inagawa

I am not working exclusively with Windows, actually. The use of GDI+ (a painful experience as it were) is just temporary.

So how would you gentlemen advise me to continue?

---

Yeah definitely. But you might consider different strategies depending on what your ultimate goals are. I am definitely following this thread, and it will definitely influence my work. I hope you don't mind my taking advantage or it.

You basically would need to say what platforms you are targeting. What are you wanting to do with it. Is i18n important. Is it an opensource or closed source project. Is it of limited scope etc.

Depending on your answers a good answer might be yeah, if it looks good to you and it works, then that's that right? Or otherwise you might want to hang around and see what doesn't rise out of these ashes.

PS: If you are not planning on leaving planet Windows I think there probably are some things you can do to make things easier and nicer.

Quote:

---

Originally Posted by dukey

It works as a drop in replacement for wglfontbitmaps. Proper anti-aliased fonts for win32. Opengl 1-2 support.
It's not especially fast because it uses gldrawpixels, which doesn't seem to be very fast. But it works fine nonetheless.

If you use it credits to me please http://www.opengl.org/discussion_boa...lies/smile.png

---

Quote:

---

Originally Posted by def

Why is nobody discussing FTGL, have I been missing something?

FTGL is a free cross-platform Open Source C++ library that uses Freetype2 to simplify rendering fonts in OpenGL applications. FTGL supports bitmaps, pixmaps, texture maps, outlines, polygon mesh, and extruded polygon rendering modes.

---

Just wanted to say thanks for these two posts.

EDITED: Also as for FTGL. I do worry about these kinds of projects not supporting particular (widely used; non proprietary) font file formats for quasi-political reasons. But on the other hand I would not be surprised if there are file formats and fonts exclusively used in the Linux world. In which case there is probably a strong argument for doing things in more than one way in order to make all the fonts anyone might want to use just work so that they will be happy :(

Quote:

---

It works as a drop in replacement for wglfontbitmaps. Proper anti-aliased fonts for win32. Opengl 1-2 support.

---

The whole point of wanting to replace wglFontBitmaps (besides potential performance issues) is to not use removed functionality like glDrawPixels and display lists.

Quote:

---

Why is nobody discussing FTGL, have I been missing something?

---

Because it's 8 years old and clearly no longer being supported.

Quote:

---

IMO it's pretty ridiculous that a consumer card cannot draw lines in 2012.

---

You can draw lines in consumer cards just fine.

Quote:

---

Printf like drawing should not introduce a new library to a project.

---

This makes no sense. You don't want to use Pango to do text layout, and you don't want to use FreeType2 to do glyph creation and font processing. But you don't mind if something else uses them, if it's "under the hood".

OK, but that something else... will be a library. Which, if you're not already using in your project, will have to be introduced to it. The very thing you say you don't want to do.

So I really don't understand what it is you're looking for. It sounds to me like you want some magical, "Do everything I want" library to poof into being. You want FreeGLUT or whatever to simply solve all of your problems as you get them.

That's not going to happen; the sooner you accept that, the better.

Quote:

---

Search for D3DX.

---

I did. According to Wikipedia, it's Deprecated in the Win8 SDK. The only part that survives are the math functions that form the core of DirectX Math.

Also, D3DX is not part of D3D and it never was. It is a new library that you explicitly have to introduce to a project separately from D3D.

michagl: Well, the story is basically that I need a way of not only rendering the glyphs in good quality, but I also need all the glyph metrics, so I can position the glyphs individually.
GDI+ vomits some kind of metrics, but they are unusable.

I'd actually like to avoid using any external libraries at all if possible - I happen to be using C# and OpenTK, so any external library might be a big problem for me.

So let me get this straight. You want a cross-platform glyph rendering solution. But you don't want to use an "external library" to do it (even though GDI+ is an external library). So... how exactly do you expect this to happen?

In general, the non-Windows world renders its glyphs through FreeType2. But that's an external library.

I said I'd like to avoid using external libraries, but I will use them if there's no other way. And GDI+ may be an external library to you (C++), but not to me - it's part of .NET.

I'll have a look at FreeType2, it looks sweet. Thanks for the recommendation, I'll post here later on how it worked out.

Quote:

---

Originally Posted by Alfonse Reinheart

You can draw lines in consumer cards just fine.

---

Not in my experience. If you are using a normal consumer card for playing games changes are the lines will be broken and irregular when you use a line drawing API. This is still the case on a 1400$ gaming laptop that is going on 7yrs old. And its the case on an ATOM+ION2 (mainboard, cpu, and gpu in one) that is about 2yrs old now that I purchased as a backup. Actually the laptop has defect that kills the graphics modules, but I quit replacing them with the same model (because it became too expensive) and I don't know if I've done anything with line rendering since. Prior to around the times programmable GPUs became the norm drawing lines just worked. Though I tended to have workstation cards back then. Maybe nowadays you need an extension or something.

Quote:

---

This makes no sense. You don't want to use Pango to do text layout, and you don't want to use FreeType2 to do glyph creation and font processing. But you don't mind if something else uses them, if it's "under the hood".

---

Sure. Whenever you use a library you don't know what it is going to do under the hood. It's an abstraction layer. If you want to do something like a publishing app then you might want a lot of control. But if you just need to display text you don't want to complicate things, have to write a wrapper around a competing library that may not even be supported a few years down the line. You want something minimal and standard that can be relied on in the long term. Just displaying text should be as simple as writing text to a file in 2012. Since the ways to do that are not very mature on desktop platforms other than Windows there is no standard way to do it apparently. So we are just trying to figure out the best way in the meantime the way I see it.

Quote:

---

So I really don't understand what it is you're looking for. It sounds to me like you want some magical, "Do everything I want" library to poof into being. You want FreeGLUT or whatever to simply solve all of your problems as you get them.

---

Yeah that's how we do it. Ex. You don't program a software rasterizer in 2012 and you don't expect to.

Quote:

---

That's not going to happen; the sooner you accept that, the better.

---

It will happen but that's not the point. It's a shame it hasn't happened yet, otherwise this thread would be unnecessary. We have something like gettext to do translation. Drawing text should be as simple and as commonplace. It is an additional dependency which almost everything already has as a dependency, but its minimal and entrenched and well understood. Text is a basic currency of information exchange. It should be provided at the system level and integrated into OpenGL. If we lived in a world where you didn't need more than 65535 characters to render all of the symbols of all of our languages etc... if we just need ASCII things would be different. But the guts of Unicode need to be under the hood and easy to access so that we can easily communicate with it. It's a travesty IMO but again just an opinion.

Quote:

---

I did. According to Wikipedia, it's Deprecated in the Win8 SDK. The only part that survives are the math functions that form the core of DirectX Math.

---

I think D3D is deprecated IMO because its not compatible with XP past D3D9. Microsoft had to bring back XP after it declared it dead because it did not anticipate netbooks and nettops and it doesn't have anything for those class of PCs in the works. I love these things because I can buy a computer for the same price I used to pay for a cpu, and a mainboard, and a gpu, and presumably they are just going to get cheaper and cheaper... that's a huge market to neglect. I have almost no expensive habits in my life nowadays.

Quote:

---

Also, D3DX is not part of D3D and it never was. It is a new library that you explicitly have to introduce to a project separately from D3D.

---

It's an extension layer for D3D. It uses the same interfaces. It's analagous to GLUT. I think there was something else simply called Glu, but I forget, it's been so long. I did not tend to use either. But that was around the turn of the century. Most of all D3DX is something the end user installs separately from your application and if they play video games will almost always already have installed. On Windows that is important, even though in the Linux world you have package management (that makes DLL hell look like a picnic)

Quote:

---

Originally Posted by Inagawa

michagl: Well, the story is basically that I need a way of not only rendering the glyphs in good quality, but I also need all the glyph metrics, so I can position the glyphs individually.
GDI+ vomits some kind of metrics, but they are unusable.

I'd actually like to avoid using any external libraries at all if possible - I happen to be using C# and OpenTK, so any external library might be a big problem for me.

---

In my opinion the only worthwhile technologies Microsoft has ever developed are Win32 and COM (COM is slowly replacing Win32 completely which is probably for the best; D3D is an example of COM) and if you look under the hood of everything that MS churns out, MFC, ATL, GDI+, .Net, C# (and its 3 or 4 molts), all kinds of new stuff for Win8, and everything I've left out, of which there is likely many because I am very dismissive of all of them because like I was trying to say if you look under the hood you find out that these are all wrappers around Win32 and COM most of which have a very short life cycle. But I understand that MS requires the use of C# I think for some things like entry level Xbox development.

I would never use one of Microsoft's static OOP APIs like MFC and GDI+. All of the fonts in Windows are based on a class of functions that are equivalent to DrawText in its Win32 and D3DX variety. It should be possible to generate metrics with these if they are provided... but I am wondering why you are mixing C# and OpenGL. That seems like an unusual pattern.

Actually I forgot. GDI is actually just the graphics APIs of Win32. So it's definitely not deprecated. That means it's just GDI+ that is solidly deprecated. GDI+ is just an MFC like version of GDI in my experience. So probably you are already familiar with this family of functions in one form or another...

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

EDITED: Search for "Font and Text Functions" (since microsoft.com links have a lifespan of only a few months)

I think that is everything, but I may be wrong.

The metrics should not be unusable. You are probably just not doing something right (unfortunately we are stuck with Microsoft's "documentation" and short term memory until someone is able to topple this giant; and unfortunately compared to MS's competitors MS really looks more and more like the friendly giant nowadays)

MS calls these APIs legacy (not the same as deprecated) but the truth is everything boils down to Win32 or COM and COM does not yet do everything Win32 can and it certainly can't (and never will) on XP and all of Microsoft's non-legacy (read: deprecated or-soon-to-be wrapper) APIs are always supplanted after a year or two so they are really not worth the investment if you envision your code being useful ~2 years from whenever.

Quote:

---

Not in my experience. If you are using a normal consumer card for playing games changes are the lines will be broken and irregular when you use a line drawing API.

---

Define "broken and irregular". Lines are drawn. They may not be pretty, but they're drawn from point A to point B.

Quote:

---

It's an extension layer for D3D. It uses the same interfaces. It's analagous to GLUT.

---

No it isn't. GLUT is a toolkit for creating and managing OpenGL windows, with a few ancillary functions for doing useful things. And though D3DX provides many features, conspicuously absent from that feature list is a simple way to create and manage a D3D window. Similarly, D3DX's primary features are math functions, image loading, meshes loading, and shader/effects loading and management, none of which you will find in GLUT.

Please stop trying to pretend that two libraries that have completely different purposes are in any way comparable just because they're named similarly.

Quote:

---

GDI+ is just an MFC like version of GDI in my experience.

---

:doh:

In the future, please take the time to do some research before forming an opinion and spreading misinformation.