WARNING: While resolving call to function 'FTC_GNode_Compare'
arguments were dropped!
No idea what this is...
base/fttrigon.c: In function 'FT_Vector_Rotate':
base/fttrigon.c:439: warning: right shift count = width of type
base/fttrigon.c:440: warning: right shift count = width of type
base/fttrigon.c:439: warning: right shift count = width of type
I guess it can be related with LP64 issue. In my LP64 patch,
there was a modification of fttrigon.c aslike: [...]
- FT_Int32 half = 1L ( shift - 1 );
+ FT_Int32 half = (FT_Int32)1L ( shift - 1 );
vec-x = ( v.x + half
. 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
I'm designing my own program that uses freetype indirectly, through
another library that uses it. Does the clause in the BSD license
requiring me to mention that my program uses it apply in this type
of situation? Also, is there any other stipulations I need to meet
if all I'm doing is
Here is the first patch set including about 40 fragments.
Some comments.
. Please don't use tabs in the code.
. patch-03.diff contains changes to builds/atari/FREETYPE.PRJ --
this looks like an error.
. The first part of patch-05.diff should probably be sent to the
gzip guys
This is the second patch set including about 30 fragments
that are not included in previous patch set.
Everything is fine, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
In private communication, Greg Hitchcock from Microsoft gave some
interesting insights how Windows selects rendering modes, which I post
here (with permission). The main question was whether a font can
request ClearType rendering. Below is his answer. Note that Windows
provides three
This is the third (and final) patch set for LP64 platform,
including about 30 fragments.
And all those changes look fine.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
For reference, here the default gasp table values for GDI applications
under Win XP and Vista (again thanks to Greg Hitchcock) which get
applied if there is no gasp table in the font.
Regular and Italic Fonts:
8ppemGASP_DOGRAY
17ppemGASP_GRIDFIT
0x
During the development for AtariST, I found that there are 2 generic
implementations of zcalloc() zcfree() in zutil.c and ftgzip.c.
IIRC, the main idea was to leave the number of changes in zutil.c as
small as possible since it is an `external' file, and possible
re-synchronization with the
We have needed to add the string
DFKaiShu
to trick_names[] in tt_check_trickyness() in ttobjs.c for the
attached TTF extracted from a PDF.
Applied to the CVS. Thanks for the report.
Werner
___
Freetype-devel mailing list
We've been trying to resurrect the freetype bridge code in
ghostscript, and have been testing against the freetype 2.3.8 release.
I think there may be some bit rot in the incremental font support.
Indeed. After Graham has stopped to work on this, noone has
maintained this code; from time to
I'm sorry to say that there is no chance that I shall work on this
again. I have too much on my plate for the foreseeable future.
OK.
But I claim (as always ;-) that the parts of the bridge code I wrote
are relatively easy to follow and can probably be debugged by
single-stepping and
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),
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 in a
- 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
commit messages a bit.
(It's still not perfect, could be improved in the future)
Thanks.
/tmp/ccbUvm7g.s:760: Error: register or shift expression expected --
`orr r0,r3,lsl#16'
Already fixed in the CVS. Thanks for the report.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
It seems the problem came from a syntax error in the ARM assembly
language. But I could compile successfully freetype-2.3.8 for the
at4x0a version of the ARM processor, with this cross-compiler:
http://www.tomtom.com/gpl/toolchain_at4x0a_gcc-4.2.1_glibc-2.6-20080202.tar.bz2
Does it mean
Folks,
the `empty log message' problem in the conversion from CVS to git
still bites me. It is far more trickier than expected :-(
The steps I've suggested in a previous mail (using parsecvs, then `git
format-patch' `git am') works in principle. However, tags created
by parsecvs are lost.
I would have used an alternative approach if I had been informed
that adding a new field to the public structure was not permitted.
I also thought that it works without problems. Sigh. I *hate* ABI.
David B., any chance to provide a fix?
Werner
I have submitted a fix to the CVS repository (which wasn't too
trivial).
Thanks. I'll release a new FreeType version probably in a week or so.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Werner, if you are overworked, I'd like to prepare the release
myself.
I can afford time, fortunately, so please check whether everything is
in shape, and I'll do a release in a few days.
It seems that you have some spare time right now -- may I ask that you
walk over the open Savannah bug
the 'alphabet.ps' example file with ghostscript shows the problem
with the type1 loader's num_glyphs check. I'll see if I can reduce
the truetype test down to something simple.
I can reduce the original PDF file if required, just let me
know. Because we're using the incremental interface I
otaylor=Owen Taylor otay...@redhat.com
Peak=Pavel Kaňkovský p...@argo.troja.mff.cuni.cz
robert=Robert Wilhelm robert.wilh...@gmx.net
tetisoft=Detlef Würkner tetis...@apg.lahn.de
tomk=Tom Kacvinsky tom.kacvin...@3ds.com
werner=Werner Lemberg w...@gnu.org
wl=Werner Lemberg w...@gnu.org
# get-empty
two new versions.
Werner
# get-empty-logs git repository
#
# Written by Werner Lemberg w...@gnu.org.
#
# 08-March-2009
#
# Public domain.
#
#
# From the given repository, this script exctracts commit messages named
#
# *** empty message ***
#
# and stores them, together with the corresponding
I use Arial.ttf. I uploaded my test project. Please Check.
http://www.nabble.com/file/p22413476/GenfontData.rar
I slightly modified (and formatted) your program so that it runs
without errors using g++ -- in particular, g++ doesn't like jumps
which cross an initialization. I compiled with
I've been working on the PIC (Position Independent Code) port
recently discussed by Mickey Gabel. The work on the modules our
company uses is done, and everything seems to compile and run (both
the PIC and non-PIC versions).
Great!
Now I need some way of testing the library thoroughly to
[...] Another would be the one that I have ended up implementing by
adding two methods to the cid service interface (pardon my FT
vocabular -- I haven't spent more that one or two days in the source
by now). One method to tell me whether a given font really is a CID
keyed font, in the sense
I've included the diff below.
Thanks. Will check them soon.
One technical detail that I have been struggling with: It seems that
the CID API functions (until my change there was only one function in
the API) are not exported when using the Visual project on Windows.
Yes, it's missing,
I've just applied your patch. Thanks!
Another remark. Since the two new functions are in the CID service,
they will return a non-zero error value if the driver doesn't
support the CID service. This is a bit clumsy if one just wants to
know whether a given font in internally CID keyed or
FreeType 2.3.9 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/showfiles.php?group_id=3157
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the
A minor annoyance: Due to a bug in the docmaker tool which I've
introduced recently (to fix a different problem), many typedef links
and similar things are missing in the HTML reference of FreeType (the
documentation is complete, however). I'll try to fix this soon and
update the online
FreeType 2.3.9 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
The above gets mirrored now thus it takes some time until the files
are propagated; for the impatient, you can grab it also from
It seems to be caused by gcc option -mtune=i686 for libfreetype
compilation, without it ftview does not crash. In both cases I
combined it with -O2. I compiled freetype on slackware 12.2 (x86
linux, gcc 4.2.4). The backtrace of ftview is:
#0 0xb8062a0a in ftc_basic_family_load_bitmap
I have migrated the FreeType 2 repositories from CVS to git, using
Keith Packard's `cvsparse' tool and updating empty commit log messages
afterwards.
URLs for anonymous read-only access:
git clone git://git.sv.gnu.org/freetype/freetype2.git
git clone
Are you planning to modernise the tag names, now that you're not
constrained by the allowed CVS character set? E.g. '2.3.9' instead
of 'VER-2-3-9'.
I don't care. Any specific reason why you ask?
Werner
___
Freetype-devel mailing list
I did not changed ftoption.h but defined
CPPFLAGS=-DTT_CONFIG_OPTION_BYTECODE_INTERPRETER \
-DFT_CONFIG_OPTION_SUBPIXEL_RENDERING
before running configure.
OK.
freetype2 was configured with ./configure [...] CFLAGS=-O2
-mtune=i686. ftview was patched with ft2demos-2.3.6.diff
I got as far as writing a test harness that didn't used the direct
interface, but hadn't gotten around to writing enough of a font
parser to check the incremental interface. I may still work on it as
a learning experience.
Is there interest in having unit tests in freetype to detect this
* ftview crashes in cache module.
* the crash can be avoided by disable -O2 optimization
My platform is Debian GNU/Linux on x86 (Centrino Duo),
gcc is 4.2.3.
Ian also reported this problem for gcc 4.2.3. Please try a newer gcc
version, say, 4.3.2, which works for me without problems.
I'm working in my local master branch so I guess 'git rebase' is not
necessary.
OK.
Attached are first two patches that are not related to PIC. Please
tell me if the comments and git patches are ok.
I hope you don't mind my nit-picking w.r.t. formatting.
Subject: [PATCH 1/2] fixing
Continuing the nit-picking:
* src/cff/cffload.c, cffload.h, cffobjs.c, cffparse.c, cffparse.h
Routing library pointer all the way to cff_parser_run.
Please use complete file names relative to the top directory:
* src/cff/cffload.c, src/cff/cffload.h, src/cff/cffobjs.c,
src/cff/cffparse.c,
I recompiled freetype with gcc-4.3.3 and -O2 -mtune=i686. It does
not cause crashes of ftview.
Very good! It seems we can close this case.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Can you add some clarification to the ChangeLog of the first patch
that explain why it is needed ?
Regarding the second patch, [...]
David, these two patches are superseded by the suite of patches in
http://lists.gnu.org/archive/html/freetype-devel/2009-03/msg00095.html
Please comment
It would be nicer if you could keep the convention instead of
prepending an extra FT_Library parameter at the start of the
function. Indeed, you should instead store the FT_Library handle
into the CFF_Parser object and pass it to cff_parser_init, then
re-use it in subsequent functions.
Another major issue that I have with the code is that it is very
error-prone and very cumbersome to have these 1000 macros for
declaring and defining classes. I would really prefer if we could
use a simpler scheme that, gasps, relies on the C pre-processor, but
at least would make our life
Arranging a set of patches where each of them is a meaningful unit
of changes takes a lot of work. I'll do that again, but I hope
that's the last time I have to do that.
Please wait a bit! Let's first look what David is coming up with. Or
do you have an urgent need to add your stuff
if I have an embedded system equipped with a hw device doing
drawing, blitting and may be streching how can freetype benifit from
that? and if yes where to modify ?
The smooth rendering engine provides callbacks which you can use for
rendering. See `gray_spans' in the `FT_Raster_Params'
Hi, the glyph with index 26 'u' is not rendered correctly in ftview
using current git master.
Fixed in git, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
There is a new `name' table format 1:
http://www.microsoft.com/typography/otspec/name.htm
Any suggestions for a FreeType API to access the new data? Extending
FT_SfntName is no option, I think, since the new information must be
allocated (and freed by the user) -- this leads to memory leaks.
David wrote:
I would also prefer if you do *not* modify public header files (e.g.
ftimage.h), the corresponding declarations you want to add could
instead be placed in internal/ftobjs.h
Oran, in case this is still true, please fix it.
Werner
Arranging a set of patches where each of them is a meaningful unit
of changes takes a lot of work.
I'll do that again, but I hope that's the last time I have to do
that.
I've answered that already -- use your changes as-is, and apply
possible fixes on top of it (including possible fixes to
I've pushed the PIC changes into GIT (including moving the changes
from the public headers to ftobjs.h).
Congrats! It will take some time until I've reviewed it completely.
And thanks for your big efforts!
Btw, I've found a broken link in:
Btw, I've found a broken link in:
http://freetype.sourceforge.net/developer.html#anongit The link to
https://savannah.gnu.org/maintenance/UsingGit needs to be with http
and not https.
Oops! This is related to FreeType :-) Fixed, thanks.
[Interestingly, both http and https works for me
Now I had to revisit this problem (because we use Freetype, and it
can't open those files on Windows). I did the same approach: on
Windows, do not map ft_fopen directly to fopen(), instead map to a
function that first tries fopen(), and if that fails converts path
from UTF-8 into UTF-16 and
I wonder if the authors can relicense the otvalid code to the
HarfBuzz license (aka old-MIT). That is, remove the FreeType
advertisement clause.
I think we can give you permission to use the code from the `otvalid'
module with the HarfBuzz license (hoping to receive bug fixes :-), but
within
This a several blocks in the font cannot render correctly with
2.3.9.
FreeType seems to do the right thing. For example, applying t1disasm
gives the following for the fourth glyph:
/block {
0 708 hsbw
-9 -305 rmoveto
0 191 rlineto
726 0 rlineto
0
(1) You can't invoke freetype's configure script (top-level wrapper)
with an argument '--srcdir=wherever', because that isn't properly
adjusted when invoking the real configure script in builds/unix
(same for other configure arguments such as '--cache-file=' and
maybe more).
Since such
I've started doing PIC-related changes on my own branch, which I
just uploaded to the git server under the branch name
david-pic-changes for you to look.
For all people who are not that acquainted with git: To check out this
locally, please do
git checkout -b david-pic-changes
I found that the edge of the character was seem rough with some
blurr.
And the stem of the character seems strange.
There's nothing special except that the heuristic values chosen by
FT_GlyphSlot_Embolden are too strong, causing unavoidable artifacts.
Especially for such thin glyphs you
Wendy,
thanks for contacting us.
I'm contacting you because we've identified reliability issues with
freetype6.dll. [...]
I don't know who is responsible for this particular FreeType DLL (it's
not us, the core development team).
The issue here is that freetype6 is enumerating all the
Someone reported to me that some fonts, including uming.ttf crash
ftstring. The crash seems to happen in the FTC code and I'm not
familiar with that part of the code base. Anyone care to check?
The following crashers were reported:
/usr/share/fonts/chinese/TrueType/ukai.ttf
[please write plain-text emails and don't use HTML]
after FT_Render_Glyph() function (this function return error code 0)
m_pkFT_ChtFace-glyph.bitmap.rows and width are zero.
(1) Is that means my ttf file doesn't have this charcode 's bitmap ?
It's an empty glyph, like a space, yes.
(2) If
The attached patch modifies the value of --srcdir option. It adds
builds/unix/ to tell the location of the autoconf configure.
Other options are passed to builds/unix/configure transparently.
Great!
BTW, after short tests of this patch, I'm afraid that some make
files of FreeType2 are not
This is 2.3.9. I have a custom build that doesn't define
FT_CONFIG_OPTION_USE_ZLIB. Compilation fails because of missing
FT_Stream_OpenGzip() symbol from PCF_Face_Init.
Fixed, thanks.
Also, it would be good if release process included freetype
compilation with all possible permutations of
The check, then, is:
A proposed changeset is: [...]
Thanks a lot for carrying out the computations! Since we apply
rotation after hinting, I think this should be sufficient to get the
desired result. Can someone please do some tests to confirm this?
Werner
Sorry for an old issue to work with broken AtariST PureC
compiler. [...]
[...] I will propose an inclusion of small conversion tool in
builds/atari (and makefile to convert source files, that joins the
splitted lines of the first token in the cpp macro definition.
Great!
As an interim
A proposed changeset is: [...]
Applied, with small modifications. Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Savannah experienced a worst case crash:
http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html
Here the strength of git (and other modern DCVS systems) is
immediately obvious: I've just updated the repositories from my local
clones, so everything should be working again as
But the advance point Cyrillic A does not moved so its contour
exceeds glyph width. The similar issue occures with e and
Cyrillic e at 12 ppem.
I can't reproduce.
I can,
Strange.
but the references don't employ the use my metrics flag. Other
references to 'A' and 'e' seem all to
It seems that we never can completely match the Windows results :-(
Reason is probably that the Windows rasterizer and bytecode
interpreter uses floating point arithmetic AFAIK. Well...
I'm pretty certain they don't use floating point. On the other hand,
they probably use different bezier
I've recently discovered a fundamental problem with the B/W
rasterization of composite TrueType glyphs. Consider the attached
images. The first one shows glyph `R' at 15ppem from font pala.ttf.
The second one shows glyph `Rcaron', which is a composite of letter
`R' and the `caron' glyph. As
Hope this isn't too far afield from FreeType topic:
It seems that Just isn't listening. I suggest that you write to the
fonttools mailing list and/or contact Just directly at
j...@letterror.com.
Werner
___
Freetype-devel mailing list
Folks,
three years ago, Jens Claudius contributed various stuff to the Type 1
parser. Unfortunately, his email address is no longer valid, and I
haven't been able to find any usable information with a quick search
in the internet.
Is anybody here who knows him or his new email address?
both FT_New_Memory, and FT_New_Library (functions called within
FT_Init_FreeType) are allocating memory, before I have a chance of
setting the function pointers in FT_Memory.. To get around that I
added an extra argument to the FT_Init_FreeType, which allows me to
provide an FT_Memory
both FT_New_Memory, and FT_New_Library (functions called within
FT_Init_FreeType) are allocating memory, before I have a chance
of setting the function pointers in FT_Memory.. To get around
that I added an extra argument to the FT_Init_FreeType, which
allows me to provide an FT_Memory
I've just changed the parsing routines of Type 1 charstrings to use
16.16 format internally, and I'm going to fix both Type 1 and Type 2
handling to use 16.16 format externally too:
1. Add a new load flag so that outlines can be returned in 16.16
font units.
2. Round the coordinates
1) We have our own struct that contains both the ft library and an
FT_Memory object.
2) We initialize the fields in the FT_Memory object so that our
callbacks are called.
3) We call FT_New_Library and tell it to use our memory object.
This is the first FT2 API call.
//
I wonder whether this code from FT_Init_FreeType
(*alibrary)-version_major = FREETYPE_MAJOR;
(*alibrary)-version_minor = FREETYPE_MINOR;
(*alibrary)-version_patch = FREETYPE_PATCH;
should be moved to FT_New_Library to make FT_Library_Version more
generic.
I suppose that you don't
Just I've finished the translation from Perl to Python.
This is my first scripting by Python, so any comments to
improve/cleanup by experts are welcomed.
I don't care :-) It's only important that you get good results.
Thanks!
Please commit, after adding a header to the file which explains
Under current WATCOM setup, the command to be executed is
wcc386 -za \
-I=.\objs -I=.\builds\win32 -I=.\include \
-DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H=ftmodule.h \
-FO=.\objs\ftsyste.obj \
.\src\base\ftsyste.obj
If I execute it via MS-DOS command
I am new to this freetype stuffs. I am able to draw a shape using
outline, but I am unable to draw a simple line by using
FT_Stroker_BeginSubPath, FT_Stroker_LineTo and
FT_Stroker_EndSubPath. I really appreciate it if anyone has any
sample code and is willing to share with me.
It's not
Just I've committed src/tools/chktrcmp.py to GIT.
Thanks a lot!
BTW, docs/release still describes how to release with CVS repository
of Savannah. Although it is not for common users (so there's no
urgent request), it should be revised for GIT repository of
Savannah, in future.
Done.
Boris,
thanks for the font.
[...] these does not work (shows undefined character instead).
What exactly do you mean with `not work'? How do you access the font?
Unicode - correct CID - this is also in this CMAP
0xFA40 - 20317
0xFA20 - 20318
0x8B7F - 20319
0x5906 - 20320
0x609E -
Please see https://bugzilla.redhat.com/show_bug.cgi?id=513582
I've applied the patch. However, it breaks C++ compilation -- David
has told me that he tries to find a better fix.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Note that there seems to be a bug in either FreeType or in the demo
programs: I can't make ftview or ftstring display any bitmap
strikes. HiraMinProN-W3 doesn't contain any, but HiraMinPro-W3
does, for example. Will investigate soon.
My mistake. I've applied a local change which caused
I debug it and found problem that ftstring using gr_pixel_mode_gray
mode, but this mode is not correctly supported in grwin32.c [...]
Applied, thanks!
Also with make setup visualc. Make of ftdemos fails because there
are warnings and warning are treated as errors (/WX parameter in
Just I've merged my patch set to main trunk of git.
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Looks fine to me
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Just I've registered ttf2ttc on sourceforge.
Nice!
http://ttf2ttc.sourcforge.net/
This isn't (yet?) valid. Use
http://sourceforge.net/projects/ttf2ttc/
instead.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Please consider applying the attached documentation patch to clarify
this.
Applied, thanks.
Going further, what people think about making this part of the core
api as FT_Get_Face_Format()? Given the broader usage nowadays I
think that makes more sense than having it only in an optional
I would like to consult with you regarding cache subsystem. [...]
I'm not familiar with the cache subsystem, and David is usually very
busy and doesn't answer emails, sorry.
My advice: Check the source code of the `ftview' application which
uses the cache subsystem, and activate FreeType's
I find the freetype.dsp with 0A as newline, but Visual C++ 6.0
require 0D0A.
We know that, thanks.
So, when I download and uncompress freetype-2.3.9.tar.gz, open the
the freetype.dsw with Visual C++ 6, nothing is show, open the
freetype.dsp, one dialog show with warn: This makefile was not
I want add two values in 26.6 format
a in format 26.6
b in format 26.6
a+b=HOW?
Simply add them!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Before I write the letter 'porting problem: visual studio compile
problem', I download ft239.zip,and it's right for visual studio.
But gzip file is small the zip file, I prefer to gzip file when I
download open source project and it also apply to linux env.
I think why not provide the
I've just received this letter from Ken; you might be interesting in
reading it.
Werner
---BeginMessage---
Werner,
I would like to let you know that we just launched the CMap
Resources open source project at Adobe, which puts all of our CMap
resources under a more favorable open
This is kevin from sega of China, and we are currently working on a
project may need to use your freetype project, as for the
acknowledge notes, since there is some restriction with our publish
requirements, we would like to get rid of the web link
www.freetype.org and use the following
Can someone give me a simplistic description of what
af_latin_blue_chars, af_latin_metrics_init_blues(), etc, are for?
Please read this:
www.tug.org/TUGboat/Articles/tb24-3/lemberg.pdf
It's a bit out of date w.r.t. details, but the algorithm itself hasn't
really changed.
Werner
For the first time, Microsoft has published details how ClearType
*really* works -- the hints given in the OpenType specification are
far too vague.
This paper, written by Greg Hitchcock, is very instructing, and I
recommend reading it.
FreeType 2.3.11 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/showfiles.php?group_id=3157
The latter site also holds older versions of the FreeType library.
Version 2.3.10 broke PCF support. Only users who
Anyone know my last question about cff_op_dup?
Please give me some time to answer; I'm abroad and have a lot of other
things to do.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
601 - 700 of 3661 matches
Mail list logo
