On Mon, Feb 23, 2009 at 6:20 PM, David Turner wrote:
> An experimental git repository is now in place, see http://git.freetype.org
Woo!
> gitosis / git-daemon / gitweb are nice, but oh my, they are so badly
> documented that it's hard to avoid many pitfalls. I'll try to document them
> later.
Tad !
An experimental git repository is now in place, see http://git.freetype.org
Note that:
- this was created by taking a snapshot of the current CVS repository;
running git-cvsimport on it then 'git-filter-branch --msg-filter' with the
attached (basic) script to improve the comm
David Turner wrote:
> Hello everyone,
>
> long time no see :-)
>
> I'd like to know if Werner and others are interested in switching the
> FreeType repository to git in the near future ?
That would also make it easier for me to hack on FreeType (the only piece of
GNOME-based text rendering stack
On Mon, 2009-02-23 at 19:25 +0100, Werner LEMBERG wrote:
> Well, a direct import is trivial; however, it would be beneficial to
> walk over, say, the last 1000 to 2000 commits so that all get a nice
> one-line title.
My 'parsecvs' tool will probably handle freetype's CVS repository fairly
well. I
2009/2/23 Mike Moening
> In the 2.3.8 documentation it states that each thread should have its own
> FT_Library object.
>
> Currently we keep one FT_Library per FT_Face.
> We have a C++ wrapper object per font face which wraps these two together.
>
> We use FT_New_Memory_Face() to load the face
In the 2.3.8 documentation it states that each thread should have its
own FT_Library object.
Currently we keep one FT_Library per FT_Face.
We have a C++ wrapper object per font face which wraps these two
together.
We use FT_New_Memory_Face() to load the face into the object.
Because the font file
>From a purely personal point of view I welcome a move to git, simply to give
me an incentive to learn git :-)
Graham
-Original Message-
From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org
[mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On
Behalf Of
> the fact that we use "FreeType error code" means that we explicitely
> do not want to list a specific set of codes, or in other words that
> any error code could be returned.
I've already prepared some improvements w.r.t. the documentation of
error codes. This should be part of the repository
> long time no see :-)
Glad that you are still alive.
> I'd like to know if Werner and others are interested in switching the
> FreeType repository to git in the near future ?
Yes. I will do a new release soon (there are very embarrasing errors
w.r.t. FT_Get_Advance which I'l fixing right now)
On Mon, Feb 23, 2009 at 10:02 AM, David Turner wrote:
> I'd like to know if Werner and others are interested in switching the
> FreeType repository to git in the near future ?
Hi David! This would be nice for me as well.
> Nothing really of high priority, but I wanted at least to know your opin
Hello everyone,
long time no see :-)
I'd like to know if Werner and others are interested in switching the
FreeType repository to git in the near future ?
I've been a heavy user of the tool since several months, and while there are
really a few bat-shit insane user-interface
issues with it (even
Hi Mickey,
2009/1/22 Mickey Gabel
> Is there a standard/good way to get the module pointer (not the module
> class, I am talking about FT_ModuleRec that contains the module's data).
>
> Case in point:
>
> I am working on af_face_globals_new() in autofit/afglobals.c which is part
> of the autofi
Dear Le Tan Phu,
the fact that we use "FreeType error code" means that we explicitely do not
want to list a specific set of codes, or in other words that any error code
could be returned.
We do not want to fix the set of error codes because it may depend on the
implementation, which may evolve ov
13 matches
Mail list logo
