No. This should be done one level higher since it needs contextual
string processing normally. Have a look at the Pango or ICU
libraries, or do it yourself!
As previous posts told, FreeType is font library and not text
renderer, it should not act as locale-aware softwares.
Well, for this
As fontconfig and xft already have the code to embolden and rely
on FT_GlyphSlot_Embolden to do the real job, I think
FT_GlyphSlot_Embolden should be made standard API. This is an
important feature for Chinese (maybe also Japanese and Korean)
users, as most Chinese fonts don't have a real
Considering there is such root of embolding request, I wonder
whether FT_GlyphSlot_Embolden() API is already enough for the
purpose. It does not receive much parameters to control embolding
(am I misunderstanding?). I'm afraid several control parameters are
requested in future, for
this looks nice! Can you change your patch slightly to put
ftmisc.h into the same directory as ftraster.c? Similarly,
`ftimage.h' should be expected in the same directory as ftraster.c
if _STANDALONE_ is active.
Sure
Applied, thanks.
Werner
I still get those two compiler warnings (from gcc):
In file included from src/sfnt/sfnt.c:26:
src/sfnt/sfdriver.c: In function `sfnt_get_interface':
src/sfnt/sfdriver.c:322: warning: ISO C forbids conversion of
function pointer to object pointer type
One more thing: I found it very hard to reconfigure freetype2 on
Unix, to use another compiler for example. When I rerun
./configure with another CFLAGS, I see it report the new compiler,
but when making, it's still using the old one. My humble solution
was checking out a fresh
Uh, oh, those two warnings are still there for your compiler? Then
your double-cast patch has no effect :-( I'm not able to verify that
because I don't get any warning with 3.3.3 with and without your
change.
No, double casting solves the error problem on C++, [...]
Hmm, it compiled
[...] you can see that the glyphs get fatter and fatter.
Thanks for testing. The attached patch should fix the problem.
Applied, .
(Changelog entry included. You may need to change the date.)
It's better to include the ChangeLog entry in the mail instead of the
patch. In case someone else
This is introduced by the last patch :(
Hehe, there still seem to be problems :-) The glyphs in the two
attached fonts don't change at all (neither the appearance nor the
advance width) if I check embolding with ftview (not using your
patch).
Werner
STARTFONT 2.1
COMMENT Anti-aliased test
This patch updates builds/unix/.cvsignore so that cvs up is more
silent now. Please apply.
Done, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Sounds good, but I think the name should be something more
specific, like FT_CONST for the least.
Yes, definitely.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Folks,
I've tagged 2.1.10 in the CVS, but I don't have quick internet access
until Sunday evening for uploading, so there are no packages yet.
Please stay patient!
There is other good news: FreeType's new home is
freetype.freedesktop.org
and right now we are in the process of mapping
We decide to make the development version public.
Great! Is it OK for you to put this into the FreeType CVS (in the
next week or so)? If you agree, can you provide proper patches to
create a new module?
Werner
___
Freetype-devel mailing list
[About incorrect argument prescan in MSVC's preprocessor for C which
prevents correct compilation of FreeType's `otvalid' module.]
This is a known bug.
Aah, thanks.
If you have further questions regarding this issue, Jason Shirk can
help you out.
Jason, I'm interested in the history of
I notice that the FT_REALLOC_ARRAY #define in
freetype-2.1.10/include/ freetype/internal/ftmemory.h takes
_pointer_ as an argument, but uses _pointer (without the last
underscore) in it's definition. I'm pretty sure that this is a bug
and breaks the latest Pango build. (Sorry if this has
The function declaration for FT_Outline_Embolden in ftoutln.h is
using the wrong export macro.
Fixed in the CVS, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Why FT_VALIDATE_BASE is started from 0x0100?
It seems that 0xFF is reserved.
It was just convenience -- a new series of information which has a
different function.
I guessed this 0xFF is reserved for passing the validation level.
Using this reserved area, it is easy to pass a validation
The dsp- or dsw-file for Visual Studio is not usable.(downloaded
version 2.1.11) But you have written it.
I'm depending on volunteers since I don't use Windows. Please have a
look at the FreeType Wiki at
http://freetype.freedesktop.org/wiki
which gives some help how to create a Windows
My test of the freetype module showed that I could cause a crash by
loading any -iso10646-1 ttf font I tried; but using an eight bit
encoding never caused a crash. I didn't try any other sixteen bit
encodings (such as legacy CJK encodings) and I didn't try otf or
type1 fonts in that test.
For me xorg 6.8.2 crashes with freetype-2.1.10 when I try to run
xterm -font -monotype-courier
new-medium-r-normal--20-0-0-0-m-0-koi8-r
Yes, I can finally(?) crash my x-server with this as well.
Can you produce a backtrace?
Werner
___
Leaving aside the question of soname and binary compatibility, I was
surprised to see in CVS the change to FT_Outline_MoveToFunc and
friends; from the CVS commit message: [...]
Such a change means that a project like Cairo either has to:
A) Choose to compile *only* with 2.2.0 or newer
Is there any sort of consortium, conference, or gathering of any
kind for FreeType users or developers?
Not really.
Has there ever been?
Some developers met twice a few years ago (once in Aachen and another
time in Amsterdam) -- to have a nice afternoon with talking and a
dinner.
I am greenhorn in FreeType implementation to my software
aplications. I followed your instruction in Tutorial and wrote a
simple program in C++Builder (Client/Server). I included all your
libraries and compiled the necessary source files (*.c and *.h) for
truetype fonts. My program should
The email adress [EMAIL PROTECTED] doesn't exist anymore!
Yes, we know :-( Hopefully, this is fixed in the near future.
1.)The structure FT_Resource and the function
FT_New_Resource(engine, filename, resource) doesn't exist too or
have I overlooked it? There was nothing in the API
This seems to be the right forum for this problem. Sorry for double
posting.
Werner
---BeginMessage---
We have 3 fonts that cause an illegal access violation in
t1_builder_close_contour (Adobe Jenson MM Italic Expert, Kepler
MM Expert, and Kepler MM Ornaments 1). [...]
Has anyone
This patch does the changes (avoiding unnecessary array copying) I
mentioned in the last post, along with a heavy cleanup of the
truetype module.
I just skimmed it, and it looks fine.
Since the only good thing of the cleanup is to make the code more
readible and it risks unstablizing the
I thought heavily clean up implies some changes are not
listed :)
This is a lame excuse :-) Seriously, your clean-ups are still
comprehendable -- it's more a code shifting than a complete rewrite,
isn't it?
Werner
___
Freetype-devel mailing
ft_validator_run is defined but it not used in otvmod.c.
My patch shrinks otvmod.c 20 bytes:-P
Applied, thanks. Sorry for the delay.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
It seems that FreeType2 cannot load some bitmap-only fonts on MacOS
X (possibly on Classic MacOS too), because such fonts have no hhea
tables in its sfnt resource. I wrote small patch to bypass the
problem [...]
Applied, thanks. Sorry for the delay.
Werner
Sorry for the late reply.
Hi, after having a look at cff source code and primaryly the comment
at
cffgload.h: /*bbox :: Unused. */
The bbox field in this particular structure is no longer used. CFF
fonts of course have a bbox array.
it seems that bbox is not
P.S. After moving the FreeType2 cvs repository to
savannah(subversions?).gnu.org, I may lose my write-access to it.
I'm happy if you give mpsuzuki instead of me to write-access for
gxvalid merging tasks.
Toshiya-san, Masatake-san,
thanks a lot for your work! I've given both of you write
I will rewrite with GX. How do you think about?
This is fine with me.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
While playing font rendering, and trying to figure out while scaling
some truetype fonts ends up with the bottom horizontal line of E, L,
2 etc is missing. (75dpi, freetype used as an X server renderer,
running on Solaris, so using the Sun provided CourierNew.tff.)
[...]
I think that
FreeType's autofitter has been designed for AA mode only,
Werner, that's not true. The auto-fitter should be able to handle
non-AA modes appropriately.
Oh, thanks for the correction.
If the lines disappear, there is some bug somewhere.
The patch suggested by Chris fixes this problem.
For whatever reason, the makefile doesn't realize it's got a 'unixy'
environment. Any guesses what's wrong?
I think you have to use the Unix shell, not the DOS shell, but this is
just an educated guess. Please report again, sending the compressed
output of `make -R -r -d', if noone can give
The generated freetype2.pc file lists ${includedir}/freetype2 but
not ${includedir} which causes code to fail to find ft2build.h if
freetype is installed in a non-standard directory. freetype-config,
on the other hand, gets this right. Trivial patch attached.
Applied, thanks.
Werner
I seem to remember talk about testing FreeType on randomly corrupted
fonts; has any work on this been done?
AFAIK, George has started with some work. For my part, I've done
nothing, alas.
Werner
___
Freetype-devel mailing list
I have a little program which
makes a copy of a font file
changes a random byte to a random value (optionally more than 1)
passes the result to fontforge and makes sure ff can handle
it without crashing.
BTW, this file is now part of the FontForge CVS.
#define TT_MAX_COMPOSITE_RECURSE 5
This value is used to specify the maximum depth allowed to which
composite glyphs may be nested.
But the truetype spec does talk about this, it's a field in maxp
maxComponentDepth. So I suggest the following patch:
Applied, thanks.
Werner
This patch is causing a regression when trying to use Bitstream
Vera Sans 10 = all glyphs with accentuated letters (like à é ù )
are not longer displayed :(
Hmm. It works on my system. Did I send the wrong patch?
It's my fault I think since I applied it manually.
Anyway. Line 1215 of
Another reason to move away from the old Font Manager and to ATS, is
that some of the Font Manager stuff will not carry over to Mac OS X
on Intel without extra work, [...]
Any volunteers? Neither David nor I use a Mac...
Werner
___
Another reason to move away from the old Font Manager and to ATS,
is that some of the Font Manager stuff will not carry over to Mac
OS X on Intel without extra work, [...]
Any volunteers? Neither David nor I use a Mac...
I want to do.
Great! And thanks in advance for your support.
In a header file include/freetype/ftrender.h ,
typedef void
(*FT_Glyph_TransformFunc)( FT_Glyphglyph,
FT_Matrix* matrix,
FT_Vector* delta )
But in a source file src/base/ftglyph.c ,
FT_CALLBACK_DEF( void )
[Stefan reports that the macro FT_HAS_KERNING always returns 0.]
This is definitely a bug. We have the following in sfobjs.c, function
sfnt_load_face:
#if 0
/* kerning available ? */
if ( TT_FACE_HAS_KERNING( face ) )
flags |= FT_FACE_FLAG_KERNING;
#endif
It
[I've translated and forwarded Stefan's email to this list -- I'm no
expert for this topic, so I hope for a competent answer by somebody
else.]
In embedded systems which aren't booted often it would make sense to
use a static memory management, avoiding an increasing fragmentation
of the memory.
Let me ask a question, which is better solution?
Fix A:
FT_GetFile_From_Mac_Name() is kept for QuickDraw.
Add FT_GetFile_From_ATS_Name() for ATS.
To avoid XXX is deprecated warning,
FT_GetFile_From_Mac_Name() should be excluded in building.
Fix B:
Change
max_bytes corresponds to the maximum amount of memory you want to
dedicate to the cache nodes, it doesn't need to correspond to the
total memory available on your system; it's used to prevent the
cache from inflating to vexing levels.
note that it does NOT account for managed FT_Face and
the FreeType API defines several FT_LOAD_TARGET_XXX constants that
determine which hinting algorithm to use when loading outlines
from a font file:
FT_LOAD_TARGET_NORMAL = hint for normal anti-aliased rendering
FT_LOAD_TARGET_LIGHT = same as above, but hint less !
- the demo code didn't really select the hinting algorithm
correctly, I've corrected it in the CVS to match libXft's
behaviour
Hmm, no ChangeLog entry. Will you do that?
- there was a bug in the auto-fitter, [...] Fixed in CVS this
morning before going to work.
No, you didn't.
You mean that all registers and operators are based on 8bit entities?
yes all registers and operators are 8bit.
Hmm, I think there must be at least some 16bit entities for jumps and
similar things, right?
i don't want to have support for all fonts but if i can compile it
for a single font
I will appreciate, if someone can give pointers to Load
(FT_LOAD_XXX) and Render(FT_RENDER_XXX) flags to be used in
ver. 2.1.10.
Specifically for following scenarios:
-Antialiasing (ON), Hinting(ON)
FT_LOAD_TARGET
-Antialiasing (ON), Hinting(OFF)
FT_LOAD_TARGET_NORMAL
It also means having a non-MS signing tool. Has anyone actually
managed to independently verify or sign a font. I've tried and
failed at the most fundamental level of trying to get my md5 hash of
a font agree with MSs.
IIRC, there was something into this direction on the opentype mailing
- Do you have any idea how far out 2.2 still is ?
It's still far away because I currently have limited time to work on.
- Will 2.2 be libfreetype.so.7 ?
Yes. At least this is my opinion.
- Do you still plan to break source compat by doing const
correctness changes ?
I would like
There are some functions which are wrappers to services. Then why
not simply export the services to clients?
Please give an example how you would like to rearrange services.
To make finding a service faster, we can use integers as service id,
instead of strings.
Do you really think that
On Fri, Oct 14, 2005 at 10:11:21PM +0200, David Turner wrote:
David, I've added your address to the freetype-devel list (without
receiving mails).
An exported service is like an exported function call, once get
exported, it allows no change.
May I suggest that we postpone this discussion and
I did find some discrepancies:
ftsysmem.h doesn't put the function name on the the following line
for ft_memory_new and ft_memory_destroy,
This file, together with ftsysio.h, is obsolete; I've just removed
both.
cache/ftccmap.h uses a mixed format in FTC_CMapCache_New and
A haphazard Workaround for such issue (which replace comp by
compo) is acceptable?
In case this should be really necessary (see my other mail) I ask you
to find a variable name which is `more natural', perhaps `Comp' or
`component'.
werner
I would like to load a font , get it's glyph outline and then render
it as a path so that I can fill the glyph with custom stuff such as
gradients and patterns.I have seen examples of this for free Type
and true Type in win32.
This has been answered on comp.fonts.
I wish to know if this is
If you call FT_New_Face with face_index 0, it should return an
empty FT_Face object to indicate that the format is supported
(otherwise, an error is returned). Moreover, the face-num_faces
field can be used to determine the number of faces within the font
file. After that, the caller
This might be interesting for some of you. It means in consequence
that the higher-level code which handles GPOS has probably to discard
the kern values FreeType returns (which only looks at the `kern'
table).
Werner
---BeginMessage---
OpenType list address: [EMAIL PROTECTED]
Thomas
Attached. It includes the change I suggested and copies the same
description to FT_New_Face() and FT_New_Memory_Face().
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
And I think there should be more change in this code section:
'limit' should be reset by 'buffer + readsize' in where readsize is
actual read size.
Please provide a patch.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
David,
a comparison between a FreeType checkout with -D 2005-10-28 and -D
2005-10-29 shows that the latter has introduced a serious bug
w.r.t. TTF handling. Attached two images from the font Dustismo.ttf.
Perhaps your arithmetic performance improvents are buggy...
This might also be the
I just commited a fix to the problem. There was a bug in
ft_trigon_prenorm. the optimization introduced recently
Also included, a fix to the truetype interpreter FT_UNUSED_EXEC
unwanted memcpy
Thanks for the quick fix. Will test soon.
Werner
I've included a patch for a bug in FreeType related to zero values
for vertical metrics for OpenType CFF fonts.
Thanks! I've applied a simplified version to the CVS. Sorry for the
long delay.
My assumption is that the FreeType team didn't have time to
implement this yet.
Mhmm, I think it
In otvalid, documents say `free' should be used.
I see. The usage of FT_ALLOC() and FT_FREE() is very same between
otvalid and gxvalid. Yet I'm not sure the reason why free() should
be used for tools using otvalid,
You should use free() in ftvalid.c because FT_FREE() is not a public
API.
I attached 4 patches, please check.
Thanks a lot!
I wrote FT_TrueTypeGX_Free() to receive FT_Face (to identify the
memory object) and FT_Bytes to free, but it is possible to receive
FT_Memory instead of FT_Face. Any recommendation?
Since most functions of FreeType take FT_Face, I think
I attached 4 patches, please check.
And please install!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
For systems that dont support dlopen() and only support static
linking, the Amiga build can be used as example.
The forthcoming libtool version fixes bugs of libltdl on static
platforms. I would be glad if you could test whether libltdl (not
necessarily the libtool script itself) runs under
The attached patch fixes a memory leak in bdfdrivr.c.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
--- freetype.h2005-08-15 16:05:44.0 -0400
+++ freetype_1.h 2005-11-21 15:49:16.0 -0500
@@ -1875,7 +1875,9 @@
const FT_Byte* file_base,
FT_Long file_size,
FT_Long face_index,
-
In attached screenshot you can easily see that at 16 pixel bold, W
N characters are too bold compared to other characters. I can see
this behaviour in Freetype 2.1.10 and Freetype CVS HEAD.
Hmm, I can't see this with ftview from CVS 2005-11-25 (using
verdanab.ttf 2.35).
Werner
The problem I mentioned in the last mail is solved by replacing the
bool `cmap-unsorted' by `cmap-flags.' So here is the patch.
Both patches look good! Please add them to the CVS. I'll then run my
suite of bad and problematic fonts...
Werner
I've commit a patch to make ftdump support -c, show charmap
contents. With that, and the simple script `cmaptest' which can be
found in the attachment, you can easily test if things still work
correctly.
I've replaced `-c' with a switch `-v' to indicate verbosity.
ftdump now always shows
Both patches look good! Please add them to the CVS. I'll then
run my suite of bad and problematic fonts...
Ok, I've committed.
Thanks!
There is one difference in format 4, in how charcode 0 is mapped
when offset is 0. In my code and the original `tt_cmap4_char_next',
`delta' is
In the regression test, I've found that FT_New_Face() in ftmac.c
does not return correct aface-num_faces. [...]
...So, now I'm going to fix this, and I want to ask about binary
compatibility. At present, via FT_New_Face() in ftmac.c, we can
access the 2nd sfnt resource as the 2nd face of
NFNT resources are separated for each sizes, just aslike strike of
sbit. Could I know more about WINFNT encoding issue in ft-devel
archive?
As soon as there is an encoding difference you have to use faces.
Werner
___
Freetype-devel mailing
A little bit late but here's the fix without touching
FT_New_Meory_Face.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
How do you come to this conclusion? The original BDF
specification (found in the X11 distribution) says that both
FONT_ASCENT and FONT_DESCENT are *logical* values. They don't
guarantee that all bitmap glyphs are within this range.
Still, then we should set y_scale to 8 /
* How about header files?
The header files are separated completely? Or, the shareable
headers are installed in /usr/include and other arch-dependent
headers are separated in other directories? Or, system has only
headers for most-suitable architechture?
As far as I've seen,
I cannot verify that the file was indeed created by PDF-XChange,
though that seems likely. Nor can I verify that PDF-XChange
produced the incorrect font-subset.
Maybe this user can give more details: Perhaps he or she is able to
repeat the whole process so that it can be checked what's
To sum up, I think freetype should not round global font metrics
(nor glyph metrics) and let clients decide how to deal with them,
despite that clients are able to get the unrounded values by
scaling themselves.
As the effect is large (all apps using Xft), I need your opinions.
If
WARNING: INSTALLING THE CURRENT CVS WILL PROBABLY BREAK YOUR SYSTEM
What do you mean? The rendering results?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Here's revised version of dual-ABI patch which
generates unified ftconfig.h for 64/32bit UNIX
platforms.
This looks very promising! Thanks for your hard work.
AC_ARG_ENABLE([multi-abi],
[...]
Please put all this stuff into one or more separate files (similar to
ft-munmap.m4) to make it
Problem solved. I replaced the official binary libraries with mingw
compiled libraries I found at http://oss.netfarm.it/mplayer-win32.php
which was a lot easier than compiling freetype myself because I'm
using VPC and it's slow. I'm guessing that maybe the official binary
was compiled with
Just I've searched documents in libtool-1.5.22 2.1a, and libtool
mail list archive. In the latest CVS snapshot (2.1a), still multilib
support is written as future issue.
OK.
Anyway, I will ask future plan and advise to libtool list, but I
think my patch is sufficient for urgent fix until
The cvs instructions at
http://freetype.org/developer.html#anoncvs are out of date [...]
Fixed too, thanks.
I'd change the text to remove any mention of ssh and CVS_RSH since
that's no longer required. ie remove the '(SSH required!)' in the
title, change the CVS+SSH to just CVS and
Before posting jumbo patch for ftmac.c to fix deprecated FileManager
FontManager API issue, here is a dirty new year gift: small tool
for regression-test of MacOS specific APIs.
What about adding this to the CVS? Probably not building it by
default, but for reference.
Werner
What about adding this to the CVS? Probably not building it by
default, but for reference.
Thank you! I will add ftoldmac.c (any better name?) to
ft2demos/mac/, and write ft2demos/mac/Makefile (for MacOS X) to
build ftoldmac in the directory. I've already finished MPW makefile
for m68k
Folks,
I've now fixed Savannah bug #15056: In synthetic Unicode mappings
based on the AGL, base glyphs are now preferred over variant glyphs if
both are available.
At the same time I've replaced the cmap code in psaux/t1cmap.c with
the pscmap service, thus reducing the library size slightly.
I want to know when does the next version (ver 2.2.0?)
of freetype release?
Hopefully within a month or so.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Will it be released with FT_OPTIMIZE_MEMORY defined?
Yes, d.e.f.i.n.i.t.e.l.y !!
So maybe it's time to switch that on in the CVS...
More information at:
http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
http://turnerdavid.neuf.fr/freetype/rogue-patches.html
I'll
Chia-Yi,
can you make the AFM parser optional, to be controlled by a
configuration macro in ftconfig.h? Given that Type 1 fonts are
vanishing I can imagine that some users in the embedded market only
want to have, say, CFF support...
Werner
Have a look at
http://freetype.org/freetype2/freetype-2.2.0.html
which discusses some important issues with the forthcoming 2.2.0
release.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
[discussion continued on freetype-devel only]
A new version which makes such a radical change should bump up the
shared object version (.so.N).
Where's the `radical change'?
That way we'll allow a transition period for applications to update.
This has been discussed recently on the
And will the major .so version be bumpped up?
Nope, because this would create problems as Owen Taylor pointed out,
since through indirect linking, a given program might find itself
dependent on both libfreetype6 and libfreetype7, which could cause
major problems depending on the code paths
I *think* fontconfig 2.3.93 doesn't use the internals
anymore... well, that's what the changelog for the release claims;
perhaps this could be noted on the patches page.
Added, thanks. Can someone verify this claim, please?
Werner
___
OK. I bit the bullet and rebuild freetype and fontconfig... yes, it
does look like fontconfig-2.3.93 will compile against freetyle sans
internal headers.
Thanks a lot for the verification!
Werner
___
Freetype-devel mailing list
Steve,
I've read your very interesting mail at
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
What's your recommendation in the light of
http://freetype.org/freetype2/freetype-2.2.0.html
?
Werner
___
Freetype-devel
Perhaps we shall *rename* the library to, say, `libft2', instead of
`libfreetype', together with a new API prefix `FT2_' instead of `FT_'.
This would avoid the whole mess.
Or even `libft3' and `FT3_' ...
Werner
___
Freetype-devel mailing
1 - 100 of 3661 matches
Mail list logo
