Re: [ft-devel] Position Independent Port of FreeType2

[Mickey Gabel]

(I am out of office until Monday, so I might not be able to answer or fix
anything)

First of all, thank you for taking the time to look at the changes and
answer my questions.
I'll answer each point in turn (I hope this web based client doesn't mess
it up :)

Just a reminder, that our client needs to approve the PIC project if I am
to work on it, so don't expect additional patches from me just yet :)

-----Original Message-----
From: Werner LEMBERG <address@hidden>
To: address@hidden
Cc: address@hidden
Date: Fri, 23 Jan 2009 09:56:00 +0100 (CET)
Subject: Re: [ft-devel] Position Independent Port of FreeType2

>   . Please stay in the 78 column width limit.  At least one
>     C preprocessor doesn't like
> 
>        #define FOO( bar, \
>                     baz ) ...
> 
>     but this is a bug in this program, so we don't care.

So I should stay in 78 columns even thought there is a buggy preprocessor
that does like it, right?

> 
>   . I don't like having macros with parameters looking like a function
>     which can't be closed with a semicolon.  This is error prone.  I
>     always want this:
> 
>       FT_FOO(bar);
> 
>     So please add proper
> 
>       while ( 0 ) do { <macro body> }
> 
>     constructs where necessary.

I certainly don't mind, but it seems that the while trick would only work
with macros that are inside function bodies.
Most of the macros I made either define program level functions or structs.
While most of them look like a function, they definitely cannot be used as
functions.
When possible, I'll try to get the macros to behave as you want.

> 
>   . If possible, prepare a set of patches, together with proper
>     ChangeLog entries, which builds up your modifications step by
>     step.  This greatly simplifies understanding your changes.  Note,
>     however, that I don't want to force you to artificially reduce the
>     size of the patches.  The diffs should be rather logical than
>     small.

When (and if) our client approves this, I'll definitely submit the patches
in a much more orderly fashion.
This was more of a pilot test.

> 
>   . Is it possible (and useful) to move the large code chunk which
>     modifies ftinit.c to ftpic.c?
> 
> BTW, somewhere in the diff there is a typo `defualt'...

Thank you. They always creep up on me :)

> 
> > However, I can't figure out how to get there from the various
> > functions inside a module :( As you can see, autofit still stuffs
> > its own data into FT_LibraryRec, but this isn't very good.  Help?
> 
> Not yet, sorry.  I have a lot of other things to do.

Like I explained, no rush at all - this was a pilot/test case thing so
that you could see what I suggest, and so that I could tell our client how
much it would take.
We'll have time to figure it out when (and if) this project goes underway
from our side.

I feel that a general mechanism for this would be a boon, making it
possible for the various files comprising a module to store their data
directly, and the functions implementing them could access the module
easily. Possibly such infrastructure would also make other things easier.

> 
> > in ftrend1.c there appears to be a hack that checks a pointer
> > directly (instead of having two different functions for two
> > different classes).  I had to modify it to another hack (check the
> > number in the module's name.
> 
> Can you prepare a patch which fixes this issue?  This seems to be
> unrelated to your PIC changes.

In one sense this is related because the pic change made the original
pointers the hack uses unavailable.
The correct fix would be using different render functions for render1 and
render5, which would then do the relevant checks and then call the real
function. This would cost in one additional function call per glyph
rendering. My guess is that the original check was done to avoid this cost
(which is why even my PIC code uses a slightly different hack).

If the additional function call cost seems acceptable, I can submit such a
patch that separates to two different functions.
However this hack is really not very bad or hairy, as hacks go. It is easy
to figure out and not very likely to break. You could just as well leave
it there.

Which do you prefer? 

> 
> > 3) So far I have converted the basic module/renderer/driver
> interface,
> > and most of the autofit module.
> > I am not familiar with the insides of FT2, so can you sort of
> > guesstimate how much of the conversion work I already did? 1%? 2% ?
> > 5%? 10%? 20%?
> 
> Even more, I think.  Normally, the function tables which you have to
> modify are located at the end of a FreeType source code file, so you
> can look it up by yourself.

Indeed I had noticed that. 

There is an area of FT2 that I am totally unfamiliar with, and that is the
make / jam based build system.
So far I've been building my own custom version with the instructions in
INSTALL.ANY.
Do you think the PIC change would need special care to be "back ported"
into the make files? (For example I saw some module related definitions in
various .mk files.)
Another options is to declare that the PIC version of FT2 only "works" on
custom built versions, which are probably more likely to need PIC support
anyway.

> Do you have the possibility to work directly with the CVS code?  The
> main advantage would be that you could provide small patches right now
> which fixes inconsistencies of FreeType independently of your PIC
> changes.
> 
> 
>     Werner

I would be very happy to do so, but it's not likely.
My main project is a library on top of FT2 (the PIC thing is sort of an
unexpected detour), and so frequent updates to FT2 would cause extra work
for me, since it's hard to build on code that changes all the time.
There's the overheard of merging my own local changes to FT2 with each new
FT2 update.

Regarding PIC, if that comes to pass, that would be different since then I
would work directly with the source from CVS, putting our own modified
build on the side, until the PIC version for FT2 is done.

Mickey