On Wed, 20 Jun 2012 14:37:15 -0400
erik quanstrom wrote:
> > I believe I do, and I'm pretty sure the difference lies in gamma or
> > color correction which is provided by most graphics chipsets but is
> > inaccessible with VESA. It is also likely to be inaccessible with
> > native drivers if they
> Normally your monitor should have size/position/phase settings,
> adjusting them can fix such issues
You're right, that makes a big difference. New comparison:
http://plan9.cs.bell-labs.com/sources/contrib/miller/vga-tuned-vs-dvi.jpg
After tuning, the analog (on the left) looks digital too.
Normally your monitor should have size/position/phase settings,
adjusting them can fix such issues (my automatic adjustment feature
doesn't work though)
Another data point:
The DH61DL motherboard has both vga and dvi outputs from the same
graphics core (integrated in the i5 chip), and my lcd monitor has
both vga and dvi inputs. So I'm able to do an A-B experiment where
the only variable is analog vs digital connection to the monitor. See
http://
> I believe I do, and I'm pretty sure the difference lies in gamma or
> color correction which is provided by most graphics chipsets but is
> inaccessible with VESA. It is also likely to be inaccessible with
> native drivers if they are open source, it was a fluff feature when
> CRTs were common an
On Mon, 11 Jun 2012 23:55:06 +
s...@9front.org wrote:
> >> In native, I no longer benefit from X11's rendering. Here, blurry
> >> fonts look blurry.
> >
> > i'm not having that problem. but that might be because of the details of
> > the conversion to font, or due to personal sensitivity to s
> Primarily DVI, but also observed with VGA.
> LCD screens, in all cases.
can you look at pixels through a magnifying glass and see if an image
pixel affects more than one physical one? may it happen there's a
resolution mismatch?
VGAs can have artifacts which is very hard to get fixed: it is ver
Primarily DVI, but also observed with VGA.
LCD screens, in all cases.
-sl
2012/6/12 :
>>> In native, I no longer benefit from X11's rendering. Here, blurry
>>> fonts look blurry.
Sorry, is it DVI or VGA-connected?
> In my case it's the same several machines used with the same screens. The
> only change was the local operating system. From drawterm on OpenBSD
> I thought vera was very nice (and used it for around a year); in Plan 9 native
> on the same machine vera looks blurry. I realize this is subjective t
my source is here:
http://ftp.quanstro.net/other/ttf2subf.tbz
i included the executable i last used as its origin is somewhat in doubt.
i never use the good cycles for fiddle around with fonts. ☺
- erik
>> In native, I no longer benefit from X11's rendering. Here, blurry
>> fonts look blurry.
>
> i'm not having that problem. but that might be because of the details of
> the conversion to font, or due to personal sensitivity to subpixeling.
In my case it's the same several machines used with the
this is the incantation i'm using. the second argument is zero, not
font.size*72
as in your example
if(FT_Set_Char_Size(font.face, 0, font.size * 64, 72, 72) != 0)
sysfatal("FT_Set_Char_Size: status=%d\n", status);
- erik
On Mon Jun 11 19:32:19 EDT 2012, s...@9front.org wrote:
> >> I loved vera until I switched from drawterm to native. Lately,
> >> lucidasans is very comfortable.
> >
> > why would native make a difference?
>
> In native, I no longer benefit from X11's rendering. Here, blurry
> fonts look blurry.
i
On Mon Jun 11 18:36:04 EDT 2012, mirtchov...@gmail.com wrote:
> > i don't think it's a sizing thing. i think ttf2subf is somehow getting
> > the baseline wrong for letters like Â. (try cyberbit even at 14.)
>
> I don't see height issues with cyberbit (at "magic" constant of 64
> even) but I am s
>> I loved vera until I switched from drawterm to native. Lately,
>> lucidasans is very comfortable.
>
> why would native make a difference?
In native, I no longer benefit from X11's rendering. Here, blurry
fonts look blurry.
-sl
> http://mirtchovski.com/screenshots/cyberbit-erik2.png
this was generated with
FT_Set_Char_Size(font.face, font.size*72, font.size * 64, 72, 72);
according to the documentation, the previous value of 0 defaults to
the height, which is font.size*64...
> i don't think it's a sizing thing. i think ttf2subf is somehow getting
> the baseline wrong for letters like Â. (try cyberbit even at 14.)
I don't see height issues with cyberbit (at "magic" constant of 64
even) but I am seeing width issues, especially the '0', which seems to
always be chopped
On Mon, 11 Jun 2012 17:58:39 -0400
erik quanstrom wrote:
> On Mon Jun 11 17:58:28 EDT 2012, s...@9front.org wrote:
> > > Vera (I think from your contrib) works very well for me, I find that
> > > it looks good and has good enough coverage for all my uses.
> >
> > I loved vera until I switched fr
> that's why I try to stay in the very narrow band of sizes 13 and 14 :)
> bdf2subf did a much better job at properly sizing fonts.
>
> now that you've made me look, there's a magic constant used for sizing
> in main.c:611 of freetype-plan9 (ttf2subf). the constant 64 works well
> for sizes 13-14
On Mon Jun 11 17:58:28 EDT 2012, s...@9front.org wrote:
> > Vera (I think from your contrib) works very well for me, I find that
> > it looks good and has good enough coverage for all my uses.
>
> I loved vera until I switched from drawterm to native. Lately,
> lucidasans is very comfortable.
why
> The biggest challenge with Plan 9 fonts is getting the heights right;
> often converted ttfs will have the bottom of "g" and a lot of the
> non-ASCII characters cut off at either top or bottom.
that's why I try to stay in the very narrow band of sizes 13 and 14 :)
bdf2subf did a much better job
> Vera (I think from your contrib) works very well for me, I find that
> it looks good and has good enough coverage for all my uses.
I loved vera until I switched from drawterm to native. Lately,
lucidasans is very comfortable.
-sl
> Vera (I think from your contrib) works very well for me, I find that
> it looks good and has good enough coverage for all my uses.
ah, great.
> The biggest challenge with Plan 9 fonts is getting the heights right;
> often converted ttfs will have the bottom of "g" and a lot of the
> non-ASCII c
On Mon Jun 11 17:37:43 EDT 2012, mirtchov...@gmail.com wrote:
> > it really is a trick finding decent coverage and a good looking font.
> > good coverage seems to be more important as folks assume unicode.
>
> unicover.txt has a detailed description of the coverage. langcover.txt
> notes the langu
> it really is a trick finding decent coverage and a good looking font.
> good coverage seems to be more important as folks assume unicode.
unicover.txt has a detailed description of the coverage. langcover.txt
notes the languages covered. it seems to be better than what I
expected.
is libdraw ab
On Mon, Jun 11, 2012 at 2:16 PM, erik quanstrom wrote:
> On Mon Jun 11 17:07:15 EDT 2012, mirtchov...@gmail.com wrote:
>> looking for more pleasing fonts I came across dejavu which are
>> downloadable from http://dejavu-fonts.org/wiki/Download
>>
> [...]
>>
>> coverage is so-so, but there are lati
On Mon Jun 11 17:07:15 EDT 2012, mirtchov...@gmail.com wrote:
> looking for more pleasing fonts I came across dejavu which are
> downloadable from http://dejavu-fonts.org/wiki/Download
>
[...]
>
> coverage is so-so, but there are latin/greek/cyrillic ttfs available
> too. i didn't try them out.
28 matches
Mail list logo
