Re: [ft] FT_Done_Face Should Not Return An Error

On 5/10/2018 12:29 AM, Lawrence D'Oliveiro wrote: On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote: IMHO, `FT_Done_Face' shouldn't return an error code at all. Glad you finally agree. Why are so exceptionally persistent? Please help me understand your primary motivation

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 9:56 PM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: The important part here is that the constructor of gltb::Error records the actual runtime callstack of where it was executed, that is, how the throw statement was reached in the exection flow

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 10:15 AM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: if(FT_Done_Face(face != 0) { You got to be kidding me. OK, there's a brace missing. That doesn't change anything I explained below

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 1:19 AM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 00:11:12 +0200, Gregor Mückl wrote: Just don't assume that you know better than the creator of the host program when it is okay to bail and how to do so. As the provider of the lower-level abstraction, you guarantee certain

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/5/2018 11:32 PM, Lawrence D'Oliveiro wrote: On Sat, 5 May 2018 19:49:30 +0200, Gregor Mückl wrote: Please don't create another library that blindly terminates its host program on a whim. s/whim/internal consistency failure/ Which is a whim as far as the caller is concerned, isn't

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/5/2018 11:54 AM, Lawrence D'Oliveiro wrote: It is common for object-disposal routines to never return error statuses. The archetypal example is free(3) . If this is passed a valid pointer, it disposes of the object; if it is passed NULL, it quietly returns

Re: [ft] Question about porting source code to C#

On 1/26/2018 8:40 PM, Александр Струняшев wrote: Hello. For current project in our company we are needed in FreeType library to render glyphs. Project written in C# and should work on Windows and Linux. We tried with unmanaged libraries using Marshaling and everything worked well.

Re: [ft] Turkish character problem

On 01/02/2017 06:42 PM, ERCAN ARSLAN wrote: My fonts contain Turkish characters such as ç, ş, ö, ü, ğ , İ , Ö, Ü. There are no turkish characters in the C header file. Why does not it create a bitmap of turkish characters. I want to print turkish characters on my 1.8 TFT lcd screen. I can

Re: [ft] Fast wordcloud using FreeType?

On 9/12/2015 7:53 AM, Kane O'Donnell wrote: For a pet project, I'm looking to make a wordcloud generator (e.g. http://www.wordle.net/) that is as fast as possible, and as someone quite new to text rendering, etc., I was wondering if the community could offer thoughts about terms of using

Re: [ft] FT_New_Face() returns error

On 2014-01-13 14:31, Werner LEMBERG wrote: some users of a software reported a bug I have never seen on my systems. It seems like funktion FT_New_Face() returns an error FT_Err_Cannot_Open_Resource for these users. The funny thing: when they try for a second time, everything is working well

Re: [ft] [ft-devel] Windows x64 Build

Hi! For Visual Studio it is quite common to ship only one set of solution and project files which contain the settings for 32 bit and 64 bit builds. So I think that Werner's suggestion to keep only one set of files is the correct thing to do as this makes future maintainance of these files

Re: [ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?

On 6/3/2013 9:05 AM, Werner LEMBERG wrote: I've reduced my code to the attached program (which is still a bit convoluted - sorry!). [...] Thanks. There was a serious bug in FT_Get_Advance which has been fixed in version 2.4.9: According to the documentation, the returned advance value is

[ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?

Hi! I've upgraded a project of mine from using freetype 2.4.4 to freetype 2.4.12 and now I experience totally broken text layouting (the layouting code is my own). Horizontal spacings between characters are now either far too large or far too small, depending on the font. In one case the

[ft] FT_Get_Advance spuriously returns advance 0

Hi! I think I'm in need for some hints in order to track this one down. Here's the problem: I've run into a problem with text layouting engine that I've written based on Freetype. For some reasons, FT_Get_Advance sometimes returns an advance of 0 without reporting an error, while when