Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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 for this discussion. Why do you want this change at all?


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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 of the
program. And its asFormattedText method turns it into a readable
string. In various cases, I have dumped this string onto the console
(as in the example above), shown this in a Windows message box (no
console there) and written it into a log file that a user can locate
in the file system and send to me.

Also, on the way up to the exception handler in main(), stack
unwinding causes destructors of various objects to be called. That
way, RAII patterns in my code get executed: resources are freed,
files are closed (writing buffered file contents to disk) etc.


What happens if you have another FT_Face to dispose of?


Why would that matter? I cannot see the relevance to the topic.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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
invariants. In this case, that every FT_Face has a driver, and the
driver has knowledge of that FT_Face as long as it exists.

If that invariant breaks, there’s nothing that the caller can
reasonably do about it, because it’s none of the caller’s business.



This is where you reasoning is wrong. The abstraction is that the caller 
does not need to understand the exact nature of the error.


Error handling code rarely concerns itself with the exact error that 
happened, because they typically lead to the same handling strategies in 
the caller anyway. FT_Done_Face is also on this category.


(the only class of functions that I can think of that requires the 
caller to differentiate between error codes are a few blocking system 
calls that suffer from occasional spurious wake ups).



That’s what “abstraction” means.


This is highly dependent on the actual purpose of the program ...


In that case, perhaps you could show us an example or two of how you
deal with error returns from FT_Done_Face?



There are two choices here:

1. ignore it


From actual code that I wrote about 6 years ago:
-
	// Freetype could return an error code here, but it's not particularly 
useful to respect it

FT_Done_Face(TL_Globals.fonts[font].face);
-

Strictly speaking, this code is wrong, but this was for a game engine, 
so the worst thing that can happen is the player getting angry at a 
crashing game.


2. propagate the error up
=

Example using some C++ library code of mine:

