Re: soname (was Re: [ft-devel] Freetype library for LSB)
On Mon, 25 Jul 2005, Owen Taylor wrote: -export-symbols is pretty straightforward to use - we use it (or actually, -export-symbols-regex for Pango). You probably could build the symbol file pretty easily by scanning the for FT_EXPORT ... well, if you didn't use that for internal symbols. Ulrich Drepper writes in his paper [1]: === 2.2.6 Libtool's -export-symbols ... Interesting for us here is the code the linker produces using this method. For the GNU linker Libtool converts -export-symbols option into the completely useless -retain-symbols-file option. This option instructs the linker to prune the normal symbol tables, not the dynamic symbol table. The normal symbol table will contain only the symbols named in the export list file plus the special STT_SECTION symbols which might be needed in relocations. All local symbols are gone. The problem is that the dynamic symbol table is not touched at all and this is the table which is actually used at runtime. The effect of the using libtool this way is that programs reading the normal symbol table (for instance nm) do not find any symbols but those listed in the export list. Neither have any symbols been made unavailable for the dynamic linker, nor have any normal relocations been converted into relative relocations. The only reason this method is mentioned here is that there is hope libtool will learn about converting the export lists into the anonymous version maps we have seen in the previous section when the GNU linker is used. At that point libtool will become useful. Until then relying on its -export-symbols option is misleading at best. == Don't know if this has changed since. A quick look at the libtool ChangeLog doesn't suggest any. CC'ing [EMAIL PROTECTED] [1] http://www.livejournal.com/users/udrepper/2491.html --behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] compile problem: freetype/internal/services/svtteng.h: No such file or directory
Hi David, Trying to compile CVS, I get the following: In file included from /home/behdad/src/sv/freetype/freetype2/src/base/ftbase.c:30: /home/behdad/src/sv/freetype/freetype2/src/base/ftobjs.c:37:38: error: freetype/internal/services/svtteng.h: No such file or directory And indeed there's no such file in include/. Forgot to cvs add? --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Third Release candidate for FT 2.2 available
On Sun, 26 Feb 2006, David Somers wrote: RC3 seems to work on my Gentoo/Linux system... although I now seem to have problems with the edges of some glyphs being clipped on fixed-width fonts. That's probably because the release candidates had the patch for not rounding glyph metrics. David already reverted that patch, as it was causing similar problems in GNOME and cairo. So, test CVS HEAD. David - am sending you a screenshot which shows the problem. Greetings from Luxembourg --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog docs/CHANGES src/autofit/...
On Mon, 20 Mar 2006, Werner LEMBERG wrote: BTW, we have this line in ftcache.h typedef struct FTC_ManagerRec_* FTC_Manager; but no FTC_ManagerRec definition... That by itself is not necessarily a problem. We have things like that in Pango all the time for declaring abstract interfaces... Werner --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fourth Release candidate for 2.2
On Mon, 27 Mar 2006, Dave Behnke wrote: I integrated this build into my project and ran into a minor problem in trying to use an arial truetype font. Lines 171 - 173 of \src\sfnt\ttmtx.c, in the tt_face_load_hmtx method look like this: if ( FT_QNEW_ARRAY( *longs, num_longs ) || FT_QNEW_ARRAY( *shorts, num_shorts ) ) goto Fail; The problem is that my font has all 1673 long format metrics and 0 short format so the second call to FT_QNEW_ARRAY gets 0 as its second argument. This causes it throw an invalid parameter error. I'm not exactly sure what the intention was but I think all long or all short formats should be valid. I believe this is already fixed in CVS. Check recent mailing list archives for the discussion. Dave Behnke Retail Technology Solutions, Inc. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] OpenType Layout code revisited
Hi, Last night I restructured and cleaned up the OpenType Layout code (from FreeType1) that has been in Pango and import it into a new repository under the name HarfBuzz on fd.o. You can browse the code or join the mailing list here: http://freedesktop.org/wiki/Software/harfbuzz It contains the OTL buffer object that Owen developed too. Lars Knoll has already shown interest in reusing this version in Qt, and Pango is using a copy of it that I'll keep in synch. Comments and suggestions are welcome :). --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft22 and pango
On Tue, 11 Apr 2006, David Somers wrote: Hi folks, I've noticed that after installing freetype (from CVS HEAD today) a few of my gtk-based apps seg faulted: Program received signal SIGSEGV, Segmentation fault. 0xb776a75b in pango_fc_font_get_raw_extents () from /usr/lib/libpangoft2-1.0.so.0 Just in case anybody else comes across this, the solution seems to be to rebuild pango and cairo. (I also rebuilt fontconfig and glib, but I can't be sure if that was really necessary too). Greetings from Lux. It's not supposed to be needed. If it is, it's a binary compatibility problem and should be investigated. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType version 2.2.1 released
On Thu, 18 May 2006, Matthias Clasen wrote: On Wed, 2006-05-17 at 19:40 -0400, James Cloos wrote: Changing line 194 of your patch from: if ( strike_index != 0xU ) to if ( strike_index != 0xU ft_face-available_sizes != NULL) avoids a NULL dereference in FT_Do_SBit_Metrics() in ftfuncs.c. After that change I can't crash xfs, but any ttf font (sfnt/glyf font) showns only odd glyphs in a 16bit encoding such as iso10646-1. 8bit encodings work fine, as do type1 fonts. Testing the patch, I'm getting another crash for a Type1 font: #0 0x003ea427 in FT_Do_SBit_Metrics (ft_face=0x8a394c8, ft_size=0x8a21328, strike_index=0, glyph_index=0, metrics_return=0xbff4d58c, sbitchk_incomplete_but_exist=0xbff4d588) at ftfuncs.c:989 #1 0x003ea60a in FreeTypeRasteriseGlyph (idx=0, flags=1, tgp=0x8a3fa00, instance=0x8a21210, hasMetrics=0) at ftfuncs.c:1128 #2 0x003e9834 in FreeTypeInstanceGetGlyph (idx=0, flags=1, g=0xbff4d768, instance=0x8a21210) at ftfuncs.c:711 #3 0x003f1143 in FreeTypeLoadXFont (fileName=0xbff4de43 /usr/share/X11/fonts/Type1/UTBI.pfa, vals=0xbff4ddd4, xf=0x0, info=0xbff4eaec, bmfmt=0xbff4d974, entry=0x89680c0) at ftfuncs.c:3458 #4 0x003f1dcd in FreeTypeGetInfoScalable (fpe=0x8929a08, info=0xbff4eaec, entry=0x89680c0, fontName=0xbff4de38, fileName=0xbff4de43 /usr/share/X11/fonts/Type1/UTBI.pfa, vals=0xbff4ddd4) at ftfuncs.c:3874 #5 0x003e569a in FontFileListOneFontWithInfo (client=0x8a03900, fpe=0x8929a08, namep=0xbff4eaa8, namelenp=0xbff4eaa4, pFontInfo=0xbff4eb4c) at fontfile.c:1010 #6 0x003e57bf in FontFileListNextFontWithInfo (client=0x8a03900, fpe=0x8929a08, namep=0xbff4eb58, namelenp=0xbff4eb54, pFontInfo=0xbff4eb4c, numFonts=0xbff4eb50, private=0x8a26070) at fontfile.c:1048 #7 0x0805057b in init_fs_handlers () #8 0x08050d1f in init_fs_handlers () #9 0x0804d640 in set_font_authorizations () #10 0x0804dddf in set_font_authorizations () #11 0x080525f6 in init_fs_handlers () #12 0x00126724 in __libc_start_main () from /lib/libc.so.6 #13 0x0804a451 in ?? () Seems like ft_face-available_sizes is NULL. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType version 2.2.1 released
On Mon, 5 Jun 2006, David Turner wrote: Werner LEMBERG a �crit : Testing the patch, I'm getting another crash for a Type1 font: [...] Seems like ft_face-available_sizes is NULL. I don't have time to follow the thread -- is it necessary to do something on the FreeType side (either code or documentation)? Can you provide a patch in case we should fix something? no, it's ok, the patch I provided had just a little bug, but I think that this had been corrected. Correct. However, I cannot reproduce the warning message that Matthias and James are reporting. James, did you get more info yet? Do you guys need an updated patch with the fix, or had this been integrated in the CVS already ? I don't think this has been integrated. Regards, - David Turner - The FreeType Project (www.freetype.org) --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] LCD Filtering changes
On Wed, 2006-11-15 at 15:24 +0100, Werner LEMBERG wrote: These are all cool stuff. I just want to request that FreeType be released more regularly. Preferably, separate stable and devel branches should be maintained. There are lots of serious bugs fixed in FreeType CVS that are not in any release, and lots of other changes that are not stable enough for a release. This makes downstream maintenance of FreeType quite a tedious task compared to other packages like the Gtk+ stack. We are aware of that, but most of the time it's just David and me who work on FreeType. Right now David is changing jobs which in consequence means moving to a different continent. I have other projects to maintain also, and answering email normally eats up most of the time I can afford to FreeType. With other words, we need helping hands. Fully understood. How about: - Getting 2.2.2 out sooner than later. - After that, let distro maintainer maintain a stable branch in FreeType CVS. This will include backports from HEAD mostly. - Make, or let distro maintainers make, stable releases 2.2.3, 2.2.4, ... out of the stable branch. - Next major release will be 2.3.0, or if you prefer cairo style, 2.4.0... Werner -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.3.0 release candidate 2 available
On Fri, 2007-01-12 at 20:48 -0500, David Turner wrote: I just uploaded the second release candidate: http://david.freetype.org/freetype/freetype-2.3.0rc2.tar.bz2 http://david.freetype.org/freetype/freetype-2.3.0rc2.tar.g2 http://david.freetype.org/freetype/ft230rc2.zip Thanks David. Next time, if you can upload the demos and docs tarballs too, just like a release is structured, I'll be more than happy to put it into Fedora development branch for testing. Cheers, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Regression with slight hinting
Hi, So, this is not something new, fcrozat already raised this after 2.2.1 was release, but since this has not improved in 2.3.0, I'm reposing. There is a Fedora bug about this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198082 The interesting shots are: before: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=145894 after: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=145897 None and medium (in gnome-font-properties speak) settings are fine and render identically before and after. Not for slight. Note that there is a chance that the after shot is using TrueType Luxi while the before is using Type1 Luxi, but I don't think that really matters much, since the other hinting modes match in rendering. Regards, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Relicensing HarfBuzz code from FreeType
Hi FreeType developers, We have a bit of a problem with the old OpenType Layout code ripped out of FreeType and called HarfBuzz these days. The problem is that Pango is LGPL'ed, while HarfBuzz is GPL+FTL. The two do not quite match. Are the FreeType developers willing to do one of the following: - Change HarfBuzz license to LGPL+FTL - Remove the advertising clause from the FTL license in HarfBuzz, such that it becomes compatible with LGPL. Thanks, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Relicensing HarfBuzz code from FreeType
On Sun, 2007-02-04 at 18:52 +0100, David Turner wrote: Hi Behdad, On Sat, 03 Feb 2007 11:03:56 -0500, Behdad Esfahbod [EMAIL PROTECTED] said: Hi FreeType developers, We have a bit of a problem with the old OpenType Layout code ripped out of FreeType and called HarfBuzz these days. The problem is that Pango is LGPL'ed, while HarfBuzz is GPL+FTL. I don't understand. FreeType is GPL+FTL as well, and Pango as no problem using it. Why would it be different with Harfbuzz ? The problem is in Pango actually. Pango has no problem using it as in no one ever complained about, except recently in Fedora lists. The complaint is that Pango is not LGPLed, because it uses code that is GPL +FTL. Nothing serious. I thought I ask for a relicensing, but if that's not possible, I'll just make it clear in Pango's license that it's not LGPL. Regards, - David -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Relicensing HarfBuzz code from FreeType
On Sun, 2007-02-04 at 19:14 +0100, David Turner wrote: The problem is in Pango actually. Pango has no problem using it as in no one ever complained about, except recently in Fedora lists. The complaint is that Pango is not LGPLed, because it uses code that is GPL +FTL. Ah sorry, I imagined that harfbuzz was going to be distributed as a separate library, not as an integral part of Pango. Eventually we probably will distribute it separately. But today, it's just copied in Pango like it has been for a few years. I'm rewriting the code right now, so it may not be a problem in the future, but I like to have the freedom to copy from the current code into mine. In this new context, I understand that you would want a single license. I'm ok with re-licensing this code under the LGPL, but I believe that Werner wrote most of it, so you'd better ask him (and check the sources for author disclaimers). All the sources mentioned you, Werner, and Robert Wilhelm. Thanks behdad Regards, - David Nothing serious. I thought I ask for a relicensing, but if that's not possible, I'll just make it clear in Pango's license that it's not LGPL. Regards, - David -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Relicensing HarfBuzz code from FreeType
On Sun, 2007-02-04 at 21:54 +0100, Werner LEMBERG wrote: In this new context, I understand that you would want a single license. I'm ok with re-licensing this code under the LGPL, Me too. Great, thanks. To make sure, I'm looking for making it LGPL+FTL. Not LGPL alone. The FTL license is depended on in Qt I guess. So, is Robert still around and on this list? Werner -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: autokerning (was [ft-devel] New FreeType proofing tool: ftdiff)
On Wed, 2007-04-04 at 00:32 +0200, David Turner wrote: Hi Behdad, Hi David, I'm not sure if I understand what these lsb/rsb stuff is. Is there anything here that cairo/pango should be doing that it's not already? I'll try to summarize the issue as succintly as I can. Basically, rsb/lsb_delta correspond to the displacement of the right/left edges of a glyph due to auto-hinting, and they can be used to adjust inter-character spacing. - the rsb (right side bearing) is the distance between the right-most edge of a glyph and its advance. - the lsb (left side bearing) is the distance between the left-most edge of a glyph and its origin. - the space between the right-most and left-most edges of two consecutive glyphs, respectively, is always computed as rsb(glyph1) + lsb(glyph2) - Imagine that you have a pair of glyphs to display, like po Consider unhinted rendering, and let's assume that the scaled rsb of p is 0.3 pixels, and the scaled lsb of o is 0.45 pixels. This means that the right edge of the p and the left edge of the o should be spaced by 0.75 pixels, which is pretty close to 1 Consider auto-hinting, which tends to round these distances. Now, the rsb of p is 0, and the lsb of o is also 0. Both auto-hinted glyphs will appear stuck to each other the values of rsb_delta and lsb_delta simply tell us how the rsb/lsb changed due to the auto-hinting; we can compute the old inter-character space as: old_space = (rsb-rsb_delta) + (lsb-lsb_delta) = (rsb+lsb) - (rsb_delta+lsb_delta) = new_space - (rsb_delta+lsb_delta) so the sum of rsb_delta and lsb_delta corresponds to the inter-character space distortion that is due to the hinting. (rsb_delta+lsb_delta) = new_space - old_space If we find that it is bigger than a half pixel, we simply substract 1 to the new space in order to reduce the spacing error while preserving the grid-aligned rendering Similarly, if the error is smaller than -1/2 pixel, we increase the new space by 1. error = (rsb_delta(glyph1) + lsb_delta(glyph2)) if (error = 32) origin -= 64; else if (error = -32) origin += 64; the result is text that looks much better, as demonstrated by the ftdiff program. Note that you can mix this with scaled but unrounded kerning for maximal effect. The issue is that the lsb/rsb_delta values depend on the hinting mode, and current character size and need to be cached in order to get good performance (you can hardly recompute them quickly on each pair) So it means changing the caching scheme of any text layout library that wants to use it. Either store the values with the glyph images themselves, or in another table. Thanks a lot David. So this is something not currently implemented in our text rendering stack IIUC. I'll be thinking about it. Owen Taylor wrote a paper on this subject, with nice graphics explaining the issues. I can't find it anymore. I'm putting him in CC: in case he has it somewhere... Yeah, excellent stuff: http://people.redhat.com/otaylor/grid-fitting/ While looking for it, came across someone named Taylor Owen... Cheers, behdad Hope this helps, - David cheers behdad An alternative would be to hack FT_Get_Kerning to return adjusted values, but this would require implementing a rather complicated caching scheme within the engine if we don't want performance to suck horribly. Moreover, this is likely to break some libraries... - David -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New FreeType proofing tool: ftdiff
On Fri, 2007-03-30 at 10:47 -0400, David Turner wrote: I'd like to see this enhancement spreading as widely as possible. I've already tried to scan the Pango sources to see how to implement these, but I must say this is not an easy piece of code. Any help would be appreciated, there are countless other libraries to touch, like libXft, Cairo, FireFox, ThunderBird, OpenOffice.org, Poppler. This certainly not a small work, but I think the payoff can be quite big. Thanks David. Owen and I discussed this the other day and have the following plan to bring lsd/rsb deltas support to Pango: - In cairo 1.6, add API for a transparent or opaque cairo_glyph_metrics_t, that allows fetching rsb/lsb deltas for a glyph. - In pangofc, add backend methods for accessing them. - Use them in pango-ot-buffer.c:apply_gpos_*() and in pango_fc_font_kern_glyphs(). Search for PANGO_UNITS_ROUND in those functions in Pango trunk. I don't think it's worth implementing anything for cairo's toy text api. Cheers, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A question about freetype and harfbuzz
On Mon, 2007-05-28 at 01:48 -0400, LingNing Zhang wrote: Hi all, I have a question about freetype and harfbuzz. FreeType1 includes an extension to support OpenType text layout processing. But this support hasn't become part of FreeType2. Why? Why does FreeType2 not use the codes of harfbuzz to support OpenType text layout processing? Thanks! :) Hi Lingning, harfbuzz is in fact based on the OpenType Layout code salvaged from FreeType 1. The reason for not carrying it over to FreeType2 like Werner said is to let FreeType do one thing, and do it really good. behdad Regards, Lingning Zhang -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A question about freetype and harfbuzz
On Mon, 2007-05-28 at 02:34 -0400, [EMAIL PROTECTED] wrote: On Mon, 28 May 2007 13:48:20 +0800 LingNing Zhang [EMAIL PROTECTED] wrote: Hi all, I have a question about freetype and harfbuzz. FreeType1 includes an extension to support OpenType text layout processing. But this support hasn't become part of FreeType2. Why? Why does FreeType2 not use the codes of harfbuzz to support OpenType text layout processing? Thanks! # Personally, I'm one of the people who want FT2 to have # support for text layout feature. I guess I feel sympathy # with you. But we are minority among FT2 developers :-). Excuse me, HarfBuzz developers want FT2 to include built-in OT table parsers? Or, there is non-ICU/ non-HarfBuzz/non-M17NLib/non-Pango/non-Qt library their developers want FT2 to have OT table parser and don't want to copy such from existing libraries? No, no HarfBuzz developer wants that. The future is clear: HarfBuzz is the Linux OpenType Layout engine that Pango, Qt, and ICU will use. I'm currently in the process of (slowly) rewriting it to use mmap()ed font files instead of reading tables into memory. When I'm done with that, I'll revise the API and freeze it. There is further work to make HarfBuzz *the* shaper API for Linux systems. That is, again, Pango, Qt, ICU, Scribus, OO.o, etc all will be using HarfBuzz. This has been discussed extensively at the Text Layout Summit in Boston, and discussion is going on on the harfbuzz list and will be at the next Text Layout Summit at aKademy in a few weeks. This all probably takes a year or two to stabilize and released as a shared library, but what is two years anyway... On Mon, 2007-05-28 at 02:42 -0400, Werner LEMBERG wrote: Perhaps a misunderstanding: I don't object to make FreeType handle OpenType tables (see the validating stuff which we have developed together). However, I object to let FreeType interpret them -- this is really the job of a higher-level library. For the record, I think the ftvalid stuff is misplaced and doesn't belong in FreeType. Some of my concerns are similar to what David already raised. In short, I believe that any OpenType Layout engine should do its own validation, and has enough code to be able to do a validator very easily, and if mere font validation is desired, things like ttx already do it. I don't see where ftvalid is expected to be used. (that said, given that it's already in freetype, I don't mind it staying there.) Regards, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A question about freetype and harfbuzz
On Tue, 2007-05-29 at 11:52 +0900, [EMAIL PROTECTED] wrote: I'm glad to hear that. In addition, I'm not sure if validating OT-tables only is sufficient. For example, otvalid checks whether the substituted glyph ID by GSUB is within the range declared by maxp. I suppose HarfBuzz lets the handling of too-large glyph ID to the clients. I think it's reasonable because HarfBuzz parses and interprets only OT-tables. But from the client viewpoint, it's slightly inconvenient to check the glyphID by itself, after choosing a font to use. Most users don't have to deal with out-of-range glyphs at all. What happens is that they will see a box (glyph 0) instead. Font developers, ditto, they will see it and fix the font. Lets first identify who the target of the validator is. For validation-before-layout case, I really don't think using a validation code path separate from the actual layout path makes sense. On Mon, 28 May 2007 17:37:03 -0400 Behdad Esfahbod [EMAIL PROTECTED] wrote: There is further work to make HarfBuzz *the* shaper API for Linux systems. That is, again, Pango, Qt, ICU, Scribus, OO.o, etc all will be using HarfBuzz. This has been discussed extensively at the Text Layout Summit in Boston, and discussion is going on on the harfbuzz list and will be at the next Text Layout Summit at aKademy in a few weeks. Pango had already included HarfBuzz (as OpenType parser). I suppose Qt is also moving to adopt HarfBuzz. Although I could find the developers of other softwares (ICU, Scribus, OO.o) in Text Layout Summit 2006, I don't know the status and directions of them. Please let me know more about the migration movement. At present, Text Layout Summit 2007 page: http://www.freedesktop.org/wiki/TextLayout2007?highlight=%28%28HarfBuzz%29%29 has only 1 agenda of HarfBuzz. You can follow HarfBuzz activity on the harfbuzz mailing list. On Mon, 28 May 2007 18:05:19 -0400 Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 2007-05-28 at 23:48 +0200, Werner LEMBERG wrote: [...] I believe that any OpenType Layout engine should do its own validation, Why? What is bad about letting FreeType doing that? Afterwards you can omit any error handling... For one thing, FreeType is not necessarily available. We are removing FreeType dependency from HarfBuzz, and Qt wants to use HarfBuzz on Windows too. I think it's slightly different issue, because FT2 does work on Windows. I suppose Qt wants to use Windows native rasterizer instead of FT2, but Qt wants to use HarfBuzz shaping engine? Using OTLS is difficult? No idea. OTLS's API is not publicly documented. The other reason is that, for example, HarfBuzz is forgiving about some problems. A nonexistent lookup index for example is automatically ignored. Or a subtable that is not ever referenced can have an (invalid) offset of zero and it will still work. These kind of exceptions were added to make fonts that already worked with Windows work with Pango too. Hmm, the severity of ftvalid is controlled by validation level, although the fine tuning of default level for otvalid is not finished. Considering the fact most Open Type layout engine follows the behaviour of OTLS (to share existing OpenType font resources), I think it's not disadvantage of layout-engine-independent validation approach, like ftvalid. Rather, I think the OT-table validation in HarfBuzz will be one side of its runtime failsafe mechanism. I remember what I wrote 2 years ago: Apparently our opinions are different, but I don't see any problem with that. I'm putting my touch-typing fingers where my mouth is and developing an OpenType Layout engine that I think is right. I'll come back with a comparison when I'm done. Before then, there's not much to talk about. I have the fundamental problem of doesn't-belong-in-a-rasterizer though. If one finds a font that crashes or doesn't work with the HarfBuzz Layout engine, they should be able to fix it in HarfBuzz. With the validator code in freetype, they may need to fix FreeType. To me, it's like, donno, putting an hj engine in FreeType. It sure is text layout, and works nearly with fonts, but it's not rasterization. http://lists.gnu.org/archive/html/freetype-devel/2005-11/msg00084.html Another reason is that: if the text layout engine includes its own validator, it will be runtime checking to avoid from wrong behaviour and crashing, and won't validate unaccessed parts. It's not easy to use text layout functions to crawl all features declared in the OpenType/TrueTypeGX. Regards, mpsuzuki -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
On Wed, 2007-07-25 at 17:32 -0400, Werner LEMBERG wrote: I am using FT_Glyphslot_Embolden and so far it seems to work quite well. However, the default extra boldness (1/24 em) is too great for my purposes, and ought to be settable via an argument, because different values are needed at different times. For example, 1/32 em is adequate for making DejaVu Sans Bold extra-bold. I therefore suggest the following changes. This looks good. However, I think a default boldness would be nice to retain. For example, the value 0 could indicate this. What do you think? Another problem is backwards compatibility. Inspite of being declared as alpha code I fear that we no longer are in the situation to change the API because it is included by default into the library :-( What about adding a new function instead, say, FT_Glyphslot_Set_Emboldening, to change the embolding value? Given the emboldening sample in Maxim's recent article, can FreeType be made to have separate horizontal and vertical emboldening factors? Werner -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] (copy) Freetype to Cairo - newb needs help
On Tue, 2007-10-23 at 02:33 -0400, Werner LEMBERG wrote: 1. I want to use pure python. Hmm. If I remember correctly, a longer time ago there was a message about someone having written a python wrapper for FreeType. Whether this still exists or whether it is up to date, I don't know. Using ctypes it's quite easy: http://lists.cairographics.org/archives/cairo/2007-October/011700.html Basically, the freetype part comes down to: from ctypes import * ft_so = CDLL(libfreetype.so.6) ft_lib = c_void_p() assert 0 == ft_so.FT_Init_FreeType (byref (ft_lib)) ft_face = c_void_p() assert 0 == ft_so.FT_New_Face (ft_lib, fontfile, 0, byref(ft_face)) Werner -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: Problem enabling new language on gdm language selection list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Clasen wrote: For b), we basically ask fontconfig do you have fonts for this language ?. It seems that fontconfig says no if it doesn't know the language. It would be better if fontconfig could say I don't know in that case... One way to detect that fontconfig doesn't know about the language is by querying the newly added FcLangGetCharSet(). It returns NULL if it doesn't know. behdad -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkihqqgACgkQn+4E5dNTERU5NgCbB/wfDVWBqzQjMYJxqyvOKNRL kAgAn3WV+V9VDVugPJ4Psq6Qn02d4o66 =dhTm -END PGP SIGNATURE- ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Switching to Git ?
David Turner wrote: Hello everyone, long time no see :-) I'd like to know if Werner and others are interested in switching the FreeType repository to git in the near future ? That would also make it easier for me to hack on FreeType (the only piece of GNOME-based text rendering stack I've not mastered yet). behdad I've been a heavy user of the tool since several months, and while there are really a few bat-shit insane user-interface issues with it (even in most recent releases), it beats CVS hands down in nearly all respects. I'm currently maintaining my own git repo with git-cvsimport, which works pretty well, but would like the ability to directly talk to the main server that way. Nothing really of high priority, but I wanted at least to know your opinion about it ? Regards - David ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Open Type Font Support on Mobile Devices?
Hi, For OpenType complex shaping you need HarfBuzz [1]. Google engineers are working on using it for the Chromium port on Linux [2]. Using Pango with the FreeType backend is a simpler solution (Pango+FreeType uses HarfBuzz internally). If your primary use is to get Arabic rendering done, you can get away with using FriBidi2 [3] only. behdad [1] http://freedesktop.org/wiki/Software/HarfBuzz [2] http://lists.freedesktop.org/archives/harfbuzz/2009-March/000312.html [3] http://fribidi.freedesktop.org/ On 04/09/2009 05:19 AM, Waqar Ahmad wrote: Hi, Is there anybody who has been working on font related stuff on mobile devices? I am interested in getting Open Type Font (OTF) support on symbian, windows mobile devices and most likely on Android in future as well. As far as I know, Open Type Fonts (Arabic, Urdu etc.) are not supported on Symbian and Windows Mobile devices. FreeType does not support GSUB and GPOS. I am thinking about porting an existing open source OTF solution to mobile devices. A few possibilities that come in my mind are mentioned below and suggestions from members of this list are solicited. -Is there any good port of FreeType for Symbian and Windows Mobile available in open source? If it is there, I can try to further extend it to add required support for OTF. -If somebody has experience of working with Pango and consider it good for porting to mobile devices, this can be another option to explore. -Google Adroid is using FreeType, however, I don't know if they have added any support for OTF. One way could be to take FreeType from Android (assuming it would have been optimized for constrained mobile devices) and add support for OTF. I would highly appreciate suggestions and guidelines from this list on above matters. Best Regards, Waqar However, I am not sure if Open Type Font are completely supported or not in FreeType library. Specifically, I am interested in Urdu and Arabic languages support which require a number of rules for appropriate text rendering like glyph positioning and substitution. I want to know if such features are supported in FreeType library? If not, is there any other project in your knowledge that is working on something similar to what I am interested in? I will highly appreciate your guidance in this regard. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] dfont and TrueType collections
Hi, I had to fix a bug [1] in Pango and fontconfig where the ftglue-derived code was checking face-num_faces 1 to detect TrueType Collections. This fails with Apple dfont's where num_faces is the number of faces in different streams of the dfont and does not mean the current face is a TTC. Is this intentional or a bug in FreeType? Thanks, behdad [1] http://bugzilla.gnome.org/show_bug.cgi?id=577952 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] dfont and TrueType collections
On 04/09/2009 07:37 PM, mpsuz...@hiroshima-u.ac.jp wrote: Hi, On Thu, 09 Apr 2009 13:34:23 -0400 Behdad Esfahbodbeh...@behdad.org wrote: I had to fix a bug [1] in Pango and fontconfig where the ftglue-derived code was checking face-num_faces 1 to detect TrueType Collections. This fails with Apple dfont's where num_faces is the number of faces in different streams of the dfont and does not mean the current face is a TTC. Is this intentional or a bug in FreeType? It was intentional. The feature counting the faces in Apple Suitcase font format as if it were TTC had ever been implemented for MacOS, proposed by Paul Mirror: Understood. 2001-10-26 Leonard Rosentholleona...@lazerware.com * builds/mac/README: Updated to reflect my taking over the project and that is now being actively maintained. * src/base/ftmac.c (parse_fond): Applied patches from Paul Miller pa...@profoundeffects.com to support loading a face other than the first from a FOND resource. (FT_New_Face_From_FOND): Updated. But I sympathize with your dissatisfaction that FT2 provides no API to distinguish TTC and FOND. Although you already fixed Pango (and fontconfig?) to distinguish by checking the internal of the font file (I'm sorry!), do you need any functionalities in FT2? No, it's perfectly fine, as we were doing our own table lookup anyway. It's just that the ftglue code was making a wrong assumption. The patch was barely ten lines. behdad Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Relicensing otvalid?
Hi, I'm rewriting the OpenType Layout engine in HarfBuzz to use the mmap()ed font file directly. For that, I need a validator, which I'm also planning to write. In the mean time, I checked otvalid and the code looks very useful in writing mine. I wonder if the authors can relicense the otvalid code to the HarfBuzz license (aka old-MIT). That is, remove the FreeType advertisement clause. Thanks, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Relicensing otvalid?
On 04/21/2009 02:05 AM, Werner LEMBERG wrote: I wonder if the authors can relicense the otvalid code to the HarfBuzz license (aka old-MIT). That is, remove the FreeType advertisement clause. I think we can give you permission to use the code from the `otvalid' module with the HarfBuzz license (hoping to receive bug fixes :-), but within FreeType I don't want to do that. That's good enough. I'm mostly interested in looking at the code as I develop mine. As for bugs, well, I have some comments already. But I remember David having the same kind of concerns in general back when otvalid was being developed. In short, it's not clear to me what the audience for otvalid is. Is it to help font designers validate their tables only? The reason I can't use the code as is is that my code has a different idea of what is valid, or rather, good enough. It's fair to say that I'm not developing a validator, more like a sanitizer. For example, I don't care if the format specifier of a subtable is invalid, since my lookup code will simply ignore that table. One place I found otvalid being too strict is that it checks that glyph ids are valid by making sure the font has such a glyph. This is not required by the spec AFAIK, and indeed, multiple tables can use invalid glyph ids ephemerally to simply case handling. I'll come back with more as I explore the code more closely. Thanks, behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Free-Type and Windows 7 beta data
On 05/13/2009 11:18 AM, Werner LEMBERG wrote: I don't know how this can be done (since I'm not a Windows developer); however, there are some FontConfig people reading this list whom I ask to forward your report to the developers who take care of the Windows port of FontConfig. Wendy, I'm forwarding your message to people who typically do fontconfig win32 builds. Do you think what application exactly is doing this? I'm guessing The GIMP. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ftstring crashes with uming
Hi, Someone reported to me that some fonts, including uming.ttf crash ftstring. The crash seems to happen in the FTC code and I'm not familiar with that part of the code base. Anyone care to check? The following crashers were reported: /usr/share/fonts/chinese/TrueType/ukai.ttf /usr/share/fonts/chinese/TrueType/uming.ttf And on 64-bit architectures also: /usr/share/fonts/zh_TW/TrueType/bsmi00lp.ttf Thanks, behdad ___ 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 11/12/2009 06:59 AM, Russell Hay wrote: ...has this 'removed the restrictions on distributing the the bytecode interpreter? That's my understanding, yes. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fwd: FreeType patented bytecode interpreter now in rawhide
FYI. Original Message Subject: FreeType patented bytecode interpreter now in rawhide Date: Thu, 03 Dec 2009 19:13:42 -0500 From: Behdad Esfahbod beh...@behdad.org To: Development discussions related to Fedora fedora-devel-l...@redhat.com, fedora-fonts-list fedora-fonts-l...@redhat.com Hi, Since the patents covering the TrueType bytecode interpreter expired at the end of October, I've now built FreeType in rawhide with that part of code enabled. Note that the subpixel stuff remains disabled as it was. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Open Type Font Support on Mobile Devices?
Hi Maggy, First, you would need FriBidi or another bidi implementation even if you use HarfBuzz. Next, for Arabic shaping, FriBidi does a very basic job of that, with no advanced substitution/positioning involved and hence no need for GSUB/GPOS tables. For anything more than basic Arabic you need HarfBuzz. behdad On 01/24/2010 10:30 PM, Maggy Anastasia wrote: Hi Behdad, At the moment I am trying to use HarfBuzz (and FreeType) to deal with these tables. The only reason for me to do so (at least at current moment) is to render Arabic font correctlly. you mentioned that if the primary use is to get Arabic rendering, I can use FriBidi only to do so. Does FriBidi2 needs advance typography tables (GPOS, GSUB, etc) as input? I looked at the interface of fribidi, it seems to me that freebidi output is independent from font files (ttf or otf) and that the information regarding glyph substitution, joining, etc is already defined in a built in lookup table (please correct me if I am wrong). If this is the case, if I want to render the arabic text using certain font, is it true that for glyph positioning, i would still need to use the information in GPOS table, thus requiring me to use HarfBuzz and FreeType? I am so sorry if my question is too basic, I have no prior knowledge on Arabic typography. I am basically in need of enlightenment on when to use fribidi, harfbuzz and freetype and whether I should combine any of these in this situation. best regards Maggy Anastasia Suryanto Hi, For OpenType complex shaping you need HarfBuzz [1]. Google engineers are working on using it for the Chromium port on Linux [2]. Using Pango with the FreeType backend is a simpler solution (Pango+FreeType uses HarfBuzz internally). If your primary use is to get Arabic rendering done, you can get away with using FriBidi2 [3] only. behdad [1] http://freedesktop.org/wiki/Software/HarfBuzz [2] http://lists.freedesktop.org/archives/harfbuzz/2009-March/000312.html [3] http://fribidi.freedesktop.org/ On 04/09/2009 05:19 AM, Waqar Ahmad wrote: Hi, Is there anybody who has been working on font related stuff on mobile devices? I am interested in getting Open Type Font (OTF) support on symbian, windows mobile devices and most likely on Android in future as well. As far as I know, Open Type Fonts (Arabic, Urdu etc.) are not supported on Symbian and Windows Mobile devices. FreeType does not support GSUB and GPOS. I am thinking about porting an existing open source OTF solution to mobile devices. A few possibilities that come in my mind are mentioned below and suggestions from members of this list are solicited. -Is there any good port of FreeType for Symbian and Windows Mobile available in open source? If it is there, I can try to further extend it to add required support for OTF. -If somebody has experience of working with Pango and consider it good for porting to mobile devices, this can be another option to explore. -Google Adroid is using FreeType, however, I don't know if they have added any support for OTF. One way could be to take FreeType from Android (assuming it would have been optimized for constrained mobile devices) and add support for OTF. I would highly appreciate suggestions and guidelines from this list on above matters. Best Regards, Waqar However, I am not sure if Open Type Font are completely supported or not in FreeType library. Specifically, I am interested in Urdu and Arabic languages support which require a number of rules for appropriate text rendering like glyph positioning and substitution. I want to know if such features are supported in FreeType library? If not, is there any other project in your knowledge that is working on something similar to what I am interested in? I will highly appreciate your guidance in this regard. ___ Freetype-devel mailing list addr...@hidden http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] freetype.com
Stumbled upon freetype.com by accident. Have people seen this before? Interesting... behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Patented bytecode interpretter and fallback to autohinter
Hi, In Fedora rawhide I enabled the patented bytecode interpretter a while ago since the patents expired. I've received reports since that this has resulted in degraded rendering of some fonts. Apparently, from what I hear, with Medium hinting, the autohinter is not used even if the font doesn't have any bytecode. The desired behavior is to use the autohinter for any glyphs without bytecode hints. Please see: https://bugzilla.redhat.com/show_bug.cgi?id=547532 Is there any way we can resolve this? Otherwise I'd have to turn it back off again. Thanks, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patented bytecode interpretter and fallback to autohinter
On 02/23/2010 08:26 PM, Werner LEMBERG wrote: Basically, I think this is a FontConfig issue; all TrueType fonts which need autohinting should be configured as such. I understand your stance. However, having to configure fonts individually is something we have tried to avoid before. On the other hand I see the problem you have. However, there is currently no possibility (built into FreeType, I mean) to find out whether a font has TrueType hints or not. It's straightforward to add such a function, and FontConfig might use it during the creation of the cache. That would be useful, yes. What kind of interface would you like to have? I can imagine that you want to check the presence of a font's hinting instructions for a given range of input codes (not that I would really like this, but...) Not really. A yes/partial/no answer should be enough. Do you think this is something we can get in soon? If yes, I can get the fontconfig parts in. Probably need some cairo work also. I'll probably revert it in Fedora since getting all the pieces working may take a bit longer. Thanks, behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patented bytecode interpretter and fallback to autohinter
On 02/24/2010 06:19 PM, Werner LEMBERG wrote: Not really. A yes/partial/no answer should be enough. why do you need a `partial' if there is no possibility to find out which ranges are hinter or unhinted? What I want to use this info for is to be able to write configurations that say if the font doesn't have bytecode hinting, then enable the autohinter. Now one should ask where should the line for has / doesn't has be drawn... I don't know. What I know is that: - A font having hints for all but a few glyphs should be considered yes. - A font having hints for just a few should be considered no. No idea about the in-between. That's what I called maybe. But it's not a very flexible API. Another way would be to get the number of hinted glyphs. I'm not sure. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patented bytecode interpretter and fallback to autohinter
On 02/25/2010 05:21 PM, Werner LEMBERG wrote: No idea about the in-between. That's what I called maybe. But it's not a very flexible API. Another way would be to get the number of hinted glyphs. I'm not sure. Sounds sensible. The arguments could be `start' and `end' of a range (or (-1,-1) to indicate that we want the hinted glyphs of the whole font, regardless of the CMap); the return value could the number of hinted glyphs. Something like that. Not quite sure yet. Maybe others can provide some ideas? behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?
On 03/01/2010 09:18 PM, mpsuz...@hiroshima-u.ac.jp wrote: How about using if ( face-stream-read == NULL ) instead of if ( face-stream-base != NULL ) Yes, that's what I'm planning to do instead. Checking the source code, I wonder if I should also check for (face_flags FT_FACE_FLAG_EXTERNAL_STREAM) to detect whether it's an mmapped stream or the user provided it (and hence we cannot mprotect). The docs say: Don't read or test this flag. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?
On 03/05/2010 02:26 AM, mpsuz...@hiroshima-u.ac.jp wrote: Checking the source code, I wonder if I should also check for (face_flags FT_FACE_FLAG_EXTERNAL_STREAM) to detect whether it's an mmapped stream or the user provided it (and hence we cannot mprotect). The docs say: Don't read or test this flag. Please let me know more detail about what the information is needed at the part. Yet I'm not understanding the idea of blob in HarfBuzz. Well, in short, all the hb_blob_t in HarfBuzz is about communicating to harfbuzz what it can do with the memory backing the font file. There are three different cases we are interested in: - The memory is read-only; harfbuzz will make a copy if it needs to modify it. - The memory is writable and it is ok to write to it. harfbuzz will not make a copy. - The memory is read-only, but can be made writable using mprotect() or similar (win32, ...) functionality. HarfBuzz only makes changes to the font data if it detects corrupt fonts. The changes are NOT meant to be written back to the font file. Currently the hb-ft glue layer assumes that font data is mmap()ed or are otherwise mprotect()able. This fails for examples when: - Font data is in ROM. In this case mprotect() will fail and harfbuzz will make a copy of the memory. Not a huge problem. - FreeType malloc()ed the font data. In this case, mprotect() is not necessary and will probably affect memory beyond the font data (since mprotect works on whole pages). - Font data is coming from the user. In this case it may not be desirable to modify the data. Adding API to FTStream to be able to detect the above cases, specially the user-provided data, would be useful. Thanks, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion)
On 03/15/2010 01:44 AM, mpsuz...@hiroshima-u.ac.jp wrote: On Sun, 14 Mar 2010 21:19:44 -0400 Behdad Esfahbod beh...@behdad.org wrote: On 03/11/2010 02:47 AM, mpsuz...@hiroshima-u.ac.jp wrote: Attached (get-stream-info.diff) is a revised patch with a feature to get the info about the origin of the memory in FT_Stream object, which is inspired by recent discussion with Behdad about mprotect() to the buffer in FT_Stream object. Sample code (get-stream-info.c) invokes the new APIs FT_Get_MemInfo_From_Stream() and FT_Get_Path_From_Stream() then shows results, aslike: Thanks! Looks interesting. I don't see the mmap() in there though. What am I missing? I'm sorry for poor description, you missed nothing. get-stream-info.c does not invoke mmap() by itself, it reports if FT_Face-stream-base is allocated by mmap(), ft_alloc(), static buffer (for Amiga). If it is mmap()ed, it should be read only. If it is ft_alloc()ed, it can be modified without changing font file. I understand that. I didn't see the code for returning mmap allocation type in the patch though. I'm sure I just missed it. Otherwise, looks like something I can use, yes. Thanks. Considering with another comment from you on my idea restricting memory allocation methods in FT_Face object creation, I have to switch this direction. Sounds good! # One of my concern (except of the code size) is that APIs # like FT_Get_Path_From_Stream() is a bad idea from the # viewpoint of software design, and it can encourage badly- # designed FT2 clients. FT_Get_MemInfo_From_Stream() might # not be so bad, but it could conflict with the philosophy of # the encapsulation of FT_Stream. I definitely had this concern myself when the Get_Path API was being discussed. I think the stream meminfo is different however. And as Werne pointed out, seems like getting the path is also something people find useful anyway (oh and you have no idea how useful it would be for debugging!), so lets add them. Thanks, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion)
On 03/15/2010 08:36 AM, mpsuz...@hiroshima-u.ac.jp wrote: FT_EXPORT( FT_Error ) FT_Object_Get_Property( FT_Librarylibrary, FT_Pointerobject, const char* object_type, const char* property_name, FT_Pointer* property, const char** property_type ); Ok, now I think this is a bit over-engineering it :). It looks more like Python than FreeType! I think the previous API was more inline with FreeType's API design. In another note, since you seem to be writing a lot of FreeType patches recently, it doesn't hurt to ask: have you ever considered implementing reference counts for FreeType? That would be very highly appreciated by all the building blocks sitting on top of FreeType! I know at least cairo, harfbuzz, and pango have gone way out of their way to work around this. Cheers, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: Reference count in FreeType2
On 03/15/2010 11:43 PM, mpsuz...@hiroshima-u.ac.jp wrote: However, yet I've not figured out the detailed usecase for reference counter of FreeType2 (so I cannot write short testing code), thus I cannot start working just now. If you know any softwares showing the problem caused by the lack of reference counter, please let me know. Should I compare older newer cairo? Use case is very simple: with the FreeType stack, all of hb_face_t, PangoFont, and cairo_scaled_font_t all can use keeping a pointer to an FT_Face. But alas, one cannot do that safely since you never know when the face is going away. So this is how they deal with it currently: - Cairo: For cairo-created faces, it adds a ref-counted wrapper around it itself. For user-provided faces, it's user's responsibility to make sure the FT_Face is not finalized before the cairo_face_t (which is refcounted). - harfbuzz: It's user's responsibility to make sure the face is available. - Pango: Lacking refcounts is not the only problem FT_Face. The other is that it also includes a FT_Size and a glyph slot in it. Pango currently uses a lock/unlock scheme (exported by Cairo) to get exclusive access to the FT_Face and release it every time the FT_Face is needed. If there was refcounts in FreeType, harfbuzz could increment the refcount on the FT_Face it keeps a pointer to. Cairo could also increase the refcount of user-provided faces such that the face wouldn't die after FT_Done_Face() was called but cairo still has a pointer to it. In general, to be binding friendly, and programmer friendly, any library should provide refcounting to make it easier to tie object lifecycles together. Try writing a Python binding for FreeType to see how impossible that is. FreeType currently has a generic-data pointer with a destroy callback and both Pango and harfbuzz use that slot to cache some stuff on the face, and they race over the use of the slot of course. Attaching user data to objects is another useful feature of object systems. Both glib and cairo provide that (but not harfbuzz yet). That's also very useful for bindings. behdad Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: Reference count in FreeType2
On 03/16/2010 02:05 AM, Werner LEMBERG wrote: Use case is very simple: with the FreeType stack, all of hb_face_t, PangoFont, and cairo_scaled_font_t all can use keeping a pointer to an FT_Face. But alas, one cannot do that safely since you never know when the face is going away. Again: What would you like as an interface? Something like a function `FT_Face_IsAlive', returning a boolean? Nope. FT_Reference_Face(). That increments the refcount. Then FT_Done_Face() should decrement the refcount and only destroy if it drops to zero. Refcount is initialized to 1 when face is constructed. And of course these should be done using atomic operators. Same about FT_Library and any other object worth keeping around. But those two are the major ones. If there was refcounts in FreeType, harfbuzz could increment the refcount on the FT_Face it keeps a pointer to. Since my knowledge is quite poor here, can you point me to a library which implements something along this? Any of HarfBuzz, cairo, glib, fontconfig. But I think the description above should be enough to implement it. Of course that doesn't make FreeType threadsafe, but it does immensely simplify life-cycle management. behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
On 05/05/2010 08:55 AM, David Bevan wrote:
And how /should/ FreeType be used for vertical writing mode?
This is how cairo handles it:
/*
* Translate glyph to match its vertical metrics.
*/
static void
_cairo_ft_scaled_glyph_vertical_layout_bearing_fix (void*abstract_font,
FT_GlyphSlot glyph)
{
cairo_ft_scaled_font_t *scaled_font = abstract_font;
FT_Vector vector;
vector.x = glyph-metrics.vertBearingX - glyph-metrics.horiBearingX;
vector.y = -glyph-metrics.vertBearingY - glyph-metrics.horiBearingY;
if (glyph-format == FT_GLYPH_FORMAT_OUTLINE) {
FT_Vector_Transform (vector, scaled_font-unscaled-Current_Shape);
FT_Outline_Translate(glyph-outline, vector.x, vector.y);
} else if (glyph-format == FT_GLYPH_FORMAT_BITMAP) {
glyph-bitmap_left += vector.x / 64;
glyph-bitmap_top += vector.y / 64;
}
}
behdad
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
On 05/25/2010 11:26 AM, David Bevan wrote:
Thanks for the feedback on this.
Does anyone have access to any PDF files which contain vertical writing mode
text? If so, would it be possible to send some to me off-line?
Not me. But I'm also interested in receiving those.
behdad
Thanks.
David %^
-Original Message-
From: Behdad Esfahbod [mailto:behdad.esfah...@gmail.com] On Behalf Of Behdad
Esfahbod
Sent: 05 May 2010 20:40
To: David Bevan
Cc: freetype-devel@nongnu.org; Antony Bush; Stephen Brazier; Houjie Tu
Subject: Re: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
On 05/05/2010 08:55 AM, David Bevan wrote:
And how /should/ FreeType be used for vertical writing mode?
This is how cairo handles it:
/*
* Translate glyph to match its vertical metrics.
*/
static void
_cairo_ft_scaled_glyph_vertical_layout_bearing_fix (void
*abstract_font,
FT_GlyphSlot glyph)
{
cairo_ft_scaled_font_t *scaled_font = abstract_font;
FT_Vector vector;
vector.x = glyph-metrics.vertBearingX - glyph-metrics.horiBearingX;
vector.y = -glyph-metrics.vertBearingY - glyph-metrics.horiBearingY;
if (glyph-format == FT_GLYPH_FORMAT_OUTLINE) {
FT_Vector_Transform (vector, scaled_font-unscaled-Current_Shape);
FT_Outline_Translate(glyph-outline, vector.x, vector.y);
} else if (glyph-format == FT_GLYPH_FORMAT_BITMAP) {
glyph-bitmap_left += vector.x / 64;
glyph-bitmap_top += vector.y / 64;
}
}
behdad
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Problem with ligatures and strikes
Hi, The Calibri font shipped in Windows XP has bitmap strikes for a variety of sizes, but from what I understand, no bitmap glyphs for many ligature combination it defines in its GSUB table, for example, for 'tt', 'ft', 'ffi' among others. That results in very ugly rendering (see attached). My question is, how does Windows deal with this? Do they turn certain features off if using strikes? Not form the ligature if not found in the current strike? I need help understanding this to implement the correct behavior since I don't have access to Windows. behdad attachment: strike.png___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: Reference count in FreeType2
On 07/18/10 12:43, Werner LEMBERG wrote: I've now implemented FT_Reference_Face and FT_Reference_Library. Please test. Wow, thanks! What a timing... Last week I started working for Google, and I was in Mountain View. I finally met David Turner for the first time, and the first thing I brought up about FreeType was refcounting, or lack thereof. Werner, since you seem to have psychic powers, can you please fix the other things I talked about with David? :-D Cheers, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] latest patch file for spline flattening
On 09/12/10 09:36, Werner LEMBERG wrote: Werner, can you give a ruling on whether assignments in conditionals are allowed in FreeType code? If it is allowed in C89, then everything's fine. Please post the final version I shall commit (I assume that your git access still doesn't work...) I'd rather assignments are moved outside the expressions. Makes code more maintainable. My 0.02CAD behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Cache subsystem question
On 09/26/10 11:17, Gernot Reisinger wrote: Hi there, I am using Freetype for an embedded project and I have an issue with the cache subsystem. In my FTC_Face_Requester callback I create the fonts from memory with FT_New_Memory_Face. The font memory is dynamically allocated. I understand that FT_Face objects are managed by the cache subsystem including FT_Face destruction with FT_Done_Face. As there is no way to detect when the cache invokes FT_Done_Face, I can not deallocate the memory buffers holding the font data. Any idea how to solve that issue? You can register a callback by setting face-generic. behdad Thanks, Gernot ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
You need HarfBuzz. On 11/06/10 04:36, 丁力 wrote: OK. Thanks. do you know any other small open source library can do this job? i just want to display the vertical characters, the layout engine is to big for me. 2010/11/6 Werner LEMBERG w...@gnu.org mailto:w...@gnu.org i want to display Japanese characters in vertical mode. in some opentype font, i only can get some bracket glyphs in vertical mode by gsub table such as the MS Mincho. i found that it seems no APIs in freetype to translate the horizontal glyph to vertical mode by gsub. does anyone can tell me how to do it? You can't do that directly. It's not the job of FreeType. Instead, you should use a higher-level library like ICU, Pango, or Qt to apply OpenType features to text strings. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
On 11/08/10 19:59, 丁力 wrote: There is a message in the HarfBuzz website: There are no releases available for download yet, but we expect to start 0.x release soon and aim for a 1.0 release with stable API around March 2011. You can clone the git repo for now. Firefox and Pango already use it. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
On 11/12/10 07:56, Алексей Подтележников wrote: Let's face it. It's only you and me who understand these conditions. Not really. The rest of us just don't care. Because it's just a Bezier flattener after all... No personal attacks on this list. We're grown ups. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
[+harfbuzz list, Kenichi Handa] On 11/06/10 05:22, mpsuz...@hiroshima-u.ac.jp wrote: Hi, To parse OpenType tables at low level and obtain the substituted glyph index, libotf might be useful. http://www.m17n.org/libotf/ Interesting. I had totally forgotten about libotf. I hope now that new harfbuzz is in a usable state Kenichi abandons the libotf and helps with harfbuzz. behdad It does not provide the database of the tags of script, language and features, and no dependency/conflict checker of each features. So libotf client programmer have to read OpenType spec and choose appropriate script/language/feature to apply to the serie of the glyph index. Regards, mpsuzuki On Sat, 06 Nov 2010 09:50:28 +0100 (CET) Werner LEMBERG w...@gnu.org wrote: do you know any other small open source library can do this job? No. i just want to display the vertical characters, the layout engine is to big for me. Then load the GSUB table with FT_Load_Sfnt_Table and parse the data by yourself. This is rather straightforward. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
On 11/13/10 05:28, Miles Bader wrote: Behdad Esfahbod beh...@behdad.org writes: Interesting. I had totally forgotten about libotf. I hope now that new harfbuzz is in a usable state Kenichi abandons the libotf and helps with harfbuzz. Do they do the same thing? From the description it sounds like libotf is much smaller and more focused, and might be more appropriate for someone that only wants to get file info (which seems to have been the case for the original poster on this thread). HarfBuzz does everything that libotf does and much more. And is less than twice the size (70kb vs 120kb). The libotf-like API is in hb-ot.h. Maybe you're thinking of libm17n; that looks closer to harfbuzz in functionality. That too. [BTW, is harfbuzz actually used anywhere yet? I can't seem to find it in Debian...] We have not made tarball releases yet because 1. it's changing fast and 2. the API is not stable yet. But we plan to reach a stable 1.0 before March. Firefox 4 betas ship with HarfBuzz included. And the harfbuzz-ng-external branch of Pango moves forward with the master branch of harfbuzz. behdad -Miles ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
On 11/16/10 22:47, Kenichi Handa wrote: I too want to switch from libotf to harfbuzz, but at the moment, harfbuzz is not released as an independent library (and APIs are still changing), I can't catch a good timing to shift to harfbuzz. Good to know. Maybe you're thinking of libm17n; that looks closer to harfbuzz in functionality. That too. I really hope to use libm17n's shaping engine from harfbuzz. A few years ago, I asked you to include libm17n-based shaping module in Pango, but there have been no progress, perhaps because Pango is going to use harfbuzz's shaping engines, right? And, when I checked harfbuzz code a while ago, it seems that shaping engines are builtin (i.e. not by loadable modules). Don't you have a plan of making it possible that harfbuzz can use the other loadable shaping engine? For HarfBuzz, I do plan to support other backends. The final design will perhaps be a bit different, but it will be coming. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] family_name for the font without ASCII names
On 01/07/11 00:45, suzuki toshiya wrote: Hi, Recently I found a group of Japanese fonts that requires hinting even for ASCII characters, for readable results: http://lists.gnu.org/archive/html/freetype-devel/2010-12/msg00021.html During the registration of them to tricky font lists, I found that these fonts lack ASCII family name. Their name tables are for MacJapanese (ShiftJIS) and Microsoft Unicode. In both names, the family names are in Japanese, not English. In such case, current FreeType2 replaces non-ASCII character in non-ASCII family name by ?. Thus, FT_Face-family_name is set by broken string. There is a possibility that the different fonts will have same broken family name. However, the PostScript name of the fonts I found are still in ASCII. I think, a few improvements would be possible. Generally, we don't care if a font does not have an ASCII name. What we care about is that the name and the name encoding are consistent and hence we can decode and meaningfully represent the name in Unicode. Why would that fail with these fonts? behdad A) If we cannot find ASCII family name from WWS family name, preferred family name and (original) family name, try to find ASCII name in PostScript name. B) Non-ASCII characters should not be replaced by ?, but escaped, like \OOO or \xXX or U+. # Using both is possible. Such changes will invalidate the fontconfig database, so I want to ask the comment from fontconfig developers/users. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
On 03/01/11 22:24, Werner LEMBERG wrote: Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... I agree with David :). I guess warping may produce superior results if combined with correct lsb/rsb adjustment. But Firefox/Pango currently don't do that. So you get awful kerning between, say, ee in the example. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Improve FT_MulFix
On 04/05/11 17:04, James Cloos wrote: WL Looks good, thanks! WL Please redo the patch so that the old code gets saved within a #if 0 WL ... #endif clause (to stay as a reference), (having the old code in the repo’s history is not enough? :^) I agree with James. Disabled code only clutters the code base... behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
Hi, Every user of FreeType that I know has once in their lifetime hit the bug that with many common CJK fonts, non-CJK characters take doublewidth where they should take a single one. The fix always has been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the fonts have the bit set wrongly. A monospace CJK font is never monospace. It has single-width glyphs, and double-width, hence setting global-advance is wrong in the font. But since this is such a common issue, I wonder if FreeType should simply ignore global advance by default. Cairo and fontconfig always pass that flag to FreeType. I've seen this bug hit Qt before. And most recently I watched it hit Skia. What do you think? behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
On 04/20/11 03:11, Werner LEMBERG wrote:
Every user of FreeType that I know has once in their lifetime hit
the bug that with many common CJK fonts, non-CJK characters take
doublewidth where they should take a single one. The fix always has
been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the
fonts have the bit set wrongly. A monospace CJK font is never
monospace. It has single-width glyphs, and double-width, hence
setting global-advance is wrong in the font.
But since this is such a common issue, I wonder if FreeType should
simply ignore global advance by default. Cairo and fontconfig
always pass that flag to FreeType. I've seen this bug hit Qt
before. And most recently I watched it hit Skia.
I've already pondered about this problem, but I've found no solution
which guarantees backwards compatibility. Your idea of completely
ignoring this flag didn't come to my mind :-)
Since your suggestion sounds sensible, could you provide a patch?
Attached. You also need to update the ft2demos that use it to remove the
option (ftdiff, etc).
behdad
Werner
commit 544aeed84bd287a6897e341025c8a15dcbc29361
Author: Behdad Esfahbod beh...@behdad.org
Date: Wed Apr 20 14:52:12 2011 -0400
Always ignore global advance
This makes FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH redundant, deprecated,
and ignored. The new behavior is what every major user of FreeType
has been requesting. Global advance is broken in many CJK fonts.
Just ignoring it by default makes most sense.
diff --git a/builds/unix/install-sh b/builds/unix/install-sh
old mode 100644
new mode 100755
index a5897de..6781b98
--- a/builds/unix/install-sh
+++ b/builds/unix/install-sh
@@ -1,7 +1,7 @@
#!/bin/sh
# install - install a program, script, or datafile
-scriptversion=2006-12-25.00
+scriptversion=2009-04-28.21; # UTC
# This originates from X11R5 (mit/util/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
@@ -515,5 +515,6 @@ done
# eval: (add-hook 'write-file-hooks 'time-stamp)
# time-stamp-start: scriptversion=
# time-stamp-format: %:y-%02m-%02d.%02H
-# time-stamp-end: $
+# time-stamp-time-zone: UTC
+# time-stamp-end: ; # UTC
# End:
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index b9e34e2..3956676 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -2444,13 +2444,7 @@ FT_BEGIN_HEADER
* in fonts. By default, FreeType tries to handle broken fonts also.
*
* FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH ::
- * Indicates that the font driver should ignore the global advance
- * width defined in the font. By default, that value is used as the
- * advance width for all glyphs when the face has
- * @FT_FACE_FLAG_FIXED_WIDTH set.
- *
- * This flag exists for historical reasons (to support buggy CJK
- * fonts).
+ * Ignored. Deprecated.
*
* FT_LOAD_NO_RECURSE ::
* This flag is only used internally. It merely indicates that the
diff --git a/src/truetype/ttdriver.c b/src/truetype/ttdriver.c
index d723b57..fd30661 100644
--- a/src/truetype/ttdriver.c
+++ b/src/truetype/ttdriver.c
@@ -135,8 +135,6 @@
{
FT_UInt nn;
TT_Face face = (TT_Face) ttface;
-FT_Bool check = FT_BOOL(
- !( flags FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH ) );
/* XXX: TODO: check for sbits */
@@ -149,7 +147,7 @@
FT_UShort ah;
-TT_Get_VMetrics( face, start + nn, check, tsb, ah );
+TT_Get_VMetrics( face, start + nn, tsb, ah );
advances[nn] = ah;
}
}
@@ -161,7 +159,7 @@
FT_UShort aw;
-TT_Get_HMetrics( face, start + nn, check, lsb, aw );
+TT_Get_HMetrics( face, start + nn, lsb, aw );
advances[nn] = aw;
}
}
diff --git a/src/truetype/ttgload.c b/src/truetype/ttgload.c
index b2cab01..7923c6b 100644
--- a/src/truetype/ttgload.c
+++ b/src/truetype/ttgload.c
@@ -65,22 +65,16 @@
/*/
/* */
- /* Returns the horizontal metrics in font units for a given glyph. If */
- /* `check' is true, take care of monospaced fonts by returning the */
- /* advance width maximum.*/
+ /* Returns the horizontal metrics in font units for a given glyph. */
/* */
FT_LOCAL_DEF( void )
TT_Get_HMetrics( TT_Face face,
FT_UInt idx,
- FT_Bool check,
FT_Short* lsb,
FT_UShort* aw )
{
( (SFNT_Service)face-sfnt )-get_metrics( face, 0, idx, lsb, aw );
-if ( check face-postscript.isFixedPitch )
- *aw = face-horizontal.advance_Width_Max;
-
FT_TRACE5
[ft-devel] Improving documentation re vertical metrics
Hi, I'm adding vertical text support to HarfBuzz and it occurred to me that FreeType's vertBearingY and vertAdvance metrics have a Y coordinate growing downwards, while all other Y coordinates in FreeType grow upwards. Thought that may be worth documenting. Cheers, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Improving documentation re vertical metrics
On 05/18/11 12:21, Werner LEMBERG wrote: I'm adding vertical text support to HarfBuzz and it occurred to me that FreeType's vertBearingY and vertAdvance metrics have a Y coordinate growing downwards, while all other Y coordinates in FreeType grow upwards. Thought that may be worth documenting. Could you provide a patch, please? How about this: diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h index 3956676..602e475 100644 --- a/include/freetype/freetype.h +++ b/include/freetype/freetype.h @@ -226,10 +226,12 @@ FT_BEGIN_HEADER /* Left side bearing for vertical layout. */ /* */ /*vertBearingY ::*/ - /* Top side bearing for vertical layout.*/ + /* Top side bearing for vertical layout. Larger positive values*/ + /* mean further below the vertical glyph origin.*/ /* */ /*vertAdvance :: */ - /* Advance height for vertical layout. */ + /* Advance height for vertical layout. Positive values mean the*/ + /* glyph has a positive advance downward. */ /* */ /* Note*/ /*If not disabled with @FT_LOAD_NO_HINTING, the values represent */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
On 06/15/11 06:28, Werner LEMBERG wrote: Finally, there is the problem of glyphs which can't be addressed with a cmap directly, like small caps which are activated by an OpenType feature. Similar to FreeType's autohinter, such glyphs don't get any special consideration and are treated by the default hinting module (in FreeType this is the `cjk' module currently, and in ttfautohint it can be either `dummy' or `latin', to be controlled by another yet-to-be-written configuration option :-). This is quite a generic problem and needs separate attention; for the moment it is beyond my work on ttfautohint. With HarfBuzz it's quite easy to list every glyph that can be accessed through, say, the 'latn' GSUB table. I probably can provide some API for such introspection. That may solve your ttfautohint problem, but not FreeType's. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
On 06/17/11 23:53, Werner LEMBERG wrote: If I understand you correctly, there currently isn't a possibility to get such info from HarfBuzz easily (if at all)? No, currently there isn't. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] character spacing
On 09/19/11 01:21, Louis Desjardins wrote: Also - as I have already invested much time in Freetype I no longer have time to integrate a different library such as Pango - is there somewhere I can obtain freely distributable TTF files that contains kerning information that can be handled by Freetype? I'm guessing that you don't want kerning. You want the glyph advance widths. I'm just guessing that you are stacking bitmaps next to eachother, using the bitmap width as the advance vector. That's wrong. When saving the bitmaps, also save face-glyph-advance.x. behdad Thank-you! -- From: lost_bits1...@hotmail.ca To: w...@gnu.org CC: freetype-devel@nongnu.org Subject: RE: [ft-devel] character spacing Date: Sun, 18 Sep 2011 22:15:58 -0700 Thanks for your reply - Note, however, that today many fonts contain kerning in the GPOS table which is not handled by FreeType. Instead, you have to use a higher-level library like Pango or ICU. FT_HAS_KERNING will return true for these types of fonts? When I call, FT_Get_Kerning, the akerning value always gets set to (0,0), which from the sample code on freetype.org, looks like is an error. Could this indicate that the kerning information is in the 'GPOS' table? How can I know for sure, or is there a way to debug this? Thank-you again! Date: Mon, 19 Sep 2011 07:10:24 +0200 To: lost_bits1...@hotmail.ca CC: freetype-devel@nongnu.org Subject: Re: [ft-devel] character spacing From: w...@gnu.org In order to draw my text, I currently make calls to: FT_Get_Char_Index FT_Load_Glyph FT_Render_Glyph and then I store the bitmap of each ascii character to memory, so that once I actually render the character, I can simply call on the stored bitmap. The problem is that the character spacing is not correct. It looks like I need to use FT_Get_Kerning to correct this, however from the examples I've seen, it looks like I need to call this before FT_Load_Glyph, i.e. at the time when I am storing each of my characters. However, I have no idea what strings will be rendered, until runtime, so I don't know the 'left_glyph' and 'right_glyph' parameters in FT_Get_Kerning beforehand. Is there a way to make use of FT_Get_Kerning while drawing my bitmap (after I've already loaded the glyph and retrieved its bitmap), in order to achieve proper character spacing at runtime? Have a look at the ftstring demo program to see how simple kerning works. You can call `FT_Get_Kerning' whenever you want; it is completely unrelated to `FT_Render_Glyph'. Note, however, that today many fonts contain kerning in the GPOS table which is not handled by FreeType. Instead, you have to use a higher-level library like Pango or ICU. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ANN] Freetype/OpenGL (with good rendering quality)
Hi Nicolas, This is great stuff! Humm, may I suggest that you write a PangoRenderer implementation around this? You can then render any language... behdad On 09/21/11 06:55, Nicolas Rougier wrote: Hi Folks, You might be interested in the following code that allow to render freetype font using OpenGL with quite good quality (IMHO): http://code.google.com/p/freetype-gl/ There are examples for infinite zoom, subpixel positioning, gamma correction... I got most ideas from the antigrain library: http://www.antigrain.com/research/font_rasterization/ (the demo-atg-agg.c tries to reproduce the truetype_test from this article) Nicolas ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Get_Advance() docs
Hi, In Chromium, there's a bug being discussed right now about what the expected return value of FT_Get_Advance() is: http://code.google.com/p/chromium/issues/detail?id=66073 Testing suggests that it returns glyph-linearHoriAdvance, not glyph-advance.x. This is understandable, but unintuitive and not documented. In fact, the following suggests that FT_Get_Advance() may in fact take hinting into account: /*/ /* */ /* Const */ /*FT_ADVANCE_FLAG_FAST_ONLY */ /* */ /* Description */ /*A bit-flag to be OR-ed with the `flags' parameter of the */ /*@FT_Get_Advance and @FT_Get_Advances functions.*/ /* */ /*If set, it indicates that you want these functions to fail if the */ /*corresponding hinting mode or font driver doesn't allow for very */ /*quick advance computation. */ /* */ /*Typically, glyphs which are either unscaled, unhinted, bitmapped, */ /*or light-hinted can have their advance width computed very */ /*quickly. */ /* */ /*Normal and bytecode hinted modes, which require loading, scaling, */ /*and hinting of the glyph outline, are extremely slow by*/ /*comparison.*/ /* */ #define FT_ADVANCE_FLAG_FAST_ONLY 0x2000UL But apparently it doesn't. At any rate, would be nice to document what exactly is it that FT_Get_Advance() returns, and what tests can the client use to determine whether what FT_Get_Advance() returns matches glyph-advance.x. Cheers, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] harfbuzz experience anyone ?
On 01/05/2012 04:13 AM, Nicolas Rougier wrote: Hi all, Hi Nicolas, Does anybody has some experience in using the harfbuzz (http://freedesktop.org/wiki/Software/HarfBuzz) library with freetype ? I cloned the old version (harfbuzz.old, because the new one is not stable nor documented) but I did not find running examples. The contrib directory has some harfbuzz-freetype.c but I did not find how to actually use it and I would like to provide shaping for displaying font in freetype-gl (http://code.google.com/p/freetype-gl/). I actually suggest that you get the new version. Checkout the hb-shape tool, it gives you ideas how to you it. Ideally, I would like to write a function that takes a font filename, a font size and a string to be rendered and the function would return all the required glyphs codepoint and probably the advance information (but since I'm no specialist, I'm not sure this even makes sense). You can do that. But note that it would only work for left-to-right languages. behdad Nicolas ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType License and patents
On 01/13/2012 02:13 PM, Werner LEMBERG wrote: Comments? Are you willing to do the work to make sure no FreeType contributor currently has a patent on code they have contributed? Changing the license for upcoming contributions is a welcome addition to me, without the hassle of relicensing. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType License and patents
On 01/18/2012 10:08 PM, Alexei Podtelezhnikov wrote: On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG w...@gnu.org wrote: 3. Grant of Patent License. Do freetype authors hold or have they filed for a patent? Don't you need it first before granting any patent license? This is one strange and curious discussion thread without a patent at hand. There is a difference between patent and copyright. Patent means royalties, copyright does not. There is no need to change a license. I do not think so. Offlist. Would have been interesting if, say, David, had patents, so then when Apple started shipping FreeType maybe we didn't have to fear their patents affecting FreeType so much... behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] emboldening rework v1
On 04/09/2012 09:23 PM, Alexei Podtelezhnikov wrote: In memory of Paul Alexi As a way of ping, I going to throw in a much simpler FT_Outline_Get_Orientation patch. So the whole collection of three patches now looks like the attached. Comments, suggestions? I like the area-based algorithm. I had to implement outline orientation code recently and I wish I had remembered that algorithm! What I found in testing my implementation was that fonts don't have consistent contour orientation. From what I understand: - TrueType fonts have even-odd fill rule and fill-right orientation, - Type1 fonts have zero-winding fill rule and fill-left orientation. Now *if* TrueType outlines are really fill-right, then even-odd and zero-winding rules are the same. But I've came across many fonts where TrueType outlines are even-odd, not fill-right. I'm guessing that you want to return ORIENTATION_NONE in those cases. But finding them is not easy with your algorithm. Maybe we don't care really. What I ended up doing was implement both even-odd rule and winding rule and compare the results. I was doing this on arc splines though, not Beziers. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] emboldening rework v1
Humm. The docs say: /*FT_OUTLINE_EVEN_ODD_FILL ::*/ /* By default, outlines are filled using the non-zero winding rule. */ /* If set to 1, the outline will be filled using the even-odd fill */ /* rule (only works with the smooth rasterizer).*/ This sounds wrong to me. I'm fairly sure that FreeType by default does EVEN_ODD, not WINDING. /* */ /*FT_OUTLINE_REVERSE_FILL :: */ /* By default, outside contours of an outline are oriented in */ /* clock-wise direction, as defined in the TrueType specification. */ /* This flag is set if the outline uses the opposite direction */ /* (typically for Type~1 fonts). This flag is ignored by the scan */ /* converter. */ This is consistent with EVEN_ODD being the case, not WINDING. behdad On 04/10/2012 02:45 PM, Alexei Podtelezhnikov wrote: On Tue, Apr 10, 2012 at 11:54 AM, Behdad Esfahbod beh...@behdad.org wrote: I like the area-based algorithm. I had to implement outline orientation code recently and I wish I had remembered that algorithm! What I found in testing my implementation was that fonts don't have consistent contour orientation. From what I understand: - TrueType fonts have even-odd fill rule and fill-right orientation, - Type1 fonts have zero-winding fill rule and fill-left orientation. Now *if* TrueType outlines are really fill-right, then even-odd and zero-winding rules are the same. But I've came across many fonts where TrueType outlines are even-odd, not fill-right. I'm guessing that you want to return ORIENTATION_NONE in those cases. But finding them is not easy with your algorithm. Really, there are *two* questions. 1. What is the orientation? 2. What is the appropriate fill rule? The area based algorithm is more than sufficient to determine the orientation. Freetype seem to separate the two concepts as well (FT_OUTLINE_EVEN_ODD_FILL is not the same as FT_ORIENTATION_TRUETYPE), but then mixes them up again in the function description by referring to fill orientation. I agree that there is a connection that some fonts decided to ignore. So what is the purpose of this function? Are we interested in the orientation of the fill rule? Maybe we don't care really. Surprisingly, FT_Oultine_Get_Orientation is not used to render the outlines. The smooth rendered flips the negative sing and puts a ceiling on the coverage above 1 without thinking twice. I do not even know what filling rule that is. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] emboldening rework v1
On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote: When we talk about an outline as a collection of contours, things get out of control very quickly Yes, and that's what confused me. I'm still trying to figure out all the details, to reply to your message in more detail. Cheers! behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] On contour directions and fill rules (was Re: [patch] emboldening rework v1)
Ok, I *was* seriously misguided. I think I understand things now. Let me summarize for posterity. What puzzled me before is that I came across fonts that have both TrueType orientation and Type1 orientation in the same glyph (but separate from eachother), and FreeType handles them fine. It didn't occur to me until now that separate parts of the glyph can have different winding direction and that's fine for a nonzero-winding fill rule. So, each glyph outline is a collection of contours. Each contour has a direction: clockwise or counter-clockwise. The contour direction can be determined in a few ways. Finding an extreme point and probing the edge angles is one. Using the signed area is another. Now there are different fill rules: - Even-odd rule: from any point, draw a halfline in any desired direction, add 1 every time the halfline crosses a contour. Fill if total number is odd, don't fill otherwise. - Non-zero winding rule: from any point, draw a halfline in any desired direction, add +1 or -1 every time the halfline crosses a contour, depending on the direction of the crossing. Fill if total number is nonzero, don't fill otherwise. Now. *if* the outline is not self-intersecting and doesn't have degenerate contours, then filling a glyph designed to be filled with nonzero winding rule with the even-odd rule generates the same outcome. A degenerate contour is one that does not change the rendering if removed. For example, if you have a clockwise circle, and another clockwise circle fully inside it, the second circle is degenerate because the rendering is one fully filled circle with or without it. With this assumption, one can show that the halfline to infinity ought to flip between in and out at each crossing, hence this being the same as the even-odd rule, and the contours being crossed are CW/CCW alternatively. Now, if we are dealing with such nice glyphs, and the outer outlines all have the same direction, then we can use simpler filling rules. For example, for such well-formed TrueType outlines, you can have a fill-right rule: - Fill-right rule: find the closest outline, fill if the point is to the right of the outline, don't fill otherwise. So, that's what mainly confused me. Because my rasterizer is in fact a fill-right rule. Now there are three if's so far: - There are no degenerate contours. I'm just going to assume this. Have not seen any in the wild so far. - All outer contours have the same direction. I've seem many glyphs in the wild violating this. Letter A' in MonsieurLaDoulaise-Regular.ttf from Google Font Directory is just one example. The good news is, this can be detected and fixed. And I'm going to fix my code to do that. - No self-intersection. Now, when one says self-intersecting, one has to qualify. I was under the impression that assuming outlines are not self-intersecting was a safe assumption. However, I'm convinced now that this is absolutely false assumption. I'm convinced otherwise now. I'd say assuming that each *contour* is non-self-intersecting is safe, but I'm going to guess that many well-constructed font will have overlapping contours for the c-cedilla character. Any font creating that glyph as a composite glyph is going to have this problem. There are two different contours, both clockwise, that partially intersect. And filling this with fill-right or even-odd is plain wrong. Only non-zero winding rule can render this correctly. And now I guess these cases are exactly why non-zero winding was chosen over even-odd originally. And indeed, my rasterizer cannot handle ccedilla in Droid Sans Regular right now. One way to fix it I guess would be to detect those and render the two outlines as if they were separate glyphs. Needs more work, more math, and some graph algorithms to separate the contours into separate subglyphs... Not impossible, though clumsy... That's it. Ok, now wouldn't be fair to not reveal my rasterizer after all this talk. It's a project I've been working on for a while, and many interested parties already know about it. I was holding off announcing publicly until a driver issue in mesa could be fixed. There's a patchset for that now, so I'll go ahead and announce the project right after this email. I will also be presenting it at LGM and GUADEC. Cheers! behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] On contour directions and fill rules
On 04/19/2012 03:11 PM, Werner LEMBERG wrote: A small remark: - No self-intersection. Now, when one says self-intersecting, one has to qualify. I was under the impression that assuming outlines are not self-intersecting was a safe assumption. However, I'm convinced now that this is absolutely false assumption. Yep. I'd say assuming that each *contour* is non-self-intersecting is safe, ... No, it's not. Especially after applying TrueType bytecode some outlines can be (intentionally) extremely distorted at small sizes. Right. Thanks for clarifying. I mostly care about original glyph outlines right no. And about your rasterizer: I will also be presenting it at LGM and GUADEC. Which talk is this? I fear I will be only able to attend on May 3rd in the afternoon. It's on May 2nd 17:00. I can present it to you over beer on May 3rd. Ok, here's the project, until I write a real announcement email today or tomorrow: http://code.google.com/p/glyphy/ BTW, what's the main difference to the FreeType rasterizers? Or have you been able to reuse some code? It competes with freetype-gl really. It's a GPU rasterizer. The main different with freetype-gl is that I don't do any sampling, so the glyphs are truly infinitely zoomable. The downside is that I do much (orders of magnitude) more math in the fragment shader, and do more texture lookups. That said, it runs at a decent frame rate already. If trying this on intel Linux, you need mesa with this patchset or the shaders wouldn't compile: http://lists.freedesktop.org/archives/mesa-dev/2012-April/020721.html behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] On contour directions and fill rules
On 04/20/2012 12:31 AM, Werner LEMBERG wrote: It competes with freetype-gl really. It's a GPU rasterizer. The main different with freetype-gl is that I don't do any sampling, so the glyphs are truly infinitely zoomable. Nice! No time to look at it more closely, but I've recently skimmed over a paper which uses wavelet transformation to achieve something similar Yes, I saw that exchange, but have not read it yet. (the paper was mentioned on this list a few days ago). Maybe you are something into this direction also? Not really, for this I just wanted to avoid signal processing by all means :). Essentially, it's a generic SDF rasterizer, like freetype-gl is, but instead of using a 2D sample to represent the SDF, we use circular-arc splines. So, essentially, what GLyphy does is: - Convert glyph outlines to bunch of circular arcs, - Build a datastructure to make it fast finding which arc is closest given a point, - Upload these all to the GPU, do the math in the fragment shader. The devil is in the corner cases of course. And in making it fast. behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] emboldening rework v1
On 04/24/2012 11:07 PM, Alexei Podtelezhnikov wrote: As I said, the ideal solution for you is to avoid this currently-broken API and just flip the negative sign like ftgrays.c does on line 1243. That's all there is to it. Right. I'm not planning to use this function to begin with. And I'm not concerned with how broken the current broken implementation is. I'm talking about what ideally it should look like. Anyway. I'll report on my progress in making a perfect version of that function. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Seams with disjoint composite
Hi, I was playing with Unicode box characters, and noticed that DejaVu Sans creates the glyph for ▟ out of three quadrant boxes. At different sizes I can see very noticeable seams where the sub-glyphs meet. I thought FreeType would handle these cases better, but seems like I'm wrong. Any ideas? Does FreeType combine all contours together and rasterize them in one pass, or raster them separately and combine? Cheers, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
On 06/05/2012 01:56 AM, Werner LEMBERG wrote: I was playing with Unicode box characters, and noticed that DejaVu Sans creates the glyph for ▟ out of three quadrant boxes. At different sizes I can see very noticeable seams where the sub-glyphs meet. I thought FreeType would handle these cases better, but seems like I'm wrong. Any ideas? Does FreeType combine all contours together and rasterize them in one pass, or raster them separately and combine? They are rasterized in a single pass. However, the DejaVu font doesn't contain the necessary bytecode to properly handle the rounding issues which inevitably happen if subglyphs are combined -- in ftview, press key `f' to force autohinting, and you won't see seams. I've just confirmed that exactly the same issue is present with the Windows rasterizer, so it's not a FreeType problem. Thanks Werner for looking into this! Great time for asking then: are subglyph positions rounded as part of the hinting process? behdad Of course, a much simpler (and probably even better) solution is to avoid subglyphs if they touch at longer lines. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
BTW, checkout DejaVuSans at 4pt. I see all kinds of triangular artifacts. On 06/07/2012 12:40 PM, Behdad Esfahbod wrote: On 06/05/2012 01:56 AM, Werner LEMBERG wrote: I was playing with Unicode box characters, and noticed that DejaVu Sans creates the glyph for ▟ out of three quadrant boxes. At different sizes I can see very noticeable seams where the sub-glyphs meet. I thought FreeType would handle these cases better, but seems like I'm wrong. Any ideas? Does FreeType combine all contours together and rasterize them in one pass, or raster them separately and combine? They are rasterized in a single pass. However, the DejaVu font doesn't contain the necessary bytecode to properly handle the rounding issues which inevitably happen if subglyphs are combined -- in ftview, press key `f' to force autohinting, and you won't see seams. I've just confirmed that exactly the same issue is present with the Windows rasterizer, so it's not a FreeType problem. Thanks Werner for looking into this! Great time for asking then: are subglyph positions rounded as part of the hinting process? behdad Of course, a much simpler (and probably even better) solution is to avoid subglyphs if they touch at longer lines. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
On 06/07/2012 03:25 PM, Werner LEMBERG wrote: Great time for asking then: are subglyph positions rounded as part of the hinting process? It depends on a flag in the glyph's data, ROUND_XY_TO_GRID, if the subglyph's offset is given as xy values. However, for the particular DejaVu glyph, the subglyphs all have a zero offset, but point coordinates are rounded to integers anyways as part of the normal rasterization process. Right. So I guess my question is, why are they rounded differently? Excuse my total ignorance of the 'glyf' table part of OpenType! behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
On 06/07/2012 04:20 PM, Werner LEMBERG wrote: BTW, checkout DejaVuSans at 4pt. I see all kinds of triangular artifacts. Not my problem :-) According to the font's gasp table, hinting should be switched off below 9pt. See attachment. Yes, I know. I can only repeat: The bytecode goes havoc because it doesn't work at this size. This is *not* a problem! The gasp table tells you not to do that. Alternatively, can't FreeType do that itself? I know previously you've had said that FreeType exposes gasp table, and that FreeType just does what you tell it. Previously I agreed with that. But now I think it makes sense to disable bytecode if gasp says so. IMO, applications should only need to tell FreeType whether to hint or not, whether to antialias or not, and not know about the details of TrueType or other formats. FreeType should abstract that away. *If* then need full control though, FreeType can allow that too. behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
On 06/07/2012 04:20 PM, Werner LEMBERG wrote: BTW, checkout DejaVuSans at 4pt. I see all kinds of triangular artifacts. Not my problem :-) According to the font's gasp table, hinting should be switched off below 9pt. See attachment. Yes, I know. I can only repeat: The bytecode goes havoc because it doesn't work at this size. This is *not* a problem! The gasp table tells you not to do that. Ah, now I see what you mean. Ok, maybe I should go back and vouch for that gasp-table patch for cairo. behdad Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
On 06/07/2012 05:47 PM, Werner LEMBERG wrote: I wonder how such glaring problems can be part of one of the most used free fonts. That was my first thought too. Of course, I only noticed this because I made hb-view print ANSI-art if outputting to a terminal! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Seams with disjoint composite
Filed here: https://bugs.freedesktop.org/show_bug.cgi?id=50848 behdad On 06/07/2012 05:47 PM, Werner LEMBERG wrote: It depends on a flag in the glyph's data, ROUND_XY_TO_GRID, if the subglyph's offset is given as xy values. However, for the particular DejaVu glyph, the subglyphs all have a zero offset, but point coordinates are rounded to integers anyways as part of the normal rasterization process. Right. So I guess my question is, why are they rounded differently? I spoke too hastily since I hadn't looked closely enough at the subglyphs. It's a bug in the font. The glyph ▟ consists of three elements: TTGlyph name=uni259F xMin=-20 yMin=-512 xMax=1593 yMax=1576 component glyphName=uni2596 x=0 y=0 flags=0x1004/ component glyphName=uni2597 x=0 y=0 flags=0x1004/ component glyphName=uni259D x=0 y=0 flags=0x1004/ /TTGlyph Note that the 4 in the flags value 0x1004 means ROUND_XY_TO_GRID. Now the components. The first one is a real glyph: TTGlyph name=uni2596 xMin=-20 yMin=-512 xMax=786 yMax=532 contour pt x=-20 y=-512 on=1/ pt x=-20 y=532 on=1/ pt x=786 y=532 on=1/ pt x=786 y=-512 on=1/ /contour /TTGlyph The other two, however, are not: TTGlyph name=uni2597 xMin=787 yMin=-512 xMax=1593 yMax=532 component glyphName=uni2596 x=807 y=0 flags=0x1004/ /TTGlyph TTGlyph name=uni259D xMin=787 yMin=532 xMax=1593 yMax=1576 component glyphName=uni2596 x=807 y=1044 flags=0x1004/ /TTGlyph Both have the flag 0x1004, meaning that the offsets are rounded to the grid... The real solution is to redefine uni259F (and all other similar block characters) having uni2596 three times as subglyphs, with proper offsets, and with flags values 0x1000. I've justed tested it: no gaps. I wonder how such glaring problems can be part of one of the most used free fonts. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Fontforge-devel] Peter Wiegel's auto spacing idea
On 06/15/2012 01:49 AM, Werner LEMBERG wrote: I think, that could work like this: the software has to build and you conture around any glyphe, in a way that the distance to the outline of the glyphe is depending on its form, so that the new outline is closer to sharp edges then to straight lines. this could be done in the way I have described in the attached graphic. First I have made a pixel copy of my letters. Then I have blurred this little picture and after that I had reduced all the gray pixels to black. this new picture can be traced, so I get a new outline around my glyphes. The next step is to move all the glyphs to gether, until the new outline we get in touch, so it must be possible to calculate a good value for this kerning pair. this could be done automatically with all glyphs in the font, or even with all possible combinations in any language. Sounds nice. I think it's not necessary to trace at all: Since kerning for Latin fonts works in the horizontal direction only, it's fully sufficient to work with the blurred bitmaps, shifting two glyphs together until they touch. It would be nice to see a font specimen sheets with kerns computed this way, using various blurring radii. I've been thinking about this approach for a couple years. Never got to try it. Mine is more mathematically rigorous, but really very similar. Essentially: convolve the glyph with a gaussian, then for any two glyphs, you want to set them next to eachother such that the integral of the gaussians for the two glyphs shifted and multiplied is a certain number. The width of the gaussian, and the certain number give you two axes to adjust 1) general spacing, and 2) how spacing functions around acute corners compared to straight lines. BTW, an approximation of it can be done using analytical algorithms instead of bitmapping. Maybe I give it a try finally. At any rate, someone has explored this space extensively already. I never got to read what he exactly does, has been on my TODO list. Checkout iKern. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Fontforge-devel] Peter Wiegel's auto spacing idea
On 06/15/2012 02:48 PM, msk...@ansuz.sooke.bc.ca wrote: I don't have a link for just the documentation file describing this, but both the code and the PDF user manual explaining how it works are in the Tsukurimashou distribution package available here: Ah, great. Thanks for sharing. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Fontforge-devel] Peter Wiegel's auto spacing idea
http://charlesmchen.github.com/typefacet/topics/autokern/index.html On 06/15/2012 03:20 PM, Nathan Willis wrote: My understanding is that the auto-kerning implemented by Zapf's Hz-program is now patent-free due to 2010 patent expiration. Is anyone familiar with the approach used there? URW supposedly published a book about it, but only in Germany (and doubtless in less-than-Twilight quantity). I've looked for a copy before, without success Nate On Fri, Jun 15, 2012 at 1:48 PM, msk...@ansuz.sooke.bc.ca mailto:msk...@ansuz.sooke.bc.ca wrote: On Thu, 14 Jun 2012, Vernon Adams wrote: This is very interesting, reminds me of David Kindersley's work on 'optical spacing'. I think that spacing for web and screen fonts could be dealt with like this fairly straightforward because of the role that the pixel grid plays in determining final rendered spacing. Would be interesting to test it. Also thinking this could be built into an app like robofont very easily - would just need to add a blur effect etc to the glyphs in spacing mode. could that be done in fontforge too? Using freetype or pango? There's code in my Tsukurimashou package that implements an auto-kerning algorithm serving a similar purpose to these ideas but with a few more features. The general idea is that I first calculate a left and right contour for each glyph; the contours follow the actual shape of the glyph except that there's a limit on how shallow the contour angles can be. Then to kern a pair, I compute a distance measure between the contours equal to the average inverse cube of the distance between the left and right glyphs' contours. The glyphs are kerned to make that measure equal to a constant. Using the actual shapes of the glyphs, even smoothed, is undesirable because it can result in one glyph sliding too far under another, for instance between apostrophe and period; those two can never be pushed together far enough to make them touch because they don't share any subset of the vertical extent. My existing code still needs some tweaking for this kind of situation, but the slope limit helps a lot. A glyph like . is in effect kerned as if it looked like / and \ on its two sides, preventing it from sliding too far under any other glyph. Using until the contours touch is undesirable because it places too much weight on the single point of closest approach, which may not be visually significant. This effect is visible in serif fonts with pairs like AV, where there may be serifs that should be brought much closer together than the distance you would generally want for flat parts of glyphs; auto-kerning algorithms in general tend to put such pairs too far apart because of putting too much weight on the serifs. You want to give some weight to both the nearest-approach points, and other parts of the glyphs that may be a little further apart; that requires something a little softer than a pure touch/don't touch test. Blurring may be intended to serve a similar purpose, but my own code uses nonlinear weighting on the hard outlines in order to produce a more controllable effect. The exponent of 3 seems to produce the most appealing results in my tests. As I mentioned, there are still some issues with glyphs that have very little vertical extent, such as apostrophe. I've also found that the adjustable parameters in the algorithm need to be different for Latin, Japanese, and Korean glyphs, in order to produce results that mix well with each other. The spacing readers expect between characters in those writing systems is simply different. I don't have a link for just the documentation file describing this, but both the code and the PDF user manual explaining how it works are in the Tsukurimashou distribution package available here: http://en.sourceforge.jp/projects/tsukurimashou/downloads/54223/tsukurimashou-0.5.zip/ -- Matthew Skala msk...@ansuz.sooke.bc.ca mailto:msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fontforge-devel mailing list fontforge-de...@lists.sourceforge.net mailto:fontforge-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fontforge-devel --
Re: [ft-devel] Ligature support in Freetype?
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, and so my next big mystery is .. how would I integrate something like harfbuzz on top of our freetype2 usage in order to gain a ligature feature? I understand this is a stupid question, potentially, so I'll keep researching this, and reading some code to try to understand the approach to solving the problem .. but if anyone feels motivated to explain to me how I might approach this, I'd be very grateful. Here's a simple example: https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Ligature support in Freetype?
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 some study. Thanks for the pointers! Well, this doesn't compile out of the box. Behdad, have you seen this my mail to the HarfBuzz list which contains a patch? I did. I don't maintain that file however. We should add a minimal HarfBuzz + FreeType + Cairo example to HarfBuzz. Any volunteers? behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Ligature support in Freetype?
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 ‘hb_language_from_string’ /usr/local/include/harfbuzz/hb-common.h:123:1: note: declared here Seems like you have a very old version of HarfBuzz. I just pushed a snapshot here: http://www.freedesktop.org/software/harfbuzz/release/ behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Ligature support in Freetype?
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 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 On Jun 27, 2012, at 2:37 PM, Behdad Esfahbod wrote: 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 ‘hb_language_from_string’ /usr/local/include/harfbuzz/hb-common.h:123:1: note: declared here Seems like you have a very old version of HarfBuzz. I just pushed a snapshot here: http://www.freedesktop.org/software/harfbuzz/release/ behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] WOFF support in FreeType?
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 typical Linux development environment... behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] optimal configuration to render fonts using gamma correction
On 07/31/2012 01:51 PM, Francesco Abbate wrote: I believe that gamma correction is necessary to render properly antialiased graphics but when I render the text with gamma correction it looks too much light, almost washed out. An extremely powerful way to evaluate whether your gamma is correct is to use fore / back colors of the same luminosity but different hue. Then if your gamma is correct, the blending edges should have the same luminosity as the fore / back colors. See for example: http://people.freedesktop.org/~sandmann/srgb.png BTW, I've observed the same behavior that you observed in GLyphy. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] supporting coloured bitmaps in FreeType
On 08/15/2012 11:10 AM, Werner LEMBERG wrote: The idea is to add just two modes (for the moment - no need to be over-elaborate) to FT_Pixel_Mode, for premultiplied ARGB, and the same format using 8-bit indexes into a palette. These modes are convenient when creating bitmap fonts from PNG images. [...] This sounds great! Are you going to implement this? Is there any common font format for these? b Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
