frankheckenbach / ftgl Goto Github PK

Hi,
in reference to this: ulrichard#15 (comment)

You can trigger this bug by cycling A-Z and a-z characters with the font

Cambay Devanagari Regular

CambayDevanagari.zip

Maybe try the other variants of the font too, there seemed to be different characters in different variations.

Build with GCC fails on:

FTVectoriser.cpp: In member function 'void FTVectoriser::MakeMesh(FTGL_DOUBLE, int, float)':
FTVectoriser.cpp:277:52: error: invalid conversion from 'GLUTesselatorFunction' {aka 'void (*)(...)'} to 'GLvoid (*)()' {aka 'void (*)()'} [-fpermissive]
  277 |     gluTessCallback(tobj, GLU_TESS_BEGIN_DATA,     (GLUTesselatorFunction)ftglBegin);
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                    GLUTesselatorFunction {aka void (*)(...)}
In file included from FTInternals.h:73,
                 from FTVectoriser.cpp:30:
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290:74: note:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())'
  290 | extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
      |                                                                 ~~~~~~~~~^~~~~~~~~~~~~~~
FTVectoriser.cpp:278:52: error: invalid conversion from 'GLUTesselatorFunction' {aka 'void (*)(...)'} to 'GLvoid (*)()' {aka 'void (*)()'} [-fpermissive]
  278 |     gluTessCallback(tobj, GLU_TESS_VERTEX_DATA,    (GLUTesselatorFunction)ftglVertex);
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                    GLUTesselatorFunction {aka void (*)(...)}
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290:74: note:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())'
  290 | extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
      |                                                                 ~~~~~~~~~^~~~~~~~~~~~~~~
FTVectoriser.cpp:279:52: error: invalid conversion from 'GLUTesselatorFunction' {aka 'void (*)(...)'} to 'GLvoid (*)()' {aka 'void (*)()'} [-fpermissive]
  279 |     gluTessCallback(tobj, GLU_TESS_COMBINE_DATA,   (GLUTesselatorFunction)ftglCombine);
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                    GLUTesselatorFunction {aka void (*)(...)}
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290:74: note:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())'
  290 | extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
      |                                                                 ~~~~~~~~~^~~~~~~~~~~~~~~
FTVectoriser.cpp:280:52: error: invalid conversion from 'GLUTesselatorFunction' {aka 'void (*)(...)'} to 'GLvoid (*)()' {aka 'void (*)()'} [-fpermissive]
  280 |     gluTessCallback(tobj, GLU_TESS_END_DATA,       (GLUTesselatorFunction)ftglEnd);
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                    GLUTesselatorFunction {aka void (*)(...)}
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290:74: note:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())'
  290 | extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
      |                                                                 ~~~~~~~~~^~~~~~~~~~~~~~~
FTVectoriser.cpp:281:52: error: invalid conversion from 'GLUTesselatorFunction' {aka 'void (*)(...)'} to 'GLvoid (*)()' {aka 'void (*)()'} [-fpermissive]
  281 |     gluTessCallback(tobj, GLU_TESS_ERROR_DATA,     (GLUTesselatorFunction)ftglError);
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                    GLUTesselatorFunction {aka void (*)(...)}
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:290:74: note:   initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())'
  290 | extern void gluTessCallback (GLUtesselator* tess, GLenum which, GLvoid (*CallBackFunc)());
      |                                                                 ~~~~~~~~~^~~~~~~~~~~~~~~
make[2]: *** [libftgl_la-FTVectoriser.lo] Error 1

Hello,
I am trying to build 2.4.0 on Slackware 14.2, but I am getting errors. Any help here would be appreciated.

Output:
https://pastebin.com/8ntsJYqf

TL/DR: I've dumped FTGL in my own code and won't do any more maintenance in my GitHub fork. Reasons follow, including some general criticism of FTGL.

I forked this repo from ulrichard who also told me then he wasn't interested in maintaining it further. The original authors have been unresponsive for a long time. Anyone who cares about the library might want to take over maintenance, which may be a simple as forking this repo and declaring it the new official version. :) And hopefully fixing some of the open issues ...

The immediate cause was that I needed to adapt my code so it can run with and without an OpenGL connection and do text layout in either case. Since FTGL loads the fonts into textures in its constructors already, I could not use it in the "no OpenGL" case, so I needed to use FreeType directly.

