Re: [9fans] dejavu sans

Re: [9fans] dejavu sans

[erik quanstrom]

On Mon Jun 11 17:07:15 EDT 2012, mirtchovski@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.

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

Re: [9fans] dejavu sans

[John Floren]

On Mon, Jun 11, 2012 at 2:16 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Mon Jun 11 17:07:15 EDT 2012, mirtchovski@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.
>
> 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

Re: [9fans] dejavu sans

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

I loved vera until I switched from drawterm to native. Lately,
lucidasans is very comfortable.

-sl

Re: [9fans] dejavu sans

[erik quanstrom]

On Mon Jun 11 17:58:28 EDT 2012, sl@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 native make a difference?

- erik

Re: [9fans] dejavu sans

[Ethan Grammatikidis]

On Mon, 11 Jun 2012 17:58:39 -0400
erik quanstrom <quanstro@quanstro.net> wrote:

> On Mon Jun 11 17:58:28 EDT 2012, sl@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 native make a difference?

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

Re: [9fans] dejavu sans

[sl]

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

Re: [9fans] dejavu sans

[erik quanstrom]

On Mon Jun 11 19:32:19 EDT 2012, sl@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 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 http://ftp.quanstro.net/other/w.png|page

- erik

Re: [9fans] dejavu sans

[sl]

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

Re: [9fans] dejavu sans

[erik quanstrom]

> 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

Re: [9fans] dejavu sans

[Yaroslav]

2012/6/12  <sl@9front.org>:
>>> In native, I no longer benefit from X11's rendering. Here, blurry
>>> fonts look blurry.

Sorry, is it DVI or VGA-connected?

Re: [9fans] dejavu sans

[sl]

Primarily DVI, but also observed with VGA.

LCD screens, in all cases.

-sl

Re: [9fans] dejavu sans

[Yaroslav]

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

Re: [9fans] dejavu sans

[Ethan Grammatikidis]

On Mon, 11 Jun 2012 23:55:06 +0000
sl@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.
>
> 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.

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.

I'm not sure when the palette adjustment should take place. It could be
adjusted on font load, but perhaps it would be better to statically
adjust fonts for each display and put something like this in
$home/lib/profile:

for(fdir in \
	/mnt/term/lib/font/bit \
	/mnt/term/usr/local/plan9/font \
	/mnt/term/usr/local/inferno/fonts \
) {
	if(test -d $fdir) {bind -b $fdir /lib/font/bit}
}

A small program could be made to display a font ignoring any previous
palette, allow the user to adjust it (a single slider control may
suffice), and then batch convert any 4-bit subfont files in a chosen
subtree.

--
This is obviously some strange usage of the
word "simple" that I was previously unaware of.

Re: [9fans] dejavu sans

[erik quanstrom]

> 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

Re: [9fans] dejavu sans

[Ethan Grammatikidis]

On Wed, 20 Jun 2012 14:37:15 -0400
erik quanstrom <quanstro@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 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!

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

Re: [9fans] dejavu sans

[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
http://plan9.cs.bell-labs.com/sources/contrib/miller/vga-vs-dvi.jpg 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.

Re: [9fans] dejavu sans

[hiro]

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

Re: [9fans] dejavu sans

[Richard Miller]

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

Re: [9fans] dejavu sans

[andrey mirtchovski]

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

http://mirtchovski.com/screenshots/dejavu-small.png

Re: [9fans] dejavu sans

[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

Re: [9fans] dejavu sans

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

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

http://mirtchovski.com/screenshots/dejavu-higher.png

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 ☺

Re: [9fans] dejavu sans

[andrey mirtchovski]

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

Re: [9fans] dejavu sans

[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

Re: [9fans] dejavu sans

[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

Re: [9fans] dejavu sans

[erik quanstrom]

On Mon Jun 11 18:36:04 EDT 2012, mirtchovski@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 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?

> 
> 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
> slightly higher than the height seems to do the trick:
> 
> 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.

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

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

Re: [9fans] dejavu sans

[andrey mirtchovski]

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

Re: [9fans] dejavu sans

[erik quanstrom]

On Mon Jun 11 17:37:43 EDT 2012, mirtchovski@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 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

Re: [9fans] dejavu sans

[erik quanstrom]

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

[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):
http://mirtchovski.com/screenshots/dejavusans.png
dejavusansmono, size 13 (fixed width):
http://mirtchovski.com/screenshots/dejavumono.png
dejavusansmono, size 14: http://mirtchovski.com/screenshots/dejavu.png

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