Re: [ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?
On Mon, Mar 1, 2010 at 11:30 PM, Tor Lillqvist t...@iki.fi wrote: Sorry, I don't. As the enter/exit functions are called dozens of times before something odd happens and the exit function isn't called (and then later the Pango function is called), it would take quite some time to debug... Maybe next weekend. A time-machine in the debugger would be nice;) GDB 7.x has something like this, for some targets: http://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html I don't know if windows is one of those. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Enabling the incremental interface by default
On Wed, Jan 6, 2010 at 1:24 AM, Werner LEMBERG w...@gnu.org wrote: OK. By the way, FreeType's PostScript hinting is rather miserable currently (and buggy too -- I'm aware of at least one serious bug but haven't had time yet to fix it); a longer time ago someone has suggested to merge the autohinter with the PS hinter, which sounds sensible. Oh dear. Is that https://savannah.nongnu.org/bugs/?23669 ? -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Enabling the incremental interface by default
All, Attached is a patch enabling FT_CONFIG_OPTION_INCREMENTAL in the default build. I hope Werner will apply it. The argument for this is as follows: FreeType has for many years provided an optional FT_Incremental_Interface to support clients like Ghostscript which need to be able to supply glyph data through a callback as text is rendered. This was an optional feature in Ghostscript, but we are now switching to FreeType as our primary font rasterizer. There will be a transition period this year, after which we hope to rely entirely on FreeType and abandon our native rasterizer. As such, it would be nice if we could link directly against upstream. That's would be convenient for us, but I think it also makes sense for the general community. The incremental interface had bit-rotted quite a bit since it was initially developed. As of today, Ken Sharp and Werner have it working again without crashes or errors. If this API is going to be in regular use it makes sense to build it so it gets more regular attention. Also, Ghostscript is a core component of the printing infrastructure on most free operating systems, and part of the Linux Standard Base. The packaging guidelines of most Linux distributions require linking against shared system libraries for all dependencies, so the distros will have to ship FreeType with the interface enabled anyway. Enabling it upstream simplifies this transition and makes less work for everybody, since we can just depend on a new release. Cheers, -r 0001-Enable-the-incremental-font-interface-by-default.patch Description: Binary data 0002-Improve-the-comment-describing-the-FT_CONFIG_OPTION_.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Apple Patents on font hinting expired?
On Thu, Nov 12, 2009 at 3:59 AM, Russell Hay russe...@ysmail.net wrote: 5,155,805: October 13, 2009 5,159,668: October 27, 2009 The relevant US patents have expired, but I believe there are equivalent patents in Canada, Japan and Germany. The truetype hinting instructions should be free worldwide in May, 2010. See: http://www.freetype.org/patents.html FWIW, -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems in ubuntu fonts rendering with freetype2
On Mon, Oct 26, 2009 at 7:41 AM, oscar santis pelaosan...@gmail.com wrote: ./configure --prefix=/usr make sudo make install This overwrites the Ubuntu system's freetype with the one you've compiled. sudo make uninstall This removes the one you compiled, leaving no freetype on your system. This is why nothing works. You need to restore the original version from the Ubuntu package. Generally it is better to test libraries by installing them with --prefix=/usr/local instead of /usr. On most systems this will override the system version, but if it's removed or there are marked version differences, applications can still use the distro version from /usr. This is why --prefix=/usr/local is the default. Good luck with the recovery, -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [PATCH] Document that FT_Get_X11_Font_Format is an intrinsic call
Working on the the freetype integration in ghostscript again, I went looking for a way to identify whether an FT_Face was a Type 1 or TrueType. There is a function which implements this, confusingly named FT_Get_X11_Font_Format() because it was originally added (in 2002) for the benefit of XFree86, even though the documentation is aware that PDF implementations also need this feature. I was concerned about this being platform-dependent and traced through some of the code; it is completely intrinsic to freetype and doesn't depend on X11 at all. i Please consider applying the attached documentation patch to clarify this. 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 module. -r From 6783bc25ab1ce8128b0fd44d5052f49d284ecb8f Mon Sep 17 00:00:00 2001 From: Ralph Giles gi...@ghostscript.com Date: Wed, 26 Aug 2009 13:27:04 -0700 Subject: [PATCH] Document that FT_Get_X11_Font_Format() is a general call. This function was originally added to return the underlying font format in a way which was compatible with the needs of the XFree86 font server. However, a function of this sort is also necessary when freetype is used by PDF interpreters which apply different rules based on the font format. The X11 namespace is confusing for such users. This commit ameliorates that confusion by documenting that this function is in fact entirely internal to freetype and doesn't depend on X11 in any way. --- include/freetype/ftxf86.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/freetype/ftxf86.h b/include/freetype/ftxf86.h index ae9ff07..8c68afd 100644 --- a/include/freetype/ftxf86.h +++ b/include/freetype/ftxf86.h @@ -49,6 +49,9 @@ FT_BEGIN_HEADER /* however, there are special cases (like in PDF devices) where it is */ /* important to differentiate, in spite of FreeType's uniform API. */ /* */ + /* This function is in the X11/xf86 namespace for historical reasons */ + /* and in no way depends on that windowing system. */ + /* */ /*/ -- 1.6.0.4 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] git
On Thu, May 21, 2009 at 4:43 PM, Tom Kacvinsky tkacvin...@mac.com wrote: I am looking at getting back into the FreeType project after a five or so year hiatus. I see things have moved from cvs to git (skipped svn?) Does anyone know of a good tutorial on git? http://git.or.cz/course/svn.html (-- git in terms of svn) http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [PATCH] Fix SEAC glyphs with the incremental interface
All, Please take a look at the attached patch to make accented characters work with the incremental font interface Ghostscript uses. The patch is gs-specific, but we'd like to get this resolved upstream somehow. Basically, the implementation of the type 1 single encoding accented glyph operator tries to look up the referenced glyph indices before constructing the composite glyph. We don't pass the decoding in when using the incremental interface, so this fails. And indeed, the check is prefaced with a comment: /* `glyph_names' is set to 0 for CID fonts which do not */ /* include an encoding. How can we deal with these?*/ Our patch just disables the check if the incremental font interface is compiled in, which I doubt is satisfactory. How should this be handled? It works fine if the code assumes an identity mapping. I'm confused how responsibility was intended to be divided here; the API Reference says, Apart from [glyphs\, all other tables are loaded normally from the font file. This mode is useful when FreeType is used within another engine, e.g., a PostScript Imaging Processor. I don't understand how that's intended to work when there is no literal font file. If we can't resolve this quickly, applying the patch as is would be better than nothing, since it doesn't affect the normal build. -r SEAC-glyphs-fail-with-incremental.patch Description: application/mbox ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2 repositories moved to git
On Sat, Mar 14, 2009 at 7:36 AM, Werner LEMBERG w...@gnu.org wrote: I have migrated the FreeType 2 repositories from CVS to git, using Keith Packard's `cvsparse' tool and updating empty commit log messages afterwards. Hooray! Remote repositories could use a description file for the gitweb index. Those urls are: http://git.savannah.gnu.org/gitweb/?p=freetype/freetype2.git http://git.savannah.gnu.org/gitweb/?p=freetype/freetype2-demos.git Also, the repository seems to be missing tags? -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] check for missing glyf table
On Wed, Mar 4, 2009 at 10:01 PM, Werner LEMBERG w...@gnu.org wrote: Sorry to say but I haven't found time yet to actually work on the incremental interface, and I fear I have to postpone this after the next FreeType release which should appear this weekend. Ok, thanks for letting us know. Looking forward to rebasing our patches after the release. :) I must set up gs + freetype to test those things. As soon as I'm ready for that I'll contact you, asking for failing fonts (and/or snippets) which I can debug then. 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. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] check for missing glyf table
Werner, On December 9 you committed a fix for Savannah bug #25010, which includes adding a check for an empty glyf table to load_truetype_glyph(). However, the check is implemented as a proxy check for a zero glyf_offset, rather than the table itself being absent. I think this isn't correct when the incremental font interface is being used. In that case the font data consists only of the glyph data, and the offset can be zero. At least that's our analysis so far. We have two files which fail on this check, and render correctly when it is bypassed. Is there some other way the presence of a glyf table can be checked? -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with CVS-git conversion
On Tue, Mar 3, 2009 at 6:03 AM, Werner LEMBERG w...@gnu.org wrote: . git format-patch . editing commit messages in the *.patch files . git am --rebasing --whitespace=nowarn *.patch works fine, however, it loses all tags created by parsecvs. Presumedly this is because changing the log message changes the commit hash, so the tags are no longer part of the reachable history. You should just be able to add: . check if the commit was tagged and 'git tag -f tag commit' for the appropriate patches. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
On Mon, Feb 23, 2009 at 10:02 AM, David Turner da...@freetype.org wrote: I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? Hi David! This would be nice for me as well. Nothing really of high priority, but I wanted at least to know your opinion about it ? There was a thread about this in December in January. Suzuki-san did some trial conversions and there was some discussion about editing the commit messages to give a better shortlog as part of an official conversion. http://lists.gnu.org/archive/html/freetype-devel/2008-12/msg00074.html http://lists.gnu.org/archive/html/freetype-devel/2009-01/msg1.html Note that git support on windows is still shaky. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
On Mon, Feb 23, 2009 at 6:20 PM, David Turner da...@freetype.org wrote:
An experimental git repository is now in place, see http://git.freetype.org
Woo!
gitosis / git-daemon / gitweb are nice, but oh my, they are so badly
documented that it's hard to avoid many pitfalls. I'll try to document them
later.
No kidding. I've set up a couple of gitweb instances, if you need any help.
In particular:
edit *.git/description to set the description column in the gitweb index
add the git-daemon base url to the git_base_url_list definition in
gitweb.cgi. Something like
our @git_base_url_list = grep { $_ ne '' } (git://git.freetype.org);
There's some way to also list an http url, which is helpful for people
behind firewalls, but I've not figured it out yet. You don't want to
default to the http url because it's so much slower.
-r
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Incremental font support
On Wed, Feb 18, 2009 at 7:59 AM, Henry Stiles henry.sti...@artifex.com wrote: to build gs with freeype: make FT_BRIDGE=1 FT_CFLAGS=-I../freetype-2.3.8/include FT_LIB=./freetype-2.3.8/objs/libfreetype.a debug Just to follow up for anyone trying this; this is with the 'freetype' branch from my personal git tree; http://git.ghostscript.com/?p=gs-giles;a=summary With the current tip you need: make FT_BRIDGE=1 FT_CFLAGS=-I../freetype-2.3.8/include FT_LIBS=./freetype-2.3.8/objs/libfreetype.a debug Assuming you've compiled freetype-2.3.8 in a parallel directory. I also had to copy lib/FAPI* to the run directory for the bridge to work. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Incremental font support
Werner, 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. In particular, at t1gload.c:287 T1_Load_Glyph() throws T1_Err_Invalid_Argument if the requested glyph index is larger than num_glyphs in the face. Yet as far as I can tell this was never set through the incremental font api. Similarly, version 1.205 of ttgload.c broke incremental truetype handling. What can we do to fix this up? Is our code wrong? How is this supposed to work. Do you have any tests for the incremental api? -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Next FreeType release
On Tue, Jan 6, 2009 at 1:10 PM, Sean McBride s...@rogue-research.com wrote: I just worry that having duplicates will interfere with Xcode or other things that I build. You could use the Jam build. Apple hasn't used jam since Xcode 1.x, and it has no dependencies. I keep a copy of the source at http://ghostscript.com/~giles/jam/jam-2.5.tar.gz if that's helpful. Is there no way to build freetype with the tools Apple provides? Apparently not from the CVS. I'll send you a configure script privately which you can use. In cases like this, it's helpful to provide distribution snapshots if you want cross-platform testing. After all, it's not whether the CVS build works with whatever autotools suite someone happens to have installed, but whether whatever 'make dist' includes on the maintainer's machine will actually work with the native build tools that you can about for release. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Next FreeType release
On Wed, Jan 7, 2009 at 1:07 PM, Werner LEMBERG w...@gnu.org wrote: Nice idea. However, I just update the Jam files, but I never actually run them. It's thus possible that errors have crept in. It built the other day when I tried. I didn't try executing the results though. -r ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