Now, doing the same layout with FT in one case and FTGL in the other would lead to quite some code duplication (and possible bugs since the conversion from FT's metrics is a bit tricky in some places). So I now do it with FT fonts in either case.

However, it's not possible to "upgrade" an FT font to an FTGL font, i.e. constructing the latter from the former. So in the OpenGL case I'd have to load the same font again for FTGL which is inefficient (and opens the door for other bugs).

So I looked into FTGL as for what it would take to make this possible. But at the same time, I also looked how much of FTGL's code actually remained that I'd be using, and especially for the
texture font (the most common and "normal" one, and the one I currently care about), this was petty little.

Apart from interfacing FT and converting the metrics (which I'd already implemented myself before, for another non-FTGL project), all that remained was basically mapping the characters into textures (see FTTextureFontImpl::MakeGlyphImpl and FTTextureGlyphImpl::FTTextureGlyphImpl).

Side note, the FTGL code gets a little more complex due to preloading 128 glyphs. I don't seem to need that feature, and I wonder if it's actually more harmful than beneficial: Besides doing more work (in most cases, not all of those 128 glyphs are in fact used, and no work is actually saved or optimized by doing it at start), it creates (IMHO unnecessary) distinction between those 128 glyphs and the rest (i.e., typically ~ ASCII and non-ASCII), and bugs that would affect only the glyphs loaded later might be easily overlooked by developers using only ASCII, in particular English-speaking developers.

So after removing this in my test code, and reusing my general texture-setup code I had written elsewhere, what actually remained was just a few dozen lines of codes to map the glyph pixmaps FT gives me onto a texture. That was all that FTGL was doing for me at this point, and I had to conclude that's not worth it. The mere boilerplate that comes with using a library, dependency management, plus FTGL-specific setup including setting LegacyOpenGLState (that was necessitated by some historic mismanagement) took slightly more lines than reimplementing the texture mapping. So by that metric, FTGL's value had become negative to me. So I've now completely dumped FTGL and use FT directly.

(Short note about the other font types: Bitmap and pixmap are basically obsolete if they haven't always been (seeing as they don't respect the transformation matrix etc.), polygon font doesn't seem to offer anything texture font doesn't since multitexturing exists. Outline and extrude do provide for some extra features, but if I'll ever need them, I now think it would be easier to reimplement them myself too.)

Also I was reminded again of some code quality issues in FTGL I'd seen before but almost managed to forget about. I'll list some of them here. Anyone who plans to do major work on FTGL's code might want to consider these points in advance, to know what you're getting into:

• The class structure seems much too complex for its job, partly due to heavy overuse (IMHO) of the pimpl pattern. Almost any simple operation goes through so many classes (e.g. FTextureFont, FTTextureFontImpl, FTFont, FTFontImpl, FTTextureGlyph, FTTextureGlyphImpl, FTGlyph, FTGlyphImpl) and many of their methods just forward to the next one, so it's often unnecessarily hard to find out what's actually going on).
  Plus a number of helper classes such as FTPoint which look like a great example of OO overengineering -- there's no point declaring data private and at the same time providing fully-general public getter and setter methods. It does not provide any encapsulation (not that any is needed), and burdens the caller with method calls instead of field accesses.

• Of course, being written in the early 2000's, the code doesn't use any newer C++ features such as "auto", range-based "for" loops, unique_ptr, inline initialization etc. Honestly, reading this kind of code today feels closer to C than to modern C++.

• The Unicode support uses wchar_t which is generally a rather useless type since it's unspecified whether it's 16 or 32 bits wide (or in theory, even 8 bits). Of course, char32_t wasn't available back then.
  Actually, I now realize, FTGL seems to treat wchar_t as UTF-16 always, even when it's 32 bits. This might explain a bug I'd had for a long time that it didn't seem to work with non-BMP characters -- it probably expected UTF-16 surrogates even in UTF-32 (wrongly). I'd never investigated that further because non-BMP wasn't that important to me. I just know that after switching to FT, non-BMP works just fine.

• All of these things, and some miscellaneous issues, give me the impression the code is ripe for a complete rewrite already.

• Finally, OpenGL is evolving. We now have OpenGLES and Vulkan, both of which I might need to port my code to in the foreseeable future.
  Of course, FTGL doesn't support those, and given that state of the code, I'd fear having to make such a port. Whereas now I have a clear separation of FT (which doesn't need porting), my own texture handling etc. (which I'd need to port anyway) and just a few lines of font to texture mapping which are easy to port.

I tried the demo, and it crashes as soon as I enter ü. I am not suggesting this character must be supported, but at least it shouldn't crash the application if a letter isn't supported.

FreeBSD 12.1, cmake 3.17.3, ftgl 2.4.0:

-- The C compiler identification is Clang 8.0.1
-- The CXX compiler identification is Clang 8.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Freetype: /usr/local/lib/libfreetype.so (found version "2.10.2") 
-- Found OpenGL: /usr/local/lib/libGL.so   
-- Found Doxygen: /usr/local/bin/doxygen (found version "1.8.15") found components: doxygen dot 
-- Could NOT find CxxTest (missing: CXXTEST_INCLUDE_DIR CXXTEST_PYTHON_TESTGEN_EXECUTABLE) 
-- Configuring done
CMake Error at src/CMakeLists.txt:120 (ADD_LIBRARY):
  Cannot find source file:

    FTLibrary.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


CMake Error at src/CMakeLists.txt:120 (ADD_LIBRARY):
  No SOURCES given to target: ftgl


CMake Generate step failed.  Build files cannot be regenerated correctly.

FTGL is a great library but I feel that some functionality would be useful for Vulkan, DirectX, and software renderers. In particular, I think FTVectoriser.h should be exposed and exported so that anyone can use that code in other applications.

Then, maybe later, we can separate this functionality from the OpenGL functionality so that others can use FTVectoriser and related symbols outside of an OpenGL application. This would allow others to extend ftgl to support other renderers like SDL2, DirectX, GDI, et cetera.

GL_TEXTURE_ENV_MODE is not valid mask for glPushAttrib. Use GL_TEXTURE_BIT instead and texture env mode won't be leaked anymore.

build with cmake. errors show missing FTLibrary.h.
src/CMakeLists.txt libftgl_la_SOURCES should not include FTLibrary.h.

The current release (2.4.0) doesn't build for me, I can only build after 835f2ba where CMakeLists.txt was fixed. Can you please tag a new release with this fix?

In the README.md, the version is listed as 2.3 but the CMakeLists.txt has a different version.