<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Thanks a lot for all your comments, Ruben and sorry for my delay in replying. As you point out, font rendering (perhaps I should better say "screen printing") is a matter of taste, and it is also true that Trisquel renders in a more "natural/real" way characters. However, in my case (and opinion), since I have to spend quite a lot of time reading text on screen -surely this is also your situation, anyway- the crisper on the screen the less wearysome to my eyes (you probably already know this article http://www.joelonsoftware.com/items/2007/06/12.html but I think I agree with MS philosophy as stated there). As I said, on higher resolution TFT screens -perhaps also screens with smaller pixels- this is not such a great problem, though any improvement in that sense would be welcome. Honestly, I have been unable to use gnu-linux for a long time mainly due to
"on screen printing" -on lower resolution the "blurry" aspect was too weary for me, particularly on TFT's, not so much on CRT where, as you say, Trisquel might even render better- something which has already been solved since most of the time I use higher resolution screens nowadays. I also point out that there are quite a lot of discussions concerning font rendering on GNU-Linux, and probably providing an (easy) way to achieve a more "windowish" font rendering would mean an improvement for many of us. As for fiddling with the controls -I think I have tested all possible combinations-, I find that "light" contour is the best overall option (as I said "full" is perhaps better on web browser but not that much in OpenOffice, and "medium" seems to display exactly the same as "full") though in web browser black characters tend to display a bit "greyish" and gray characters tend to display in a lighter gray as they would do under Windows. In any case, I found
some remarks concerning auto-hinting vs. bytecode interpreter in David turner's page (http://www.freetype.org/david/unix-font-rendering.html), where he says that for anti-aliased fonts auto-hinting might be a better option due to better rendering the grays implied in anti-aliasing (see on last section "
        <title></title>
        <meta name="GENERATOR" content="OpenOffice.org 3.1 (Unix)">
        <style type="text/css">
        <!--
                @page { margin: 2cm }
                P { margin-bottom: 0.21cm }
                H2 { margin-bottom: 0.21cm }
        -</style><font style="font-size: 8pt;" size="1">Why
anti-aliased TrueType fonts do not look good ?</font>
"). Have you ever tried FreeType with auto-hinting? Does it perhaps produce a crisper text?<br><br>Thanks a lot again and sorry for the bother concerning on screen printing. <br><br>--- El <b>sáb, 24/7/10, Rubén Rodríguez Pérez <i><ruben@trisquel.info></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Rubén Rodríguez Pérez <ruben@trisquel.info><br>Asunto: Re: [Trisquel-devel] Would enabling bytecode interpreter in Freetype cause patents problems or break in some way Trisquel policies?<br>Para: trisquel-devel@listas.trisquel.info<br>Fecha: sábado, 24 de julio, 2010 20:15<br><br><div class="plainMail"><br>> Just some further observations on font rendering in Ubuntu/Trisquel:<br>> <br>> I found some posts in Ubuntu forums about this issue (they go back to<br>> 2005-6, I think, so the situation might have changed afterwards as<br>> you
say)<br><br>Ubuntu enabled the bytecode interpreter way before the patent<br>expiration, even the first Ubuntu based Trisquel (2.0 Taranis) had it.<br><br>From the Hardy's changelog for freetype:<br>freetype (2.2.1-2) unstable; urgency=low<br><br> * Enable full bytecode interpreter instead of just the<br> "non-patented portions".<br><br>> which seems to point that subpixel hinting was achieved in<br><br>Subpixel rendering and hinting are two separate font improvements.<br><br>[...]<br><br>> I have not been using MS Windows for quite a long time -barely ever<br>> used Vista or later versions- but I think that "Cleartype" technology<br>> in XP provided a crisper text<br><br>Crisper != better. I think Windows comes (well, I've had very few<br>encounters with Windows since XP, so they may have improved that) with a<br>too "crisp" setting and MacOS with a too "blurry" one. I've always loved<br>the default Trisquel setting for
fonts, but since it allows you to<br>esasilly tune it up to make it behave closer to Win or Mac or whatever,<br>it can hardly be improved any further.<br><br>> than (even) current Ubuntu/Trisquel<br>> versions, particularly, as I said, on lower resolution monitors (e.g.<br>> 1024x768). Besides, enabling full subpixel hinting (both on Gnome and<br>> KDE) does not produce, I think, a perfect result (i.e. a crisp text,<br>> particularly on smaller characters). While web browsers seem to<br>> render better small characters, in Open Office in particular it<br>> modifies (in a negative way, IMO) character spacing and also modifies<br>> the shape of characters. <br><br>That may be related with the fact that being a WYSIWYG OOo needs to<br>represent the fonts as close posible to the printed media, so it<br>probably avoids certain improvements related to screen printing.<br><br>> Provided that Ubuntu/Trisquel are alredy using bytecode
interpreter,<br>> might these differences in font rendering between MS Windows and<br>> Ubuntu/Trisquel be due to using a different colour filter -as pointed<br>> out in 2) above by Freetype author-? Would it be possible to tweak<br>> that colour filter in some way to achieve that crisper text provided<br>> by Cleartype?<br><br>As I said, I think our font rendering engine is better than cleartype,<br>but fiddling with the controls (maybe changing the contour selection)<br>might help you.<br><br>> A last question, Trisquel 3.5 is using libfreetype<br>> 2.3.9, would 4.0 be using libfreetype 2.4 -perhaps that version makes<br>> a difference-.<br><br>No, T4 will come with Lucid's version (2.3.11). But AFAIK the main<br>difference in 2.4 regarding this issue is that they will enable the<br>interpreter by default. Since our package comes with it already<br>enabled it should behave the
same.<br>_______________________________________________<br>Trisquel-devel mailing list<br><a ymailto="mailto:Trisquel-devel@listas.trisquel.info" href="/mc/compose?to=Trisquel-devel@listas.trisquel.info">Trisquel-devel@listas.trisquel.info</a><br><a href="http://listas.trisquel.info/mailman/listinfo/trisquel-devel" target="_blank">http://listas.trisquel.info/mailman/listinfo/trisquel-devel</a><br></div></blockquote></td></tr></table><br>