I've already spoken about this in a previous e-mail. Microsoft holds a large number of patents covering specific parts of the ClearType technology, see the bottom of this page for a non-exhaustive list:
http://www.microsoft.com/mscorp/ip/tech/cleartype.asp For the moment, we're not going to implement Microsoft's rendering techniques (which are also documented in a document named "Avalon Text", that you'll find with a search engine). Don't expect to have identical rendering in the case of anti-aliased text with FreeType on Linux. We could implement it, just like bytecode interpretation, by disabling it by default in the sources. But very frankly, I don't care enough about this to spend my time on it. If you happen to take the time to provide patches to FreeType and/or libXft to support that, we may even *not* be interested in integrating them to the official FreeType sources. You could still distribute a patch however, that distributions could pick if they want to. Case closed. - David Turner - The FreeType Project (www.freetype.org) > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la > part de Anton > Danilov > Envoyé : mercredi 16 novembre 2005 11:00 > À : [email protected] > Objet : Re: [ft] Bytecode enabled rendering > > > Thanks for the answer, Werner! > > I see your point. But what really makes this situation strange and > unnatural is that Windows makes "undocumented and > unpredictable" things > which produce well-documented and predictable results, am I not right? > > It's clear that these fonts were designed by Monotype to look > exactly as > they look under Windows. > > You're speaking about the patch for "these two symbols". I have got > problems with several symbols on Tahoma 8 pt, some other symbols on > Tahoma 10 pt, Times New Roman 14 pt. > > Maybe, there is some way to fix these symbols on my own if you do not > plan to create this patch soon? > > Anton > > Werner LEMBERG wrote: > >>I am experiencing problems with aliasing-disabled rendering, and if > >>you look at Kaya's screenshot (my system, and any other will > >>probably do, shows just the same behaviour) > >> > >>http://kayalabs.com/images/tahoma.png > >> > >>you will see the difference in rendering Tahoma's 8 and v -- in > >>freetype's version you have just one more pixel and it's really > >>disturbing and annoying. > > > > > > This has been discussed at great length on the freetype-devel list, > > IIRC. The `correct' rendering result of Tahoma on Windows > is tightly > > bound to anomalies in the Windows rendering engine which internally > > rounds certain values differently, namely in an undocumented and > > unpredictable way. With other words, Windows is `wrong'. > The correct > > solution is to fix the bytecode instructions for those two > characters > > -- this breaks the digital signature, but FreeType ignores > it anyway. > > A longer time ago I announced to provide a patch, but > unfortunately I > > haven't found enough time yet to do that. > > > > > > Werner > *********************************************************************************** Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. *********************************************************************************** _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
