Bitmap fonts only render monochrome (1-bit). Check bitmap.pixel_mode
after the character is rendered.
Joe Krahn
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
When displaying the MS-Windows symbol.ttf font, the last row is getting
clipped for most font sizes smaller than 32 pixels. This can be seen
with ftsrting, which only shows the missing char box. That makes it
easy to see the last row of pixels getting clipped.
It seems like some sort of
I tried getting freetype to render rows bottom to top using a transform
of yy=-1. This worked for some scalable fonts/sizes, but it often
results in just a few rows of filled pixels. Is freetype supposed to be
able to handle a negative transform? Is there another preferrable way to
flip the
Here's the situation. I am working on a webpage for my mother that
uses a unique font. She has a True Type font built for it. I have
the file. I'm leasing a server that has Free Type 2 installed on
it. I'm guessing it's been intialized but I'm not sure. I seem to
be bulloxing up the
I tried getting freetype to render rows bottom to top using a
transform of yy=-1. This worked for some scalable fonts/sizes, but
it often results in just a few rows of filled pixels. Is freetype
supposed to be able to handle a negative transform? Is there
another preferrable way to flip
When displaying the MS-Windows symbol.ttf font, the last row is
getting clipped for most font sizes smaller than 32 pixels. This
can be seen with ftsrting, which only shows the missing char box.
Hmm, I'm not sure what you mean. How do you call ftstring? Can you
send a small image which
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
Le mercredi 31 août 2005 à 13:58 +0200, Frederic Crozat a écrit :
Le mardi 30 août 2005 à 15:14 -0400, Owen Taylor a écrit :
It was reported with cairo that snapping of stems to integer widths
for LCD rendering was no longer working:
https://bugs.freedesktop.org/show_bug.cgi?id=4302
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
Le mardi 20 septembre 2005 à 14:55 +0200, Turner, David a écrit :
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.
Thanks you
Le mardi 20 septembre 2005 à 15:06 +0200, Frederic Crozat a écrit :
Le mardi 20 septembre 2005 à 14:55 +0200, Turner, David a écrit :
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
On Sun, 2005-09-18 at 13:23, David Somers wrote:
Please find attached a patch against freetype-2.1.10, which allows SING
glyphlet font files to be opened by Freetype.
More info on SING Gaiji Architecture can be found at:
http://partners.adobe.com/public/developer/opentype/gdk/topic.html
I
12 matches
Mail list logo
