Attachment is my code for add italic render mode to ftview.c, hope
it can help you.
Applied with slight cosmetic modifications. Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
As the comments in ft_grays.c:
- It can easily be modified to render to _any_ number of gray levels
cheaply.
But the source code looks like hard-coded. Could you give me some
tips for modifying the gray level?
Look for `coverage' (in gray_hline) and PIXEL_BITS. Again, a patch
which
This is the fuction FTDemo_Update_Current_Flags() in ftcommon.c:
[...]
It does not update the handle-low_prec! How so?
Well, handling low_prec is completely missing currently -- I assume
this glitch happened during WU Chia-I's redesign of the demo programs,
and nobody has noticed. Can you
Sorry for the late reply.
[...] what I have done is essential for the platform I am working
on, and may well be essential for other low-RAM devices. In my
current work we can use large TrueType fonts (~2BM Japanese fonts,
for example) successfully with my changes; we cannot use them
from a TrueType font I use a technic
that is much like lilypond uses (thanks for the pointer Werner
Lemberg). Which is the kind of solutions I am looking for.
But as you've seen, there's a lot of additional coding. We are not
going to integrate such stuff into the library.
One was reading out
For ftface-charmaps[1]
encoding=0(!!) platform=1 encoding_id=1 (iterating using
FT_Get_First/Next_Char yeilds 8589 chars).
Hmm, PID/EID 1,1 is Japanese on a Mac, so FreeType is correct in
saying that encoding = FT_ENCODING_NONE because it doesn't contain
mapping tables.
This font works with
[Please stay on the list.]
The issue has been resolved on my end, but for your own information
ftmac.c (amongst other things) will load various resource based font
data and massage the data into a linear representation that
resembles the on-disk format of a Windows TrueType/Type1 font. That
Hmm. If so many fonts are broken, it's probably worth to add a
hack to FreeType's cmap support so that they can be successfully
handled. What do you think? Can you investigate?
Yes, of course. Now I'm investigating the problem.
Thanks.
I guess there might be existing hacks for Dynalab
Now, src/base/ftbase.c includes ftmac.c by
#include ftmac.c
syntax.
This looks like an error, indeed: All other files (except ft2build.h)
are included with double quotes.
For such softwares, the simple inclusion by is easier because it
searches the current directory implicitly.
Just I've found the scenario how FreeType2 recognizes Dynalab cmap
format2 subtable (used as SJIS cmap). Here is brief report. [...]
Thanks! Go ahead, please.
By the way, at present, Dynalab fonts for MacOS has Apple SJIS cmap
but lacks Microsoft SJIS cmap (thus, ftview cannot specify
I encounter same issue as you described here. I can't get ftview
work when I use VC compiled it. (MinGW correctly.) return infomation
is: could not allocate display surface.
Patches welcome! I don't use Windows, so I can't be of any help here.
Werner
I get the answer, but it isn't a bug in the codes.
Just because of lack of a compiler preprocessor definition with VC.
The preprocessor definition is DEVICE_WIN32.
Where shall this be defined? Otherwise, should this be mentioned
somewhere in the docs?
Werner
That's right. Just add the preprocessor definition DEVICE_WIN32 to
the project.
Thanks for the information.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
While debugging a bug for the gd's extension in php (crafted ttf
makes it crash), I was wondering if it is expected to have a NULL
face-font_family or if there is a function to fetch it instead of
accessing the face member directly. Is it always nullified if no
font family has been found or
So, I take it you would advise that the corresponding metric files
should be in the same folder as the glyph files?
No, there's no reason for that. It really depends on the application
where it searches the files.
Am I right to assume the links are:
PFB -- PFM
and
PFA -- AFM
No. PFM is
PBA,PBF - AFM
Are those new types or typos?
Typos, sorry.
[In the following, I assume that you want to get metrics, right?]
So, to clarify, you advise that:
1. If I find a PFB file without an AFM, just use the PFB (i.e. link
into ~/.fonts).
2. If I find a PFB with a partner AFM
What is considered a font, right now, is based entirely on the
extension of the filename. .ttf,.otf,.ttc,.pfb with .pfa
in the works.
On Unix boxes, this is a bad idea. The `classical' way to find out
the contents of a file is to use the `file' program which compares the
(beginning of the)
I was also referring to the FT_Face documentation. A little note to
say that this member can be NULL and should be tested before being
used.
I did so right now.
Is the API docs generated from the comments in the source?
Yes.
Werner
___
Yet I'm not sure the target application that Fonty Python
manages the fonts for, but considering the fontconfig's
limitation, I think the first group for FP would be the
font files with Unicode interfaces and outline (not bitmap-
only) fonts. So CFF OpenType would be the first candidate.
Last year I set up this site that shows how to have sharp fonts on
Linux: www.sharpfonts.com
Aah, I wasn't aware of this.
Since then, I have had several messages from people reporting minor
font rendering issues. I think these reports may help the Freetype
project to improve the font
it's always best to check the bugs database on savannah.gnu.org
(and add an entry for a new bug).
Thanks Werner. I didn't see any bug-related information on this
page. Is this really the web site to report bugs?
https://savannah.nongnu.org/bugs/?group=freetype
Well, FreeType is just a
Could you tell me how to find out the version of a specific font,
such as Tahoma? BTW, I only use TTFs.
I load the font into FontForge and look at the font info.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I am involved in the porting of several applications to IBM AIX 5.3
and was wondering if there are any known issues with AIX 5.3 and
FreeType 2.3.4 or 2.3.5.
I can't remember that someone reported explicit problems. Why are you
asking?
Werner
Thanks for the report. Can you provide patches which I can apply
directly?
Sure, here's a try.
Applied, thanks.
Not sure if there's tag to link between sections.
No, it isn't, and I'm too lazy to implement this :-)
Werner
___
Sorry for the late reply.
The error appears to be coming from the substitution of \ for / in
these lines:
ifneq ($(findstring $(PLATFORM),dos win32 win16 os2),)
OPEN_MODULE := @echo$(space)
CLOSE_MODULE := $(subst /,\,$(FTMODULE_H))
REMOVE_MODULE := @-$(DELETE) $(subst
I didn't got ftjam working + the support for ftjam seems to be very
small
Yes, David doesn't have time to do something here. I've been tempted
to write support for SCons (www.scons.org), however there are so many
other things that I shall do that I dropped the idea very quickly
again. :-(
Why isn't a Type42 font handled internally the same as a TrueType?
Put the other way: why can't the Type42 font handler extract the
sfnt array from the Type42 font file, and hand it over to TrueType
handler?
How did you get the impression that we are doing something different?
In function
Is there any harm in making the following change in TT_Load_Glyph()
Replace
if ( ( face-header.Flags 2 ) == 0 loader.pp1.x )
FT_Outline_Translate( glyph-outline, -loader.pp1.x, 0 );
with
if ( loader.pp1.x )
FT_Outline_Translate( glyph-outline, -loader.pp1.x, 0
To make decision simplier? :-), we (at gmc.net) choosen to ignore
that flag.
Hmm. What's the Windows behaviour? I don't insist on obeying this
flag if the heuristic behaviour can be improved...
Werner
___
Freetype-devel mailing list
I have a TrueType font with a problem which prevents FreeType from
reading its cmap. [...]
Is this a sensible way to proceed, or is it likely to break other
things?
The main question is whether it is essential to handle this particular
font. For me it's questionable to patch FreeType just
However FreeType crashed when I called FT_Face_GetCharsOfVariant.
After some investigations, I found some bugs in ttcmap.c. I'll
attach a patch to fix the problem.
Applied. Thanks a lot!
Werner
___
Freetype-devel mailing list
Thanks for your detailed analysis!
I have a question to FreeType2 developers users on Mac OS X:
should I apply this patch?
Since I'm not a Mac user, I don't have a specific opinion. I trust in
you -- please go ahead as you think it's best.
Werner
The rasterizer I should benchmark against for anti-aliased
renderings is ftgrays?
Yes.
From what I can read in that code there is no hinting done in this?
No. This is done separately.
And there is no performance decrease in setting the STANDALONE flag,
right?
Not as far as I know.
And
How can i add a new font driver to freetpe.?
What do you want to do?
is there any licensing issues regarding that...?
If you use the GNU license, you have to put your driver under the GNU
license too. If you use the FreeType license, this is not necessary.
Werner
The attachment(F10.ttf) is a font that I draw-out from a PDF.
And the FreeType 2.3.5 cannot deal with it correctly. So I had try
the version 2.0.9 and 2.1.10.
I found that the 2.0.9 is right, and the 2.1.10 is wrong.
Please check it whether it is a bug or not.
The font is fine I
BTW, I plan to add a new flag value, FT_FACE_FLAG_CID_KEYED
(together with an FT_IS_CID_KEYED macro), probably together with an
FT_Get_CID_MaxCount() function (as a service in ftcid.h) since the
highest CID value used in a font is not accessible currently.
Hmm. What about setting
Please forgive me ignorance, but why would the normal
FT_Get_First_Char/FT_Get_Next_Char not work for this? Perhaps I
missed the part in the documentation which states that no glyph
index will exceed the num_glpyhs count, but I have always treated
glyph indexes as a discontinuous sequence.
FT_Get_{First,Next}_Char are walking over cmaps, not over glyph
indices. Except for subsetted CID-keyed CFFs (which use CIDs
instead of glyph indices), the range for glyph indices is *always*
contiguous.
Ok, so the problem is that this one program needs to walk all the
glyphs and dump
FT_Get_{First,Next}_Char are walking over cmaps, not over glyph
indices. Except for subsetted CID-keyed CFFs (which use CIDs
instead of glyph indices), the range for glyph indices is *always*
contiguous.
Er... and sort of ttc files where glyph indices are contiguous but
may be in
BTW, the very change is just a single line:
- cffface-num_glyphs = dict-cid_count;
+ cffface-num_glyphs = cff-charset.max_cid;
I've added this now, together with the FT_IS_CID_KEYED() macro.
Ding, please note that this doesn't yet fix the loading of your test
font in
I found some bitmap seems wrong when I render some characters under
10points.
Just look at the font's `gasp' table: It says that you must not use
hinting below 9pt. This is not a bug.
Werner
___
Freetype-devel mailing list
Friends,
this site might be of interest for you:
http://diwww.epfl.ch/w3lsp/publications/typography/
Especially the following paper might ring some bells if you have ever
looked at the details of the auto hinter:
http://diwww.epfl.ch/w3lsp/publications/typography/tuahsts.pdf
Have fun!
But how can I fix the problem which I met.
I'm working on it.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
A user just sent me to a collection of fonts (ADF_Fontspack -
Akandis Digital Foundry) that were not kerning. I do my own kerning
processing, but I was using FT_HAS_KERNING to determine that there
was no need to look for kerning.
To cite the docs:
FT_FACE_FLAG_KERNING ::
Well, I must have gotten lucky that some fonts had other kerning
that FT recognized ('kern'?) but also had GPOS kerning because the
GPOS code was written and tested with the FT_HAS_KERNING test
enabled.
If a font contains GPOS and `kern', GPOS gets preference (and if
OpenType is supported)
[Please don't answer with HTML-only emails. Use plain text instead.]
Well, i think you're right the splash screen will be annoying. I
also thought of making a license.txt part of the redistributable
(and make the DLL create that file if it does not exist). Or i
could do a combination of
Can anybody tell me?
Sorry, sorry, sorry. Swamped with real work (we have first
performance of `Jesus Christ Superstar' soon) and still trying to fix
the bug from your previous report. I'm a slow worker.
Werner
___
Freetype-devel mailing
The changlog say:
2007-03-05 David Turner [EMAIL PROTECTED]
* src/truetype/ttobs.c (tt_size_init_bytecode): Clear the `x_ppem'
and `y_ppem' fields of the `TT_Size.metrics' structure, not those of
`TT_Size.root.metrics'. Problem reported by Daniel Glöckner
[EMAIL
While writing more tests for libgd, I was trying to figure out a way
to test Freetype rendering result on various operating system and
configuration. It looks like a hard task.
Is there some work already done in this area? like generate a set of
reference images for each (possible) mode .
The issue I have is about the different results depending on the
freetype version or settings. The result may differ slightly making
image comparison somehow useless. What I can try is to detect the
freetype version and how it is built and change the default settings
when necessary or when
Werner, I want to known the progress of this bug. When this bug can
be fixed?
Hopefully, in a few days. I've already checked in some preliminary
steps. It's really a tricky problem to fix it in a general way, sorry
(and I'm not that acquainted with this code part since I haven't
written
I have downloaded latest freetype2.3.5 source code from source
forge. I am compiling freetype on ming and windows. The dynamic
compilation works well but when it is building static libs it throws
the following errors. Please help.
undefined reference to _imp_ft_mem_alloc, _imp_ft_mem_free
I thought that i woudl just move into the folder freetype and run
./configure and make after that. Is there some thing more to it?
Basically, what you've done is correct. However, maybe there are
problems with mingw -- you might try to download the latest versions
of autoconf and libtool to
Folks,
the PS language reference manual the following for CID-keyed PS fonts:
At glyph rendering time, the glyph coordinate system is defined by
the concatenation of the FontMatrix entry in the selected FDArray
dictionary with the FontMatrix entry in the CIDFont
dictionary.
Is this
the PS language reference manual the following for CID-keyed PS
fonts:
At glyph rendering time, the glyph coordinate system is defined
by the concatenation of the FontMatrix entry in the selected
FDArray dictionary with the FontMatrix entry in the CIDFont
dictionary.
Is
Is it possible with the current API to change only specific design
axis of a multiple master font ?
I haven't found a method to do this nor have I found a method to
request the currently used values.
Have you tried the `ftmulti' demo program in the ft2demos bundle?
Press `h' to see the
Have you tried the `ftmulti' demo program in the ft2demos bundle?
Press `h' to see the assigned keys.
Oops, I meant `?'.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Assuming that both those fonts have been extracted from documents
which correctly work with Acroread (Ding Li, Dirck, please
confirm) I assume that it has some heuristic code to either select
[1 0 0 1] or [0.001 0 0 0.001] as the top-level matrix.
The original font in the PDF file worked
Yes, I'm sure I have get all the code from the cvs.
Strange. Are you using the CVS version of ftview also (it shouldn't
make a difference, though)? To avoid DLL irritations I suggest that
you use static linking for building the demo programs -- you have
properly relinked the binaries, have
and another thing is that if i use the dynamic libfreetype.dll.a
then it builds pretty well.
Again, I can't help since I've never used mingw.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi, the attached font is not loaded by freetype but it is loaded by
FontForge so it seems the font is either correct or not that broken
to not be able to be read.
As others have mentioned already: This font is broken, and I won't do
anything to make FreeType accept it.
Werner
Friends,
I have a font which has this buggy `prep' program:
SVTCA[0]
SVTCA[0]
SVTCA[0]
SRP0[ ]
The last command needs some data on the stack, but nothing has been
pushed (executing SVTCA three times is useless also). Now the
problem: The current implementation runs the `prep' program
Delta: 0x0394
Omega: 0x03A9
fraction: 0x2215
hyphen: 0x00AD
macron: 0x02C9
mu: 0x03BC
periodcentered: 0x2219
space: 0x00A0
I suggest you to consider a patch for the psmodule.c, which maps
these glyph names on top of regular AGL mapping. The mapping is
created if the glyph name is
May 17 10:55:41 m2c ATSServer: Serious problems were found in font
data in file /Users/chris/Desktop/font.ttf.
May 17 10:55:41 m2c ATSServer: This font won't be available for use.
Just for the record, that's what OSX 10.4.11 says if I try to open
font.ttf.
Thanks, I've suspected that.
Would you be interested to have DLL configurations in the project
files? For example, Release MT static and Release MT DLL.
Yes, this would be great.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
When I use the memory font, I use the function “FT_New_Memory_Face”
to new a font face.
There is a font buffer in the function parameters.
Does the freetype save a copy of the buffer?
No.
I want to know when the buffer was free?
? Please reformulate.
Does it can be freed buy any
There's the following comment in ftraster.c:
Drop-out mode 2 is hard-coded since this is the only mode used on
Windows platforms. Using other modes, as specified by the font,
results in misplaced pixels.
[Note that the drop-out modes as numbered in ftraster.c differ from
the modes
Nothing serious - I just noticed that the documentation for the
FT_Driver_ClassRec structure (In freetype/internal/ftdriver.h)
documents a 'get_char_index' field (As manditory, no less!), even
though the structure doesn't actually have that field.
Fixed, thanks.
Werner
PS: Sorry to
PS: Sorry to say, but lifting ftdriver.h to be a public API won't
be part of release 2.3.6 but rather 2.3.7.
Ouch! :(
[ BTW - I assume you know this, but I seemed to need ftobjs.h too ]
Oh, oh, this must not happen!
Can you post your driver to this list so that we can have a look
Well, bug #20801 hasn't been fixed yet, thus leaving Cyrillic
charsets users with nothing newer than 2.3.4.
Is there a chance the bug's gonna be fixed before this fall's Ubuntu
8.10 release?
I have no idea, sorry. Currently, it's only me who is working on
FreeType, and the autohinting
Hi, the attached font is not loaded by freetype.
This font is present in a pdf found at
https://bugs.freedesktop.org/show_bug.cgi?id=15008
The font is buggy; it is one byte too short thus the private
dictionary can't be loaded.
As the bug report says: Adobe Reader can't read the font
This font is present in a pdf found at
https://bugs.freedesktop.org/show_bug.cgi?id=15008
FontForge thinks it is erroneous too.
BTW, I wasn't able to load it at all with FontForge on my GNU/Linux
box: It tried to allocate so much memory that my machine froze. This
probably means a bug in
I was using Freetype 2.4.1 till now.
Now I want to upgrade to Version 2.3.5.
Hoho! Version 2.4.2 doesn't exist and you should upgrade to
version 2.3.5, released a few days ago.
Say... what? O_o
Perhaps, 2.3.6?
Hihi. Of course :-)
Werner
A problem with FT_MulFix on i386 platforms using the gcc compiler has
been found:
https://savannah.nongnu.org/bugs/index.php?23556
An easy circumvention of this problem is to compile the FreeType
library with -fno-inline-function. Version 2.3.0-2.3.6 are affected.
Werner
I believe there is a bug in the opentype validator.
Is it a bug?
If I have a MarkToBase table with multiple mark classes and multiple
bases, and where at least one base is missing an attachment site
(anchor) for at least one mark class, then the validator will still
attempt to validate the
No. FreeType does *not* support ClearType.
I thought that ClearType is approximately equal to subpixel
rendering.
Yes, but the description of the additional `modes' and `features' is
far too superficial to be of any value.
But how can you propose a way to inform a font that it is
Between 2.3.5 and 2.3.6 the following change was made to
src\type1\t1objs.c: [...]
After some debugging I found out that this is the change that lets
FreeType now (mis)represent some of the Type1 fonts on my (OS/2)
system as Roman when they were Regular or Italic before:
You are right.
That's better. It now gives me Roman as a style for fonts that don't
have another style whereas it was Regular before, like this
filenamefamily, style (2.3.5) family, style (CVS)
HELVI.PFB Helvetica, Italic Helvetica, Italic
HELV.PFBHelvetica, Regular
Please provide
/FullName
/FamilyName
/FontName
/Weight
of each font so that I can test the reliability of FreeType's
algorithm.
Sure, please see below. [...]
Thanks. I've slightly improved the algorithm so that you get
`Regular' again if FamilyName and FullName
Hi, I think there is another problem with the version 2.3.6.
Yes.
The attachment is a font “F134.ttf”. I set the size 32 points, it
display normal as the picture “2.3.4.jpg”.
But when I use the version 2.3.6, it display as “2.3.6_32.jpg”, it
seems so small.
So I zoom in to 500 points.
Could you wait the release of 2.3.7 until 2008-June-23 (Mon) GMT
0:00 ?
OK, no problem.
I will finish the promised fix of configure.raw for Mac OS X. I
apologize another Macintosh issue (suitcase font face counting) will
be fixed in 2.3.8.
Thanks in advance!
Werner
Well, I don't think further investigation is necessary. The results
are acceptable, I'll just update VTK's unit tests.
It would be sufficient for me to get the font you are using for
the images.
Werner
___
Freetype-devel mailing list
I have attached a patch. Suzuki-San, can you review and commit?
Thanks for your work (which I can't further comment) -- however,
please use the `-u' switch of the `diff' program next time; it makes
the diff (a) more readable and (b) provides some context so that the
possibility of a false
I have a CID-keyed font, and I need to obtain the underlying glyphs in
the font for CIDs and vice-versa. Is there a public function which
does this already?
What exactly do you mean? [This is FreeType 2.3.6] If you call
FT_Load_Glyph for a CID-keyed font, you enter the CID, and you get
back
In my case, I need to work with the OpenType tables directly, but
these are all keyed by glyph index. Here, glyph index is a simple
enumeration of all the glyphs in the font. Often, glyph index is
the same as the CID, but for subset fonts, it doesn't need to be. I
need a way to map from
The excercise is clear: Redesign the API given in ftdriver.h so
that it can be lifted to the public level, relying only on opaque
pointers (cf. the FT_Xxx_Internal typedefs in freetype.h) if
really necessary.
No comment.
This is unfortunate :-) I can't give a time frame for providing
In order to have headers usable for both 32 and 64 bit mode, that
ought to be replaced by something like [...]
You've already reported this:
https://savannah.nongnu.org/bugs/index.php?21250
unfortunately, it hasn't been handled yet. Maybe Suzuki-san (who has
access to a 64bit-system,
After upgrade to 2.3.6 version freetype dysplays CMU Concrete
font (http://cm-unicode.sourceforge.net ) with lower height for
some small Latin letters (g, u, dotlessi) than for other ones
(e.g. x, o, etc.) at some sizes (19, 21 ppem).
I think this is a bug in the hinting of those
Can freetype use C99 features?
Not in general, but I don't object to put it into proper
#ifdef...#endif blocks -- AFAIK, C99 can be checked by a preprocessor
macro, right?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Yes. __STDC_VERSION__ is defined as 199901L. See for example:
http://lists.debian.org/debian-mentors/2002/10/msg00216.html
Thanks. However, I think it would be better to test for `greater or
equal' than just for `equal'.
Werner
___
Here is a sample of cpp input which is based on
my previous post. I tested on:
* Mac OS X 10.4 on G3 PowerPC (default is LP32)
* HP-UX 11 on IA64 HP C compiler (default is LP32. +DD64 makes LP64).
* AIX 5.2 on ppc64 Hitachi C compiler (default is LP32. -64 makes LP64).
* GNU/Linux
Apparently, java has own font engine.
I seem to recall that Java sources are now freely available. Can you
check details, please?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
as we use freetype in our application as a dll on Win32 and x64 I
have extended the distributed VC project files for those platforms
and configurations. I also have created a .def file that contains
the to be exported functions and a .rc file for version information.
If there is interest to
Has the freetype team ever considered switching away from autoconf?
CMake is another option, and might simplify some of the
cross-platform problems. See: http://lwn.net/Articles/188693/
If you can contribute CMake support, I'll add it immediately :-)
Werner
The attach file is a font which is extracted in a PDF. I use the
freetype to draw the font , I found that the glyph index 28573 cannot
be display. But in the acrobat reader, it can displayed normally.
Hmm.
This character maybe a “、”, freetype cannot load it.
There are also some characters
On a historical perspective, the real stuff was about detecting
32-bit int's, because several parts of the library could not be
handled with 16-bit int, so we (well, DavidWerner;-)) decided long
ago to use (now named as) FT_Int32 everywhere, requesting it to be
at least 32 bits.
Hmm.
Could you agree with the restriction of the current scope to
FT_SIZEOF_INT FT_SIZEOF_LONG?
I agree with everything since I don't have the means to test by
myself :-) Please go ahead.
Werner
___
Freetype-devel mailing list
FT_Get_PFR_Advance() seems to expect a 0-based glyph index, but the
rest of Freetype deals with 1-based glyph indexes. As a result,
calling this function with the highest legal glyph index will fail.
Calling it with other values will presumably give the wrong result.
The following patch
This pach adds a cast to silence a compiler warning that happens if
FT_CONFIG_OPTION_POSTSCRIPT_NAMES is not defined.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
This patch fixes a portability problem in FreeType. It also adds a
big comment explaining what the code's trying to do (which was not
obvious to me), and what the portability problem is. So I won't
repeat myself here.
Applied too, thanks. Just curious: On which platform/compiler/CPU
have
401 - 500 of 3661 matches
Mail list logo
