The attached patch changes the way 'ftview' fills the window with
glyphs so that the right margin is less blank and a larger number of
glyphs shown. It uses the actual width of the current grBitmap,
instead of super conservative max_advance, when fitting the glyphs
in the available space.
The attached patch changes the way 'ftview' fills the window with
glyphs so that the right margin is less blank and a larger number of
glyphs shown. It uses the actual width of the current grBitmap,
instead of super conservative max_advance, when fitting the glyphs
in the available space.
Hello freetype-devel'ers,
I was wondering if anyone on this list might be able to help me work out the
effort required to support the FF Chartwell font in freetype2:
https://www.fontfont.com/how-to-use-ff-chartwell
This is a font which uses ligatures to create small, interesting,
I was wondering if anyone on this list might be able to help me work
out the effort required to support the FF Chartwell font in freetype2:
https://www.fontfont.com/how-to-use-ff-chartwell
Direct support in FreeType? Nope. You need either Pango, ICU, or
HarfBuzz which are OpenType
On 06/27/2012 07:41 AM, Jay Vaughan wrote:
Direct support in FreeType? Nope. You need either Pango, ICU, or
HarfBuzz which are OpenType libraries on top of FreeType (and others
also); then it works out of the box.
Thanks for the answer! I guess we're already using freetype2 in moai,
On 06/27/2012 08:27 AM, Werner LEMBERG wrote:
Here's a simple example:
https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz
Okay, thanks for that .. it looks like something I can work with. I
guess I'll have to commit to adding pango or harfbuzz support to
MOAI, then .. time to do
I've picked FT_Err_Raster_Overflow to indicate the boundary. Is
that appropriate?
No, it isn't IMHO: FT_Err_Raster_Overflow is a fatal error, indicating
a serious problem which the rasterizer can't manage. I think a simple
integer will serve as return error instead of FT_Error.
I am also
After applying that patch, it still doesn't build.
j@aaa-build:~/Desktop/ex-sdl-cairo-freetype-harfbuzz$ make
gcc ex-sdl-cairo-freetype-harfbuzz.c --std=c99 -g -Wall --pedantic `pkg-config
freetype2 --cflags` `pkg-config glib-2.0 --cflags` `pkg-config harfbuzz
--cflags` `pkg-config cairo-ft
On 06/27/2012 08:33 AM, Jay Vaughan wrote:
ex-sdl-cairo-freetype-harfbuzz.c:146:13: error: too few arguments to function
‘hb_buffer_create’
/usr/local/include/harfbuzz/hb-buffer.h:63:1: note: declared here
ex-sdl-cairo-freetype-harfbuzz.c:151:13: error: too many arguments to
function
Great - thanks for pointing that out. The sample is now running. I've tried
add FF Chartwell to the app, but do not quite yet know how to tell harfbuzz
to use the StylisticSet01/ligatures feature of the font.. yet. Any chance you
guys want to meet in IRC?
--
Jay Vaughan
j...@allaboutapps.at
In the call to hb_shape(), you need to pass in features. Sure, I'm on the
#harfbuzz channel on freenode.
On 06/27/2012 08:47 AM, Jay Vaughan wrote:
Great - thanks for pointing that out. The sample is now running. I've tried
add FF Chartwell to the app, but do not quite yet know how to tell
Great, I have it working!
And in fact, Chartwell looks pretty good - although I haven't set up the font
sizes and coloring to really show it off, this screenshot at least shows that
it works very smoothly. So, I'll try to add harfbuzz integration into the MOAI
client next .. Thanks for your
Is there anyone interested in adding WOFF support directly to FreeType?
It's a trivial amount of work. Basically you copy the SFNT code, slightly
modify it, and hook up the gzip decompressor to the tables...
It's so frustrating that there are essentially no tools to work with WOFF
files in a
Is there anyone interested in adding WOFF support directly to
FreeType?
Yes, I will eventually add it but have'nt found time yet.
It's a trivial amount of work. Basically you copy the SFNT code,
slightly modify it, and hook up the gzip decompressor to the
tables...
Patches, please :-)
I'd be happy to contribute back a working example if I get this fixed ..
The working example, wherein Chartwell is demonstrated:
http://w1xer.at/ex-sdl-cairo-freetype-harfbuzz_CHARTWELL_HACK.c
Thanks for the help you guys, I'll be moving forward on harfbuzz+moai
integration next ..
j.
At present, FreeType2's compress font file I/O is designed for
the case that whole of font file is compressed as single stream.
On the other hand, WOFF will request the per-table decompression.
The easiest support would be done by the construction of the
sfnt font file image by using zlib, and
On Wed, Jun 27, 2012 at 8:33 AM, Werner LEMBERG w...@gnu.org wrote:
I've picked FT_Err_Raster_Overflow to indicate the boundary. Is
that appropriate?
No, it isn't IMHO: FT_Err_Raster_Overflow is a fatal error, indicating
a serious problem which the rasterizer can't manage. I think a simple
[...] the drawing functions ultimately inherit the error codes from
FT_Glyph_To_Bitmap currently. Therefore it has to be something
different from those defined in fterrdef.h to distinguish. It would
be good if freetype reserved an FT_Err_User, defined as -1 or 0xFF
perhaps, which is not
Broken since the origin (commit d818ba597945cd9a59583eb6efe75f58b468cfe5)
Signed-off-by: Gilles Espinasse g@free.fr
---
builds/unix/configure.raw |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index
-AC_MSG_RESULT([whether CFLAGS and LDFLAGS share ${c}])
+AC_MSG_CHECKING([whether CFLAGS and LDFLAGS share ${c}])
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
20 matches
Mail list logo
