[9fans] dejavu sans

[andrey mirtchovski]

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, size 13 (variable width):
Loading Image...
dejavusansmono, size 13 (fixed width):
Loading Image...
dejavusansmono, size 14: Loading Image...

coverage is so-so, but there are latin/greek/cyrillic ttfs available
too. i didn't try them out.

[erik quanstrom]

Post by andrey mirtchovski
looking for more pleasing fonts I came across dejavu which are
downloadable from http://dejavu-fonts.org/wiki/Download

[...]

Post by andrey mirtchovski
coverage is so-so, but there are latin/greek/cyrillic ttfs available
too. i didn't try them out.

dejavu sans is pretty good.

it really is a trick finding decent coverage and a good looking font.
good coverage seems to be more important as folks assume unicode.

i've been using cyberbit, but it has some holes. it's killer feature is
very good hinting at smaller sizes.

i keep meaning to teach ttf2subf to break off the subfont at unicode
block boundaries to make stiching together fonts easier.

- erik

[John Floren]

Post by erik quanstrom

Post by andrey mirtchovski
looking for more pleasing fonts I came across dejavu which are
downloadable from http://dejavu-fonts.org/wiki/Download

[...]

Post by andrey mirtchovski
coverage is so-so, but there are latin/greek/cyrillic ttfs available
too. i didn't try them out.

dejavu sans is pretty good.
it really is a trick finding decent coverage and a good looking font.
good coverage seems to be more important as folks assume unicode.
i've been using cyberbit, but it has some holes.  it's killer feature is
very good hinting at smaller sizes.
i keep meaning to teach ttf2subf to break off the subfont at unicode
block boundaries to make stiching together fonts easier.
- erik

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.

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.


john

[s***@9front.org]

Post by John Floren
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

[erik quanstrom]

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 not for smaller sizes. if you lower that to 48 you
can get even "size 10" to display well. raising it up to 72 causes
even "size 13" to exhibit glyphs chopped from above/below.

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.)

- erik

[andrey mirtchovski]

Loading Image...

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...

[andrey mirtchovski]

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 off at the end.

Loading Image...

If I play around with Set_Char_Size's arguments I can get cyberbit in
various states of disrepair, especially if I touch the horizontal and
vertical dpi, but something as simple as setting the width to be
slightly higher than the height seems to do the trick:

http://mirtchovski.com/screenshots/cyberbit-erik2.png

That function is documented here:
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size

In other news, I got ttf2subf to generate higher-than-65535 code
points from the dejavu font. they look quite nice, actually:

Loading Image...

Unfortunately libdraw doesn't like a font file that mixes 0xffff and
0x1ffff code points. i may revisit this in a couple of years if
unicode emoticons suddenly become popular ☺

[erik quanstrom]

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

[erik quanstrom]

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

[erik quanstrom]

Post by andrey mirtchovski

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 off at the end.

i don't know. if you render cyberbit with the linux tools, the a will
sit higher. the legs won't be chopped off. don't you think that's
because the baseline is incorrect?

Post by andrey mirtchovski
http://mirtchovski.com/screenshots/cyberbit-erik.png
If I play around with Set_Char_Size's arguments I can get cyberbit in
various states of disrepair, especially if I touch the horizontal and
vertical dpi, but something as simple as setting the width to be
http://mirtchovski.com/screenshots/cyberbit-erik2.png

unfortunately that changes the weight.

oddly, i don't see that problem:
hget http://ftp.quanstro.net/other/w.png|page

i'd be happy to put all my fonts on sources or some other place,
should folks find that useful.

Post by andrey mirtchovski
In other news, I got ttf2subf to generate higher-than-65535 code

ah, yes. i did that a while ago. i am using a number of bucky
characters. these are the ones i pull into my standard font

; <$font awk 'length($1)>=5+2'
0xfff80 0x100080 ../symbola/symbola.14.fff80
0x1f8b2 0x1f9b2 ../symbola/symbola.14.1f8b2
0x1f7da 0x1f8b1 ../symbola/symbola.14.1f7da
0x1f70a 0x1f7d9 ../symbola/symbola.14.1f70a
0x1f652 0x1f709 ../symbola/symbola.14.1f652
0x1f59d 0x1f651 ../symbola/symbola.14.1f59d
0x1f4e9 0x1f59c ../symbola/symbola.14.1f4e9
0x1f44f 0x1f4e8 ../symbola/symbola.14.1f44f
0x1f3a6 0x1f44e ../symbola/symbola.14.1f3a6
0x1f300 0x1f3a5 ../symbola/symbola.14.1f300
0x1f0bb 0x1f1bb ../symbola/symbola.14.1f0bb
0x1f000 0x1f0ba ../symbola/symbola.14.1f000
0x1d797 0x1d897 ../symbola/symbola.14.1d797
0x1d6b4 0x1d796 ../symbola/symbola.14.1d6b4
0x1d5bd 0x1d6b3 ../symbola/symbola.14.1d5bd
0x1d4dc 0x1d5bc ../symbola/symbola.14.1d4dc
0x1d404 0x1d4db ../symbola/symbola.14.1d404
0x1d303 0x1d403 ../symbola/symbola.14.1d303
0x1d202 0x1d302 ../symbola/symbola.14.1d202
0x1d101 0x1d201 ../symbola/symbola.14.1d101
0x1d000 0x1d100 ../symbola/symbola.14.1d000

- erik

[andrey mirtchovski]

Post by John Floren
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 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 not for smaller sizes. if you lower that to 48 you
can get even "size 10" to display well. raising it up to 72 causes
even "size 13" to exhibit glyphs chopped from above/below.

