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 : address@hidden
[mailto:address@hidden la
part de Anton
Danilov
Envoyé : mercredi 16 novembre 2005 11:00
À : address@hidden
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 address@hidden and destroy the original
message.
***********************************************************************************
_______________________________________________
Freetype mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype
Anton.Danilov.vcf