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
Normally your monitor should have size/position/phase settings,
adjusting them can fix such issues (my automatic adjustment feature
doesn't work though)
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.
On Wed, 20 Jun 2012 14:37:15 -0400
erik quanstrom quans...@quanstro.net 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
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 subpixeling.
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 and
2012/6/12 s...@9front.org:
In native, I no longer benefit from X11's rendering. Here, blurry
fonts look blurry.
Sorry, is it DVI or VGA-connected?
Primarily DVI, but also observed with VGA.
LCD screens, in all cases.
-sl
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 very
looking for more pleasing fonts I came across dejavu which are
downloadable from http://dejavu-fonts.org/wiki/Download
ttf2subf deals with them relatively well in antialiased mode and
relatively badly in mono mode, but the results for antialiased are
good enough to share, i think:
dejavusans,
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.
On Mon, Jun 11, 2012 at 2:16 PM, erik quanstrom quans...@quanstro.net 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
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
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 languages
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
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
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 at
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 would
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 but
On Mon, 11 Jun 2012 17:58:39 -0400
erik quanstrom quans...@quanstro.net 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
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
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 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
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 seeing
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'm not
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
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 same
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 to a
28 matches
Mail list logo