of course, that means that the 'size' parameter to ttf2subf is just a hint :)

this screenshot shows three rio sessions started with 13*72
(top-left), 13*48 (top right) and 10*48 (bottom-right):

Loading Image...

[andrey mirtchovski]

Post by erik quanstrom
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 able to display code points above 0xffff?

[erik quanstrom]

Post by andrey mirtchovski

Post by erik quanstrom
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 able to display code points above 0xffff?

yes! russ did the work for p9p, and 9atom has full 32-bit rune
support. 01f4a9 (from symbola) renders just fine on my screen.

i was motivated by cuniform, of all esoterica. i guess plan 9ers
just love architechtures that have been defunct for a while. ☺.

- erik

[erik quanstrom]

Post by John Floren
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.

Post by John Floren
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.

the problem is that libframe assumes that all glyphs in a font have
the same nominal character box. this isn't the case with most fonts,
especially when you have caps with hats, or little bits hanging off the
bottom of low-hanging glyphs. also some proportial fonts
have a few glpyhs that hang out of their nominal box. libframe is not
prepared for this, and the naive rubout doesn't do a good job.

the fix of course is to add stringheight() to libdraw and percolate these
changes on through so that the assumption that all characters are the
same height can be gotten rid of. also i would think that being a little
more sophisticated about overlapped bounding boxes would be good.

- erik

[erik quanstrom]

Post by John Floren
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 native make a difference?

- erik

[Ethan Grammatikidis]

On Mon, 11 Jun 2012 17:58:39 -0400

Post by erik quanstrom

Post by John Floren
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 native make a difference?

Lack of gamma correction can do it, depending on the screen. My
Thinkpad's screen looks very pale.

[s***@9front.org]

Post by erik quanstrom

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

[erik quanstrom]

Post by s***@9front.org

Post by erik quanstrom

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 having that problem. but that might be because of the details of
the conversion to font, or due to personal sensitivity to subpixeling.

this is a repeat of the image i posed for cyberbit
hget Loading Image...|page

- erik

[s***@9front.org]

Post by erik quanstrom

Post by s***@9front.org
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 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 certain
extent, but that's precisely the problem: I sees what I sees.

Note: I don't really understand the way graphics are put on screen in either
operating system.

-sl

[erik quanstrom]

Post by s***@9front.org
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 certain

oh, wait a second. if drawterm looks better than native (for some reason
i just wasn't thinking), that means the same bitmap looks worse with plan 9.
it's got to be a video driver thing, not a font problem.

- erik

[Yaroslav]

Post by 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?

[s***@9front.org]

Primarily DVI, but also observed with VGA.

LCD screens, in all cases.

-sl

[Yaroslav]

Post by s***@9front.org
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
important to get proper timining of video modes (things like refresh
hz, sync +/- etc.) even though resolutions are identical. The other
day I've got to craft custom vgadb entries using values captured by
X11 through DDC.

[Ethan Grammatikidis]

This post might be inappropriate. Click to display it.

[erik quanstrom]

Post by Ethan Grammatikidis
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 seems to still be treated that way.
You may have noticed that images appear paler on those displays where
Vera looks blurry. This is because of the lack of gamma correction.
Black may still be black and white white, but without gamma correction
a 50% grey may appear far brighter than it should be, especially on a
LCD. (On a CRT it's more likely to be darker, in my experience.) Vera
then looks blurry because the pixels that are supposed to be mid-grey
become far brighter, far more visible than they are meant to be.
The particularly interesting thing about this is it suggests a
workaround. The font is implemented as a 4-bit greyscale image. Instead
of treating the font as a true greyscale it could instead be treated as
a palettized image and the palette adjusted to suit the screen,
darkening the greys on the displays for which it is necessary.

excellent explainer.

i typically use full rgb fonts. i don't see why one couldn't α
draw through an appropriate shade to change the font image itself.

- erik

[Ethan Grammatikidis]

On Wed, 20 Jun 2012 14:37:15 -0400

Post by erik quanstrom

Post by Ethan Grammatikidis
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 seems to still be treated that way.
You may have noticed that images appear paler on those displays where
Vera looks blurry. This is because of the lack of gamma correction.
Black may still be black and white white, but without gamma correction
a 50% grey may appear far brighter than it should be, especially on a
LCD. (On a CRT it's more likely to be darker, in my experience.) Vera
then looks blurry because the pixels that are supposed to be mid-grey
become far brighter, far more visible than they are meant to be.
The particularly interesting thing about this is it suggests a
workaround. The font is implemented as a 4-bit greyscale image. Instead
of treating the font as a true greyscale it could instead be treated as
a palettized image and the palette adjusted to suit the screen,
darkening the greys on the displays for which it is necessary.

excellent explainer.

Thanks!

Post by erik quanstrom
i typically use full rgb fonts. i don't see why one couldn't α
draw through an appropriate shade to change the font image itself.

Yeah, that would work.

[Richard Miller]

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
Loading Image... for
a photo of the result with monochrome font /pelm/unicode.9.

The dvi connection (on the right) makes the letters much sharper -
note especially the lowercase 'm'. Surprisingly, from a distance I
find the vga version easier to read, because the blurring makes the
vertical strokes a bit thicker and therefore darker against the light
background. Readers with younger eyes might find otherwise.

[hiro]

Normally your monitor should have size/position/phase settings,
adjusting them can fix such issues (my automatic adjustment feature
doesn't work though)

[Richard Miller]

Post by hiro
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:
Loading Image...

After tuning, the analog (on the left) looks digital too.