-
if(FT_Done_Face(face != 0) {
throw gltb::Error("Freeing Freetype font failed", 
"TL_UnloadFont()");
}
-

In my main() functions there always is the following corresponding code 
around everything:


-
int main(int argc, char *argv[]) {
try {
// actual program code
} catch(gltb::Exception &e) {
std::cerr << e.asFormattedText() << std::endl;
return 1;
}
return 0;
}
-

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 of the program. And its 
asFormattedText method turns it into a readable string. In various 
cases, I have dumped this string onto the console (as in the example 
above), shown this in a Windows message box (no console there) and 
written it into a log file that a user can locate in the file system and 
send to me.


Also, on the way up to the exception handler in main(), stack unwinding 
causes destructors of various objects to be called. That way, RAII 
patterns in my code get executed: resources are freed, files are closed 
(writing buffered file contents to disk) etc.


This would not work if you just blindly call exit() or abort().

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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 it?


Returning an error really is the right thing to do
here. Just make it clear that this is a bad error.


And what exactly is the caller supposed to do about it?



Whatever the hell it pleases to do. I've outlined a few possibilities 
already. Depending on what the program is for, it may need to do some 
things even if (or especially because) things went wrong.


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. This is highly 
dependent on the actual purpose of the program - which you can't assume 
anything about. It could be a database frontend, a game or a medical device.


The only thing that I could possibly see myself agreeing with is a set 
of asserts that can be compiled in conditionally in specialized debug 
builds. So you'd get to break into the debugger if one of these very bad 
situations happen. A release build should be more optimistic and try to 
keep running instead, reporting the error.


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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
without doing anything. If it is passed an invalid pointer, then this
indicates a program bug, so there is no point returning an error code
anyway: better to report an error message to stderr and even abort the
program.

Looking at the code for FT_Done_Face, from src/base/ftobjs.c:

   FT_EXPORT_DEF( FT_Error )
   FT_Done_Face( FT_Face  face )
   {
 FT_Error error;
 FT_Driverdriver;
 FT_Memorymemory;
 FT_ListNode  node;


 error = FT_ERR( Invalid_Face_Handle );
 if ( face && face->driver )
 {
   face->internal->refcount--;
   if ( face->internal->refcount > 0 )
 error = FT_Err_Ok;
   else
   {
 driver = face->driver;
 memory = driver->root.memory;

 /* find face in driver's list */
 node = FT_List_Find( &driver->faces_list, face );
 if ( node )
 {
   /* remove face object from the driver's list */
   FT_List_Remove( &driver->faces_list, node );
   FT_FREE( node );

   /* now destroy the object proper */
   destroy_face( memory, face, driver );
   error = FT_Err_Ok;
 }
   }
 }

 return error;
   }

the only thing that can really go wrong is if the face cannot be
found among the driver’s memory blocks. Clearly something has gone
catastrophically wrong in this case, so it makes sense to report an
error and abort the program.

Otherwise, if it is passed NULL, it should just quietly return without
doing anything. This makes it easier to write code that initializes all
temporary pointers up front and unconditionally disposes them at the
end; there is no need to tediously check everything for NULL pointers,
because the disposal routines will take care of that.


Please don't create another library that blindly terminates its host 
program on a whim. Returning an error really is the right thing to do 
here. Just make it clear that this is a bad error.


Calling exit() uncontrollably on an error in a library is bad for a 
whole list of reasons, including but not limited to:


- robs host program of any chance to do a sane cleanup and graceful exit
- prevents the generation of an error report in programs that have this 
QA feature
- circumvents cleanup and error handling mechanisms of other programming 
languages (e.g. C++ stack unwinding)


Regards,
Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

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

[Gregor Mückl]

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.

Unfortunately for our project we could use only managed code. And that means 
that current implementation is not really fit our needs. We are thinking about 
porting C++ code to C#.

So I would like to know about this possibility. Could we do it or is there any 
license restrictions? We plan to use our project in commercial goal and sell it.

With best regards, Aleksandr.


Just for the sake of completeness: have you tried using C++/CLI? I don't 
have much experience with it, but it might allow you to compile the 
Freetype code with only some modifications instead of a full rewrite.


Regards,
Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Turkish character problem

[Gregor Mückl]

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 not print the C header file as I want on the screen, even if there

are no Turkish characters.



Hi,

with a quick Google search I determined that you most likely use the 
Adafruit GFX Library for Arduino. This is important information!


The author of the "fontconvert" program that comes with that library is 
in a better position to answer your questions correctly than the people 
on this mailing list. This list concerns itself mostly with the Freetype 
library, which is used by that program, but written by different people.


From a quick glance over the code of the GFX library I get the 
impression that the library as a whole is limited to 8 bit character 
sets. This is a valid decision in the context of a microcontroller with 
limited resources. There are many more characters in the world's 
languages than can be represented in 256 character codes. Therefore, 
different mapping tables have been created for different languages. This 
is the part where handling characters and text becomes amazingly 
complicated.


As a rule of thumb, most of these tables share the first 127 characters, 
but start to differ wildly beyond that. The characters you are asking 
for are not contained in these common 127 characters. So you need to 
choose a character encoding which contains the characters you need. A 
good 8 bit encoding table candidate for Turkish seems to be ISO 8859-3 
(also called Latin-3) or ISO 8859-9 (also called Latin-5). Another 
option is to use Unicode with UTF-8 encoding. I recommand against it, 
because this character encoding has a variable number of bytes per 
character and would require considerable changes to the Adafruit GFX 
Library.


Implementing that encoding requires a list of steps that can be quite 
tricky, however. You need to accomplish two things here:


- have fontconvert output a font table that correspond to your chosen 
encoding
- have the text strings you want to show to the user in the same 
encoding in your compiled program.


Unfortunately, this is far trickier than it sounds!

First, you need to extend the fontconvert program to map from the font's 
character map (most likely Unicode) to Latin-3 or Latin-5. This means 
that you need to extend the program with a mapping table that contains 
at least your requested characters.


Second, you need to use a text editor for your program source code that 
saves the source files in the encoding of your choice. The Arduino IDE 
does not seem capable of doing this (it looks to be hard-wired for 
UTF-8). There are many text editors out there that allow you to select 
the character encoding for a text file. Pick one for your platform, 
configure it correctly and stick to that configuration religiously once 
it works. It is usually quite simple to trip up and save a text file in 
an unwanted encoding, which in turn can cause interesting bugs.


Regards,
Gregor

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Fast wordcloud using FreeType?

[Gregor Mückl]

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 FreeType for this? What I
effectively need to be able to do is:

 1. map a given string (font + rotation) to some sort of binary pixel
array so I can tell what space the word fills.
 2. store that to a "canvas" pixel array (this is used to store word
positions and make sure they don't overlap, etc)
 3. once word placement is done, then be able to save the canvas (i.e.
drawn words) to a vector format (for printing etc) that faithfully
represents the original canvas.

 From what I've read, FreeType will allow me to handle 1. and 2.
relatively easily. However, I'm not sure about 3. While it's easy to,
for example, save the position/rotation of all placed words, and then
naively convert that to e.g. SVG, I'm not sure whether e.g. font size 32
means the same in FreeType as it will in SVG, and hence whether or not
my non-overlapping word layout will be preserved. I guess that's my key
question.

More than happy to get general feedback on such a project, including
other suitable libraries -- though a key requirement is for it to be as
fast as possible.

Kane

PS -- I've done something in Python but there was a messy and imperfect
hack to convert from PIL (bitmap) to matplotlib (PDF), which basically
failed point 3 as outlined above. I've also done this in Java, and I
managed to find two libraries which did the job well. However, now I'm
keen to learn a new language, and I enjoy using this as an example.

PPS -- I'm aware there are other methods (quad-tree + bounding boxes),
though they're not as simple as the "does this pixel overlap that one"
approach, and sometimes less functional and performant.



Hi Kane!

For text rendering to SVG, PDF and PS you should really check out cairo. 
It's a reasonably fast vector drawing library that can generate a whole 
set of outputs from the same code. See also http://www.cairographics.org.


And I have to disagree with the statement about bounding boxes and quad 
trees. Methods based on spatial accceleration structures (grids, 
BSP-tree, kD-tree, Quadtree, bounding volume hierarchies...) exist 
because they are way faster than the brute force tests that you are 
suggesting when it comes to intersection testing. They were invented 
specifically for problems very similar to yours. In your case I'd 
recommend that you search the web for some (maybe older) tutorials on 
fast pixel-perfect collision detection for 2d games. This is the exact 
problem that you're trying to solve here. A quick Google search turned 
up this tutorial, for example. On first glance it seems to be quite 
reasonable:


http://www.gamedev.net/page/resources/_/technical/game-programming/intelligent-2d-collision-and-pixel-perfect-precision-r3311

Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_New_Face() returns error

[Gregor Mückl]

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 and
FT_New_Face() is called successfully.


This looks like an issue outside of FreeType's control.  Since I don't
use Windows, I can't help.


Werner



Just on a hunch: have you asked your users whether they run an antivirus 
software and if so, could you ask them to test if the problem goes away 
when they disable the scanner temporarily?


Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

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

[Gregor Mückl]

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 much easier. With two sets of project files, you would also 
have twice the effort to keep them up to date in most cases.


Gregor

On 2013-10-22 11:16, Kenneth Miller wrote:

Yes, I used VS 2012 to make the changes.

Ok, it's your repository.

Well, I think that the separated win64 directory makes it obvious to
users who want to build for that platform what to do. I had to do all
this searching around, and if I were not so outgoing I may have just
suffered a lack of fuition and given up. That's not good, and leaving
the folder in there is less work than taking it out, and I think that
it's there strictly for helping other developers like me in the
future. I spent probably 2 hours looking around at the Makefile and
other files for building it I thought were pertinent to a mingw64
route to compile it, and went unsuccessfully down this path needing a
64 bit freetype.

And you're right. Those, and the specification of the compile results
directory, are the only changes that I've made.

Well I don't understand why. The win64 directory builds a correct
freetype lib file for 64 bit platforms. We're helping the users this
way. What is the final outcome? By the way, if you're wanting
verification that the win64 does build successfully by asking me to
test it, I had to build freetype as a dependency of a 64 bit project I
was compiling all night last night, so it definitely works.

 On Tuesday, October 22, 2013 3:21 AM, Werner LEMBERG 
wrote:


Ok, it's done. File is attached as 7zip file.


Thanks. Since this is a 15MByte archive, you won't see it on the
list.

Some observations while doing a diff between the archive and the git:

 o It seems that the vc2010 files can be used out of the box for
 Visual Studio 2012 and 2013 also, which would be good.

 o I will neither put the (extremely large) .sdf nor the .suo files
 into the git repository. According to info in the net, those
 files are regenerated as soon as you open the project files.

 o Do I need a special `win64' directory at all? It seems to me that
 your new project files simply add a 64bit option; there isn't any
 other change I can recognize. This would greatly simplify the
 whole issue.

 To test that, I ask you to start with a freshly unpacked FreeType
 archive, then overwrite the three files in `builds/win32' with the
 files from your `builds/win64'. Theoretically, this should be
 sufficient to see a 64bit build option.

Please comment.

 Werner


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

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

[Gregor Mückl]

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 either in 16.16 format or in font units.  Before the
fix this was true only if it was possible to quickly retrieve the
advance value, which is not the case for hinted TT fonts.  You
probably hadn't noticed that you circumvented the bug by using the
26.6 format, together with undoing the wrong double scaling,
right? :-)

The fix is rather simple (see below) if you want to stay with
computing everything in 26.6 format.


 Werner



Thank you very much for looking into this! The suggested fix works 
nicely. I vaguely recall that I was fiddling with this scaling when I 
originally wrote this code because it was behaving wrong in *some* way. 
But I must have been very tired to not figure out that something was 
amiss here :).


I looked at the documentation for FT_Get_Advance again. I'm using 
FT_LOAD_DEFAULT as flags, but the return value is in a 16.16 scaling. 
Yet, the documentation states:


"By default, the unhinted advance is returned in font units."

To me, this reads like a (probably unwanted) contradiction to the actual 
behaviour. I suggest something like the following instead:



"The returned advance depends on whether scaling is performed (based on 
the value of flags). If scaling is performed, the advance is in 16.16 
format. Otherwise, it is in font units."


Regards,
Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

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

[Gregor Mückl]

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 
glyph distances are at least double what they should be. None of the 
tested fonts give anything close to believable reasults. Linking against 
the old version of freetype without any further code changes fixes this 
issue.


I seem to get vastly different values for the horizontal advance. If I 
uncommend the if block around FT_HAS_KERNING in the code below, the 
result does not change noticably. This is the code I use to compute the 
horizontal layout of a string of glyphs:


typedef struct {
unsigned int glyph;
float posX;
float posY;
int lineNumber;
int font;
int size;
} TL_GlyphPosition;

void _TL_ActivateFontSize(int font, int size)
{
if(TL_Globals.fonts[font].currentSize==size) {
return;
}

FT_Set_Pixel_Sizes(TL_Globals.fonts[font].face,0,size);
TL_Globals.fonts[font].currentSize=size;

int height=TL_Globals.fonts[font].face->size->metrics.height;

if(heightsize->metrics.ascender+TL_Globals.fonts[font].face->size->metrics.descender)
 {
	 
height=TL_Globals.fonts[font].face->size->metrics.ascender+TL_Globals.fonts[font].face->size->metrics.descender;

}
TL_Globals.fonts[font].currentLineHeight=height;
}

int _TL_CalculateRunWidth(TL_GlyphPosition *glyphs, int length, bool 
firstInLine)

{
int width=0;
FT_Vector kerning;
FT_Fixed advance;
int i;

for(i=0;i	 
FT_Get_Advance(TL_Globals.fonts[glyphs[i].font].face,glyphs[i].glyph,FT_LOAD_DEFAULT,&advance);
	 
advance=(FT_Fixed)(64*advance/(float)TL_Globals.fonts[glyphs[i].font].face->size->metrics.x_scale);

width+=advance;

// check whether this is the first character in the string/line
if((i==0 && !firstInLine) || i!=0) {
			// respect proper kerning (if possible, i.e. both glyphs are from the 
same font and size)
			if(FT_HAS_KERNING(TL_Globals.fonts[glyphs[i].font].face) && 
glyphs[i-1].font==glyphs[i].font && glyphs[i-1].size==glyphs[i].size) {

// Note: glyphs[i-1] may point beyond start of 
passed glyphs array,
// but it's only a section of a larger string, so this unchecked i-1 
is fine
			 
FT_Get_Kerning(TL_Globals.fonts[glyphs[i].font].face,glyphs[i-1].glyph,glyphs[i].glyph,FT_KERNING_UNFITTED,&kerning);

width+=kerning.x;
}
}

}

return width;
}

Am I doing something obviously wrong in this snippet? Was there an 
interface change in freetype that I should be aware of?


Regards,
Gregor

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Right justification of text with glyphs reaching further than advance

[Gregor Mückl]

Hi!

I'm having a sort of conceptual problem: text that is right-aligned by 
my layout algorithm is overshooting the right boundary when rendered. 
This is bad because the last glyph in the line ends up getting visibly 
truncated there. All glyph dimensions used by this algorithm are 
provided by Freetype.


This problem seems to occur because of two conditions that are met:

1. using the advance of the last glyph in the line to compute the total 
line length and therefore implicitly the space between the 
second-to-last character and the right edge.


2. an italic font where the top parts of most glyphs reach further than 
the advance


So how would I find out the actual width of the character so that 
right-aligning it will never lead to truncation of the glyph?


My guess is that I need some sort of bounding box, but for some reason I 
cannot make FT_Glyph_Get_CBox return a non-zero bounding box. Is there 
some other way how I can obtain a control box or bounding box for a 
TrueType font at the current font size? Or do I need to use a different 
measure anyway?


Regards,
Gregor

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Get_Advance spuriously returns advance 0

[Gregor Mückl]

On Sat, 05 Nov 2011 19:32:05 +0100 (CET), Werner LEMBERG wrote:

I think I'm in need for some hints in order to track this one down.
Here's the problem: [...]


No idea what's causing this.  To help you, please provide a small
compilable sample to the list which exhibits the problem, and which I
can debug.  If you need a proprietary font to reproduce the error
please send it to me and not to the list.


Werner


Thanks for the offer. But I think I found the cause: I passed the 
FT_Font structure that the Layouter was using also to cairo for 
rendering. And rendering in cairo did in fact change something inside 
the font. Now I'm loading the font twice to get separate font structures 
and the problem is gone.


Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] FT_Get_Advance spuriously returns advance 0

[Gregor Mückl]

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 called again later 
on, it does return the correct value for the same character within the 
same string. When it happens, it happens multiple times for consecutive 
characters. Each time the text layout is regenerated, the font size is 
changed to the same value using FT_Set_Pixel_Sizes if required, before 
any calls to FT_Get_Advance are made. I am fairly confident that the 
font-related state that I can control is the same each time 
FT_Get_Advance is called.


Peculiarly, on each run of the program, the same glyphs are affected - 
on both platforms that I can test the program on: On Linux with Freetype 
2.4.6 and GCC 4.5 and with Visual Studio 2010 on Windows 7 (don't know 
the exact version of Freetype there ATM). Valgrind does not report 
anything serious, esp. no out of bounds memory accesses.


Do you have any ideas where I should start looking for the cause? 
Anything obivous that I might have missed? Comments and questions for 
more information are welcome :).


Regards,
Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype