The Cairo PDF backend seems to make direct use of FreeType API (for font subsetting). The necessary functions (looks like just a handful) should be abstracted so the appropriate font backend is used on platforms that provide their own font system. This was noticed when compiling the latest Gtk+ release against the latest Cairo release targeting native Win32. Since Gtk+ has introduced PDF printing functionality, Cairo's PDF backend is now required by Gtk+, leading to the undesirable situation where FreeType is a hard dependency of Gtk+ on all platforms.
Cairo's PS/PDF/SVG backends all depend on FreeType for all their text support right now. See: http://lists.freedesktop.org/archives/cairo/2006-July/007339.html Hans, can the full functionality be implemented easily using win32 API? Do you have any plans to do that?
With some knowledge about PDF font embedding and true type tables it should be possible with reasonable effort to fix the PDF backend. For PS/Type1 fonts embedding I have no idea. The SVG backend seems to not embed any fonts at the moment, so my patch should be enough for now. In any case there should be a fallback path in these backends to *not* embed fonts at all. There are licensing restrictions about embedding specific fonts and for well-known fonts it does not appear to be necessary but just increases file size. If it would be easily implementable for me I probably would have done it already. But I'm afraid that I lack the required knowledge to do it right. And acquiring that is quite low in my list.
For 1.2.2 I think we want to just do Type3 subsetting on win32. We should already have code for that somewhere.
The freetype dependency is very superficial for both truetype and type1 subsetting. In both cases I only really need to access the raw file contents. If there's a way to do that on win32 (and atsui) I can write a patch to make the subsetting code work with the raw contents instead of going through freetype, but I wont be able to test it on win32.
When is 1.2.2 scheduled for? Didn't see anything in ROADMAP.
For win32 the function to use is GetFontData(), see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_8d7l.asp If you just need someone to check if it compiles on win32, feel free to drop me a note;)
(In reply to comment #5) > When is 1.2.2 scheduled for? Didn't see anything in ROADMAP. We are targeting August 7, for GNOME 2.16.0 Beta 2. Carl, can you update the ROADMAP? It's way outdated after 1.2 release.
I'm quite certain that the type3 font support, (and the equivalent thing for the SVG backend), definitely has no freetype dependency. I say that because I wrote the type3 stuff and I don't know how to write any code that uses freetype. So it would even be a straightforward patch to make the additional type1 and truetype font subsetting an optional compilation based on the presence of freetype. (Though, making them work with other font systems would obviously be better.) -Carl
(In reply to comment #7) > Carl, can you update the ROADMAP? It's way outdated after 1.2 release. Behdad, "Anyone" can update ROADMAP. Just push out a new file to cairo/ROADMAP through git and the content magaically appears at http://cairographics/ROADMAP. Sorry for the currently stale data there, (and sorry I'm not fixing it now---I'm signing off tonight until Wednesday.) -Carl
(In reply to comment #7) > (In reply to comment #5) > > When is 1.2.2 scheduled for? Didn't see anything in ROADMAP. > > We are targeting August 7, for GNOME 2.16.0 Beta 2. > > Carl, can you update the ROADMAP? It's way outdated after 1.2 release. This is all updated now. Thanks for the reminder. -Carl
Created attachment 6367 [details] [review] Don't use type1 and truetype subsetting when freetype is not available Here's a patch that should eliminate the freetype dependency from the PDF, SVG, and PS backends. It accomplishes this the easy way by simply not compiling the type1 ro truetype subsetting code if freetype is not available, (or even if freetype is but the FT_Load_Sfnt_Table function is not). I haven't actually tested this on win32 at all. But I did test that if the check for FT_Load_Sfnt_Table fails that everything still compiles and that the PDF backend does indeed produce results using type3 fonts. The patch can also be obtained from the 7538 branch of my personal tree, which can be browsed here: http://gitweb.freedesktop.org/?p=users-cworth-cairo;a=commit;h=10ff02dc03d7be9fa2e49596bfbe4e468cca6bac -Carl PS. When testing this patch, please note that the recent change to the handling of the font matrix leaves text in general quite broken for the PDF and PS backends at least. One might want to revert 84840e6bba6e72aa88fad7a0ee929e8955ba9051 to avoid that problem until a fix is in place.
krh and I thought we can just make _cairo_ps_surface_emit_type1_font_subset and _cairo_ps_surface_emit_truetype_font_subset return UNSUPPORTED.
Oops sorry, seems like this was already discussed.
Bug 7603 has a patch that removes the freetype dependency while adding support for win32 truetype fonts in the PS and PDF backends.
This is now fixed in git.
Adrian, Kristian, Can one of you please patch the subsetting codes (not sure if both need work) to use types like int32_t instead of "long", "int", and "short"? I guess this is the reason truetype subsetting is reported to produce invalid PDF on 64-bit systems. We are releasing 1.2.2 on Aug 7th. Would be cool to have this fixed in that release. Thanks in advance.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.