[ft-cvs] freetype2 ChangeLog builds/unix/ftconfig.in src...
CVSROOT:/cvsroot/freetype Module name:freetype2 Changes by: Werner LEMBERG wl 06/08/27 08:03:46 Modified files: . : ChangeLog builds/unix: ftconfig.in src/otvalid: otvmod.c Log message: * builds/unix/ftconfig.in: Synchronize with main ftconfig.h. Reported by Jens. Formatting. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype2/ChangeLog?cvsroot=freetyper1=1.1370r2=1.1371 http://cvs.savannah.gnu.org/viewcvs/freetype2/builds/unix/ftconfig.in?cvsroot=freetyper1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/freetype2/src/otvalid/otvmod.c?cvsroot=freetyper1=1.7r2=1.8 ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ChangeLog include/freetype/internal/f...
CVSROOT:/cvsroot/freetype Module name:freetype2 Changes by: Jens Claudius jclaudius 06/08/27 11:26:18 Modified files: . : ChangeLog include/freetype/internal: ftobjs.h src/base : ftdbgmem.c ftobjs.c src/bdf: bdflib.c src/gxvalid: gxvmod.c Log message: 2006-08-27 Jens Claudius [EMAIL PROTECTED] Fix miscellaneous compiler warnings. * freetype2/include/freetype/internal/ftobjs.h: close comment with `*/' to avoid `/* in comment' compiler warning. * freetype2/src/base/ftdbgmem.c (ft_mem_table_get_source): Turn cast `(FT_UInt32)(void*)' into `(FT_UInt32)(FT_PtrDist)(void*)' since on 64-bit platforms void* is larger than FT_UInt32. * freetype2/src/base/ftobjs.c (t_validator_error): cast away volatileness of argument to ft_longjmp. Spotted by Werner `Putzfrau' Lemberg. * freetype2/src/bdf/bdflib.c (bdf_load_font): initialize local variable `lineno'. * freetype2/src/gxvalid/gxvmod.c (classic_kern_validate): mark local variable `error' volatile. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype2/ChangeLog?cvsroot=freetyper1=1.1371r2=1.1372 http://cvs.savannah.gnu.org/viewcvs/freetype2/include/freetype/internal/ftobjs.h?cvsroot=freetyper1=1.103r2=1.104 http://cvs.savannah.gnu.org/viewcvs/freetype2/src/base/ftdbgmem.c?cvsroot=freetyper1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/freetype2/src/base/ftobjs.c?cvsroot=freetyper1=1.257r2=1.258 http://cvs.savannah.gnu.org/viewcvs/freetype2/src/bdf/bdflib.c?cvsroot=freetyper1=1.30r2=1.31 http://cvs.savannah.gnu.org/viewcvs/freetype2/src/gxvalid/gxvmod.c?cvsroot=freetyper1=1.6r2=1.7 ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft] Tweaking/Improving FreeType Antialiasing
I've never been terribly happy with the antialiasing under various Linux distributions. I'm not sure if this is a personal preference issue or what, but suffice to say, it has been my largest complaint about using Linux on the desktop - the fonts look like utter crap to me. I can adapt to different interfaces - there are pluses and minuses to every way of doing something - but the anti-aliasing under Linux has always been kind of like going from Lindt chocolate to Hershey's chocolate, at least to me. I'm particularly leaning towards Fedore Core 5 as the distribution in which I wish to apply improved anti-aliasing. My first assumption regarding the anti-aliasing was that it was related to the disabling of auto-hinting. So I looked into ways to enable the bytecode interpreter. ( http://www.carcosa.net/jason/blog/computing/ fonts-2006-04-19-20-12.html ) But that doesn't seem to really change the rendering much. Let me show you a screenshot from FC5 with subpixel anti-aliasing, using the MS Verdana font and FreeType 2.1.10 with bytecode on: http://zinkconsulting.com/fc5-bytecode.png Now, take a look at it under OS X - same font - with lighter and normal settings with subpixel anti-aliasing using the standard OS X font rendering: http://zinkconsulting.com/osx-lighter.png http://zinkconsulting.com/osx-aa.png There are flaws, in my view, with the OS X rendering, but it is (to me) an absolute night and day improvement over the stuff in FC5. Similarly, Adobe's CoolType (when properly configured) can look pretty much as good as OS X as well. Is it even possible to get FreeType rendering text that even comes close to the OS X screenshots? If it's not possible with FreeType, is there some library I could drop in place of FreeType to get text that (to me) actually looks really good? I do realize people have difference preferences in terms of the look/ feel of their fonts, but hopefully you can help me achieve the appearance I'm seeking. Any thoughts would be much appreciated... Thanks, Galen ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
Tor, Thanks for taking the time to respond, and sorry for the double post. I accidently sent from the wrong email address, but apparently somebody was nice enough to approve it for posting. If I'm reading your post correctly, you're basically saying that getting text that looks the way I want is hopeless. I'm very sensitive to font appearance, but I'm not intimately familiar with all the terminology. It sounds like Linux has an API limitation? And this API limitation is what in turn makes the fonts look so miserable? (In my view.) Regarding turning off hinting, wasn't that the default setting under FC5? I'm fairly sure I experimented around with turning on hinting (auto/bytecode) because the FC5 default was off. I wasn't happy with the FC5 default settings, not by a long shot. If true, this sucks for me, because frankly, fonts are a big deal to me. I have to stare at them nonstop. I would nearly kill to get a browser that looks like Safari (or another OS X WebKit-based browser) under Linux. Even under OS X, Mozilla-based browsers have horrendous kerning - particularly of italic serif fonts. I love the feature set, but the kerning turns me off - despite using the system anti-aliasing - so I can't stand to use Mozilla more than the bare minimum. Maybe I'm an idiot, but I think one the largest barriers to using Linux on the desktop for me is the maddening font rendering quality. Where precisely is the problem coming in? Would it be possible to use an alternative desktop or window manager to get around it? I did look at the examples you showed me. The first example looks somewhat better than what I normally see under Linux. The kerning is pleasant and the anti-aliasing appears to be strong enough to offer an accurate rendering of the text for that point size, although it has a distinctly soft/blurry look compared to 10.4's subpixel anti- aliasing, much like fonts looked under earlier versions of Mac OS X. I would be curious how well those settings work across a wide range of fonts. Any additional thoughts/suggestions? -Galen On Aug 27, 2006, at 5:24 AM, Tor Andersson wrote: On 8/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [snip] There are flaws, in my view, with the OS X rendering, but it is (to me) an absolute night and day improvement over the stuff in FC5. Similarly, Adobe's CoolType (when properly configured) can look pretty much as good as OS X as well. Is it even possible to get FreeType rendering text that even comes close to the OS X screenshots? If it's not possible with FreeType, is there some library I could drop in place of FreeType to get text that (to me) actually looks really good? To get OS X like text, you have to disable hinting. (This is a truth with some modification. Since OSX 10.3 there is some very subtle hinting going on in OSX to align horizontal stems with the pixel grid. In versions prior to 10.3 all text was rendered completely unhinted.) It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Add this snippet to your fonts.conf: match target=font edit name=hinting mode=assignconstfalse/const/edit /match It's not FreeType's fault that Linux text looks bad. For reference, with FreeType 2 it is possible to get the kind of text quality displayed in the screenshots on this web page: http://ccxvii.net/gargoyle/screenshots.html Here I use FreeType2 to render text unhinted, taking in account the fractional position of each glyph within the pixel (ie, the render of a character is different depending on whether it starts at pixel coordinate 0.0 or 0.2 or 0.7, for example). I also apply a 5-component wide LCD coloring filter. Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On Sat, 2006-08-26 at 23:54 -0700, [EMAIL PROTECTED] wrote: I've never been terribly happy with the antialiasing under various Linux distributions. I'm not sure if this is a personal preference issue or what, but suffice to say, it has been my largest complaint about using Linux on the desktop - the fonts look like utter crap to me. I can adapt to different interfaces - there are pluses and minuses to every way of doing something - but the anti-aliasing under Linux has always been kind of like going from Lindt chocolate to Hershey's chocolate, at least to me. Same here. In fact just a couple of months ago I posted to this very list a similar cry for help and since then got a couple of helpful hints, but unfortunately haven't seen anybody really interested in fixing the situation. Given that I'm software engineer myself and I'm not a stranger to DSP (working on ffmpeg in my spare time) I'd be more than happy to collaborate on this project with somebody who is fluent in font rendering technology or could at least give guidance when I'm stuck. Of course, if you take into account that I'm already kind of stuck I might need some guidance right away ;-) Let me show you a screenshot from FC5 with subpixel anti-aliasing, using the MS Verdana font and FreeType 2.1.10 with bytecode on: http://zinkconsulting.com/fc5-bytecode.png I've got quite a few screenshots of my own which demonstrate my *personal* dissatisfaction with font rendering on Linux. The problem, once again is that I see the difference but I can not quite get my head around where to start fixing it. Now, Werner LEMBERG on this list has suggested that FreeType is off the hook here and we should really look into postprocessing filtering (sort of like what ClearType does). So it seems that Xft can benefit from a kind of plug-in infrastructure where we would be able to insert PP filters of various kinds. Sort of like what they did here: http://turnerdavid.neuf.fr/freetype/patches/font-patches.html but in a more configurable way. Hm. I wonder, whether we should move this discussion to Xft mailing list... Is it even possible to get FreeType rendering text that even comes close to the OS X screenshots? If it's not possible with FreeType, is there some library I could drop in place of FreeType to get text that (to me) actually looks really good? I would very much like to get answers to these questions myself. If you don't mind -- lets keep each other posted on our findings. Any thoughts would be much appreciated... And *PLEASE* lets continue this conversation. Thanks, Roman. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On Sun, 2006-08-27 at 10:38 -0700, [EMAIL PROTECTED] wrote: If I'm reading your post correctly, you're basically saying that getting text that looks the way I want is hopeless. Well, its not entirely hopeless, but it seems to be impossible with the current software at hand. As I pointed out -- I'd be very motivated to work on this, provided that: 1. I have somebody as obsessed with Font Rendering as I am for evaluating results of difference software rendering techniques ;-) [ Check ] 2. I have somebody I can ask stupid questions (hey -- asking stupid questions is how I got into multimedia anyway) It sounds like Linux has an API limitation? And this API limitation is what in turn makes the fonts look so miserable? (In my view.) Yes. So far it seems that at least one area of Font Rendering (postprocessing filtering) is completely missing from both libraries doing font manipulation: FreeType and Xft. Changing that, is, in fact an easy hack of Xft as far as APIs go. Figuring out what filters to use -- could be tricky. And I'm saying that based on the MPEG/DV filtering that I've been experimenting with for ffmpeg. Regarding turning off hinting, wasn't that the default setting under FC5? These days -- I always reconfigure everything myself. Default configs are simply not trustworthy enough. Even under OS X, Mozilla-based browsers have horrendous kerning - particularly of italic serif fonts. I love the feature set, but the kerning turns me off - despite using the system anti-aliasing - so I can't stand to use Mozilla more than the bare minimum. Kerning seems like the second issue to resolve. And I hope that Tor would be kind enough to offer his advice on fractional rendering here. Now, that said, IMHO kerning quality depends much more on the font being used and its kerning tables, than on autokerning software features. Maybe I'm an idiot, but I think one the largest barriers to using Linux on the desktop for me is the maddening font rendering quality. Where precisely is the problem coming in? Would it be possible to use an alternative desktop or window manager to get around it? I don't think so. The problem is coming from a very core pair of software libraries FreeType2 + Xft. Everything else is a layer on top of them. Thanks, Roman. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
Roman, Thank you so much - it seems to be maddening trying to explain the issues to most Linux users. Quite literally, they do not care or see any significant difference. I beg to differ! Take a look at a little heads up comparison: http://zinkconsulting.com/aa-comparison.png I personally prefer something more along the lines of the OS X light subpixel anti-aliasing. I'm afraid to report that I'm not a programmer, I've had some experience in that arena, but I'm pursuing a different direction in business. I would be happy to help when I can and I'm not incompetent, but I don't have much skill. I can, however, provide a great deal of feedback regarding the quality and aesthetic matters. I'd be very happy with just a custom browser build - say something KHTML based maybe - that has great font rendering and kerning. It would make Linux so much nicer to use. OpenOffice, Gnome and a PDF viewer would be next up on my list for improved font handling. I don't think it's going to be perfect system-wide, however, if I'm understanding the limitations properly - but maybe there's at least room for improvement? -Galen On Aug 27, 2006, at 6:40 AM, Roman Shaposhnik wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? It's not FreeType's fault that Linux text looks bad. For reference, with FreeType 2 it is possible to get the kind of text quality displayed in the screenshots on this web page: http://ccxvii.net/gargoyle/screenshots.html Here I use FreeType2 to render text unhinted, taking in account the fractional position of each glyph within the pixel (ie, the render of a character is different depending on whether it starts at pixel coordinate 0.0 or 0.2 or 0.7, for example). I also apply a 5- component wide LCD coloring filter. Tor, what kind of software did you use to achieve such a result ? Can it be leveraged for Xft (at least the filtering part)? Also, if you don't mind -- can you elaborate a bit on how did you do fractional positioning (I mean it doesn't seem to be possible with FT APIs so you must have done something else here). And as always -- any pointers will be greatly appreciated. Thanks, Roman. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? I'm not sure. If I remember correctly, Keith Packard explicitly decided that he didn't want the filtering to cross pixel borders because that might possibly confuse xterm and other character cell based software. Stupid reason, if you ask me. Fixing it to the same filter as Gargoyle is a trivial hack. The filter I use is a simple [ 1 2 3 2 1 ] / 9 as illustrated here: http://www.grc.com/cttech.htm It's not FreeType's fault that Linux text looks bad. For reference, with FreeType 2 it is possible to get the kind of text quality displayed in the screenshots on this web page: http://ccxvii.net/gargoyle/screenshots.html Here I use FreeType2 to render text unhinted, taking in account the fractional position of each glyph within the pixel (ie, the render of a character is different depending on whether it starts at pixel coordinate 0.0 or 0.2 or 0.7, for example). I also apply a 5-component wide LCD coloring filter. Tor, what kind of software did you use to achieve such a result ? Can it be leveraged for Xft (at least the filtering part)? I used pure freetype. The filtering can be done with a minor patch to Xft; the hard part is not the code, it's the convincing the right people. Also, if you don't mind -- can you elaborate a bit on how did you do fractional positioning (I mean it doesn't seem to be possible with FT APIs so you must have done something else here). Use the offset from integer coordinates as the translation part of the transform matrix, then render unhinted. (Hinting assumes that the translation is zero, if I recall correctly) float x, y = ... coordinates of glyph in screen space ... float xpart = x - floor(x); float ypart = y - floor(y); FT_Vector v; v.x = xpart * 64; v.y = ypart * 64; FT_Set_Transform(face, ctm, v); FT_Load_Glyph(face, gid, FT_LOAD_NO_BITMAP, FT_LOAD_NO_HINTING); FT_Render_Glyph(face-glyph, FT_RENDER_MODE_LIGHT); /* or _LCD */ Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd be very happy with just a custom browser build - say something KHTML based maybe - that has great font rendering and kerning. It would make Linux so much nicer to use. OpenOffice, Gnome and a PDF viewer would be next up on my list for improved font handling. I don't think it's going to be perfect system-wide, however, if I'm understanding the limitations properly - but maybe there's at least room for improvement? off topic, shameless plug You may want to look into MuPDF. It does not do subpixel color filtering, but has unhinted, fractionally positioned text rendering, in a very light package. http://ccxvii.net/apparition/ Only windows binaries for now (but portable source). Make sure to get the stable version if you check out the source. / ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On Sun, 2006-08-27 at 22:48 +0200, Tor Andersson wrote: On 8/27/06, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? I'm not sure. If I remember correctly, Keith Packard explicitly decided that he didn't want the filtering to cross pixel borders because that might possibly confuse xterm and other character cell based software. Stupid reason, if you ask me. Lame, perhaps, but still important -- filtering that extends beyond the pixel changes all character metrics, which is relevant for applications which cannot handle overlapping glyphs. As Xft was designed largely as a migration API for existing applications, trying to preserve as much of the semantic environment as possible seemed important. We can certainly change how this works in new rendering APIs like cairo where applications are moving beyond pixel-oriented drawing. Sub-pixel positioning is another important area; you can explore this with cairo today by converting glyphs to paths and filling them rather than using the simple text filling APIs. Making this 'go fast' is somewhat tricky as you need to cache rendered glyphs for acceptable performance these days, which means picking a sub-pixel grid for positioning. I used pure freetype. The filtering can be done with a minor patch to Xft; the hard part is not the code, it's the convincing the right people. Changing Xft in this way will change character metrics, which will break many existing applications. One option is to experiment with doing this only for non-character cell fonts and see what that does; many of these fonts already expose applications to overlapping glyphs. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, Keith Packard [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 22:48 +0200, Tor Andersson wrote: On 8/27/06, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? I'm not sure. If I remember correctly, Keith Packard explicitly decided that he didn't want the filtering to cross pixel borders because that might possibly confuse xterm and other character cell based software. Stupid reason, if you ask me. Lame, perhaps, but still important -- filtering that extends beyond the pixel changes all character metrics, which is relevant for applications which cannot handle overlapping glyphs. As Xft was designed largely as a migration API for existing applications, trying to preserve as much of the semantic environment as possible seemed important. We can certainly change how this works in new rendering APIs like cairo where applications are moving beyond pixel-oriented drawing. I'm not sure I understand this. What's your definition of character metrics here? I'm grounded in the postscript world where the only metrics that matter are the origin and advance width. How does it change metrics? The resulting bitmap will be of a different size and have different lsb/top offsets, but apps have to cope with varying bitmap sizes anyway (as returned by FT_Render_Glyph), or am I totally ignorant about how xterm co draw their text? You can also cheat and do the interpixel filtering without changing the bitmap size. The slight error at the edge is not visible; and is still a lot better than what Xft does now. Yes, yes, I know you and Carl Worth are obsessed with precision, as evidenced by the aa discussions on the Xrender mailing list. That is, before all the X11 lists changed and killed off the discussion :( That was a sad day, I really enjoyed reading that list... Sub-pixel positioning is another important area; you can explore this with cairo today by converting glyphs to paths and filling them rather than using the simple text filling APIs. Making this 'go fast' is somewhat tricky as you need to cache rendered glyphs for acceptable performance these days, which means picking a sub-pixel grid for positioning. Would a separate set of Xft functions to get fonts that does a subpixel grid be too much to ask for? I know there's nothing in the RENDER protocol to prohibit it, and if it's an easily accessible piece of functionality it might be more likely to be used. Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On Sun, 2006-08-27 at 23:57 +0200, Tor Andersson wrote: I'm not sure I understand this. What's your definition of character metrics here? I'm grounded in the postscript world where the only metrics that matter are the origin and advance width. For many applications, the extent of the rendered pixels is relevant for redraw to work incrementally. Postscript doesn't need this most of the time, although you can still get the actual glyph extents if you want them. How does it change metrics? The resulting bitmap will be of a different size and have different lsb/top offsets, but apps have to cope with varying bitmap sizes anyway (as returned by FT_Render_Glyph), or am I totally ignorant about how xterm co draw their text? Terminal emulators often assume that each glyph fits within a fixed size box and do not touch pixels beyond that box. For updating the screen image, this is significantly easier than computing which set of glyphs need to be repainted to erase a glyph. You can also cheat and do the interpixel filtering without changing the bitmap size. The slight error at the edge is not visible; and is still a lot better than what Xft does now. Sure, that might be a good thing to try with the existing Xft codebase. I didn't bother; on my monitors, given suitably hinted glyphs, it didn't provide enough improvement to be worth the effort. Would a separate set of Xft functions to get fonts that does a subpixel grid be too much to ask for? Yes. Xft uses only pixel positioning, so there's no way to ask it to draw glyphs on a sub-pixel grid. Xft is designed to plug into existing pixel-based applications using integer coordinates. Applications which have moved to sub-pixel coordinates would do better to choose a better rendering API anyways. Cairo already exposes sub-pixel coordinates, and you can experiment with sub-pixel positioned text as well, although the 'fast' code paths there are strictly pixel-aligned at the present time. Fixing cairo to display text on sub-pixel coordinates would be reasonably easy; patches are welcome. I know there's nothing in the RENDER protocol to prohibit it, and if it's an easily accessible piece of functionality it might be more likely to be used. Sounds like you should start experimenting with patches to cairo and pango then; that'll fix up all gtk+ apps and allow you to build the cairo/pango-based Mozilla and get your fixes working there as well. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft-devel] What and where are the fonts that require the unpatented hinter ?
Not 100% sure this is the same problem, but here is a CJK font fragment from a PDF file that exhibits nasty behavior unless #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER (and hinting not disabled). Yep. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_BASE_DEF et al.
why does FT_BASE_DEF in freetype2/builds/unix/ftconfig.in, line 248, contain an `extern' when not compiling with a C++ compiler? I've apparently forgotten to synchronize it with the standard ftconfig.h. Fixed in CVS, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TrueType bytecode interpreter enhancements
Pazar 27 Ağustos 2006 19:31 tarihinde, İsmail Dönmez şunları yazmıştı: Cumartesi 26 Ağustos 2006 23:48 tarihinde, İsmail Dönmez şunları yazmıştı: Hi David, Cumartesi 26 Ağustos 2006 09:47 tarihinde, David Turner şunları yazmıştı: In the meantime, I encourage you to test the CVS code, and report any discrepancies or improvements that would strike you. Note that this doesn't solve certain problems (like extraneous pixels in the '8' or Verdana at size 11pt/72dpi, which don't appear on Windows due to a bug in its Attached two screenshots amarok-old.png with old freetype ( before bytecode enchancements ) and amarok-new.png with latest freetype CVS. As you can see the new rendering seems to be much worse. TT_CONFIG_OPTION_BYTECODE_INTERPRETER and TT_CONFIG_OPTION_UNPATENTED_HINTING were both on. P.S: Tested Tahoma.ttf at 8pt/96dpi. A make distclean seems to fix this, interesting. Ok its not fixed, old freetype was in effect. So the problem still exists. Sorry for the noise. Regards, ismail -- 日本のanimeは揺れる ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
