Excellent! Will this affect all GTK programs or only Gnome programs?
It should affect all programs that depend on libXft to display anti-aliased
text, which means GTK/Gnome/KDE. I haven't reviewed the Cairo
sources yet, but I suspect that it will also benefit for it.
What about Firefox - will
I've written a small page explaining the likely problems that
people will have installing 2.2 on their system. I'll update it
soon to include patches for common libraries as well.
In the meantime, your comments are welcome:
http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
I've made a web page where I provide patches for rogue
FreeType clients, i.e. those that incorrectly use its internals.
http://turnerdavid.neuf.fr/freetype/rogue-patches.html
this is on my personal web page because I still can't logging
to the freetype.freedesktop.org machine. Damnit !
the
: Turner, David; David Turner; freetype-devel@nongnu.org
Objet : RE: [ft-devel] ft-smooth for 2.1.10?
Hello David,
what exactly
is the API change, and since when?
FT_LOAD_TARGET_LIGHT and FT_RENDER_MODE_LIGHT did nothing for
in 2.1.10.
There is no API change, it's simply
-Message d'origine-
De : Werner LEMBERG [mailto:[EMAIL PROTECTED]
Envoyé : mardi 20 décembre 2005 13:26
À : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED]; Turner, David;
freetype-devel@nongnu.org
Objet : Re: [ft-devel] ft-smooth for 2.1.10?
WARNING: INSTALLING
Hi George,
I think it's a nice proposal, but I'd like to provide an alternative.
The idea being that to avoid two subtables indirections, as well as
the separation of properties/non-properties you made, since I believe
it might be important to re-create a BDF font file with atoms listed
in the
Hello,
I also have a (maybe stupid) question. Why don't we simply have
FT_Set_Pixel_Sizes( face, w, h )
{
FT_Set_Char_Size( face, w, h, 72, 72 ):
}
?
(More looking forward to comments on this question actually)
The question isn't stupid at all. The difference comes from
OK, I'll try an explanation:
FT_Add_Modules was designed to be able to register a new module
after the library initialization on _embedded_ systems, you should
typically do something like the following in the code that *uses*
FT2:
FT_Init_FreeType( library );
FT_Add_Modules( library,
2005 13:51
À : Turner, David
Cc : freetype-devel@nongnu.org
Objet : Re: [ft-devel] Migrating layout table validation code to a new
CVSmodule
Hi,
I apologize that I wrote non-negligibly large code in gxvalid
and it triggered this issue, maybe.
Before all, I have to comment about
ME TOO. David, I've been using your patch for a long time and I love
it. Personally I just cannot understand how someone can so badly break
the kerning and character shapes for some marginal gain in crispness.
But, EVEN if this is not made the default, I don't see why it's not
included even
Hello,
I don't know if some of you won't hate me for this, but
I've commited this morning a new module in the CVS named
ftvalid
It contains a library and test program that duplicate the OpenType
and GX table validation features that are currently found in the
'otvalid' and 'gxvalid' FT2 modules.
As far as I know, all you need is set bitmap-pixel_mode to
FT_PIXEL_MODE_MONO before calling FT_Outline_Get_Bitmap.
the function will then choose the bw renderer automatically.
- David
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
la part de
George Williams
I've already spoken about this in a previous e-mail.
Microsoft holds a large number of patents covering specific
parts of the ClearType technology, see the bottom of this
page for a non-exhaustive list:
http://www.microsoft.com/mscorp/ip/tech/cleartype.asp
For the moment, we're not going to
rendered with Free Type?
Anton
Turner, David wrote:
I've already spoken about this in a previous e-mail.
Microsoft holds a large number of patents covering specific
parts of the ClearType technology, see the bottom of this
page for a non-exhaustive list:
http://www.microsoft.com
ok, i've done some investigation:
- i can't reproduce the problem on Windows, with either make setup devel or
jam
I'm using gcc 3.2.3
- on Linux, I can't reproduce the problem when compiling with Jam at the moment.
However, I *can* with make setup devel. Don't know why just yet. This is
I think there is a misunderstanding. We have integrated
David Chester's patch within FT2 for a long time (2.1.7
or 2.1.8 if I remember correctly).
Could you produce screenshots that detail striking differences
you'd like to see removed ? Please give also complete information
regarding the font
Hello,
-Message d'origine-
Hello,
I'm not sure that this is the proper place to ask but I do it
anyway as
I desparately need some help. I'm trying to compile and test Freetype
on a embedded system, an ARM-processor running ThreadX but my problem
is on the compile-stage. My dev-box
Have there been any changes in the abi that would cause programs to
break if the were linked with older libraries?
I guess the real question is, when was the last time this
happened? I've
been reading the ChangeLogs and I don't see anything jumping
out at me.
Regarding the public API, I
1. What modules should we include in LSB to begin with?
I don't see a reason to exclude a module.
I can see several reasons:
some modules are still experimental and not well tested. I'm thinking
primarily about the otvalid and gxvalid ones used to perform
validation of OpenType tables.
we
Hello Hanno,
I think I have an answer to your question:
- first of all, the behaviour *only* happens when
using the bytecode interpreter. this implies that:
- you're not using the stock FreeType installation
of your Ubuntu distribution :o)
- what's you're seeing is the result of
Hi!
Whould anybody prompt to me about following situation.
I have some font file loaded in memory, for example,
unsigned char* buff; /*loaded file*/
size_t buffSz; /*its size*/
FT_Face face;
..
/*then create FT_Face*/
FT_New_Memory_Face(Lib,
Hello,
old
versions of Pango relied on internal functions of old versions of
FreeType
that
changed or disappeared.
This
source code will not work or compile with FreeType 2.1.10, you must
either
downgrade to a previous version of FreeType, or upgrade your version of
Pango.
Hope
this
Dear
Sir,
in
order to be able to answer your question with insightful answers, may I ask
you
the
following:
- have
you enabled the TrueType bytecode interpreter in your build of FreeType
?
-
could you provide us with a simple test program that shows the differences
between
FreeType
Hello,
Alternately, is there any reasonable way to determine if a font
requires hinting to return a useful outline (aside from hard-coding
a list of known bad fonts)?
You might provide a user dialogue with a check box `if you see crap,
try to activate this' which sets the unpatented
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
la part de
Frederic Crozat
Envoyé : lundi 26 septembre 2005 12:29
À : Turner, David
Cc : freetype-devel@nongnu.org
Objet : RE: [ft-devel] [Patch] Autofit and stem snapping
Le lundi 26 septembre 2005 à 11:42 +0200, Frederic Crozat a écrit :
Le
septembre 2005 10:14
À : Turner, David
Cc : Werner LEMBERG; freetype-devel@nongnu.org
Objet : RE: [ft-devel] [Patch] Autofit and stem snapping
Le vendredi 23 septembre 2005 à 09:07 +0200, Turner, David a écrit :
Hi everyone,
I've got it !
- the demo code didn't really select the hinting
Hi all,
I want to know that, Is it possible to port freetype2 on 8
bit platform
like 8 Bit microcontrollers based on 8051 core or 8 Bit Rabbit
processors?
You mean that all registers and operators are based on 8bit entities?
This won't work with FreeType unless you have a library
:[EMAIL PROTECTED]
la part de
Frederic Crozat
Envoyé : mercredi 21 septembre 2005 10:22
À : Werner LEMBERG
Cc : Turner, David; freetype-devel@nongnu.org
Objet : Re: [ft-devel] [Patch] Autofit and stem snapping
Le mercredi 21 septembre 2005 à 00:20 +0200, Werner LEMBERG a écrit :
Ok, while
In theory, FreeType should work on 16-bit platforms, but
this hasn't been officially verified for a very long time.
However, I don't know of any 8-bit platform that is capable
of dealing with, say, memory-mapped files or heap blocks
that are larger than, say, 64 Kb, and this ability is
required
for the demo programs at the moment.
Regards,
- David Turner
- The FreeType Project (www.freetype.org)
-Message d'origine-
De : Frederic Crozat [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 21 septembre 2005 10:22
À : Werner LEMBERG
Cc : freetype-devel@nongnu.org; Turner, David
Objet
Hello,
[...] I'm having problem with the cache system under low memory
conditions. It seems if our system doesn't have 'max_bytes'
available, FTC_CMapCache_Lookup will repeatedly fail (returing
glyph_index = 0) once there is no more memory. Should the system free
part of the cache when
Salut Frédéric,
I've reviewed Owen's patch, which led me to peek inside the
sources of libXft and Cairo to understand the difference. I
now believe that the problem is in Cairo and that the patch
is incorrect.
I believe that this comes from a misunderstanding of the
FreeType API from the Cairo
Hello,
I cannot send you the real program. But this is based on the
tutorial step-1.
The addition is only that...image buffer is copied to print buffer.
I have some small comments regarding your source code, though no
real solution to provide.
a/ never call free(NULL), since the
* freetype2/builds/mac/ftlib.prj is for CodeWarrior
* freetype2/base/Jamfile is cross platform,
but ftmac.c is quoted for MPW
Not sure here either. I think Jamfiles were used in
ProjectBuilder some time ago, that means OS X/gcc - Mach-O
As far as I understand, this warning only applies to
code that reads the resource fork directly and doesn't
try to read fields in cpu-independent order.
A quicky look at the sources shows that:
- src/base/ftobjs.c is clean
- src/base/ftmac.chowever does typecast pointers
Salut Antoine,
Useless about security, probably.
Yes
Worse, the MS tool that signs does not check many things (and
certainly not possible exploit, since none are known ;-)), and anyway you
can set it up to allow signing using /another/ checking tool...
Which are the reasons why you,
I started looking at this. Unfortunately the FSSpec type has
wormed its
way into the API for the mac:
FT_EXPORT_DEF( FT_Error )
FT_New_Face_From_FSSpec( FT_Librarylibrary,
const FSSpec *spec,
FT_Long face_index,
If digital signatures are not mandatory _and_ used with
non-reversible
encryption, they're simply useless.
As signed font can be thought of as the equivalent of a signed (but
unencrypted) email message (its done using more-or-less the
same system).
Hoo, the horror of counterfeit
Applied, thanks. You've looked at Courier New with anti-aliasing off,
right? If you switch it on, you won't see that horizontal lines
disappear. 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
Hello everyone,
I'm back from vacation and have some hints regarding this infamous
crash.
- First of all, the reason why some pointers have been set to NULL in
the latest package is really that:
* the functions were _not_ used by the rest of the library,
nor exposed through a
Hello Trevor,
I have asked this before in a way, but...
Is there any specific information anyone could give me about
error code 0x12
(Invalid Glyph Format)
On which function ?
Anything specific would be very much appriciated. What might
cause this,
where it might be, what structs
This
is not trivial, and must be performed on top of FreeType.
I'll
ignore the problem of bidirectionnal text for the moment, since this
adds
another layer of complexity.
There is an "easy" way which consists in using the
Arabic presentation forms
of Unicode (in the ranges U+FB50..U+FBFD
Please please do not make the sources more complex than they
already are.
Contrary to popular advice, putting const everywhere is
_not_ important. It's just semantic sugar, and a hint to
developers that can also be placed in the documentation of
a given function. Of course we'd all be better if
Hello Anstinus,
But the face_id is just a pointer, then if I write the
following code, it
will not work as I expect:
[code removed]
The ftFace1 and ftFace2 will have the same value!
An important design point of the cache subsystem is that a
FTC_FaceID value (i.e. the address contained
44 matches
Mail list logo
