[9fans] problem using a vera font in rio

[9fans] problem using a vera font in rio

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

When I use vera/unicode.12.font for either acme or rio (see the
screenshot attached) and I write e.g. 'troff', then I move in front of
'troff', write something there, say 'mv', 'space', and move the mouse
cursor away by clicking e.g. at the end of the line, the 't' letter of
the 'troff' word is not correctly displayed.

What causes this?
Thanks
Ruda

[-- Attachment #2: screenshot.png --]
[-- Type: image/png, Size: 2443 bytes --]

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

> When I use vera/unicode.12.font for either acme or rio (see the
> screenshot attached) and I write e.g. 'troff', then I move in front of
> 'troff', write something there, say 'mv', 'space', and move the mouse
> cursor away by clicking e.g. at the end of the line, the 't' letter of
> the 'troff' word is not correctly displayed.
>
> What causes this?

it turns out that neither the 'm' nor the space trigger this problem.
the problem lies with 'v'.

i wrote a little program to dump Cacheinfo/Fontchar information.
i copied the source an executable (capable of 32-bit runes) to sources:
/n/sources/contrib/quanstro/^(fontchr fontchr.c)

it appears that v's left takes on an unexpected value.  note the
value of left for the vera font:

; char=v {8.out $char; 8.out -f /lib/font/bit/vera/vera.14.font $char}
sfname /lib/font/bit/cyberbit/cyberbit.14.0000
	Cacheinfo	x 6 w 6 left 0 v 000076
	Fontchar	x 582 top 4 bottom 11 left 0 width 6
sfname /lib/font/bit/vera/vera.14.0020
	Cacheinfo	x 10 w 7 left -1 v 000076
	Fontchar	x 639 top 5 bottom 13 left -1 width 7

i would suspect that this is a fault in ttf2subf.

the definitions in subfont(2) notwithstanding, it's not clear to
me that a value of -1 is necessarily bogus.  consider an antialiased
font with a character like 'v'.  the top left edge of the v should be
shaded to the left.  if the top left edge of the font is at x=0, then
antialiasing would leave our character box and bleed into the previous
one.  this would lead to surprising values of Fontchar->left.

likewise, i think that ttf2subf could set Fontinfo->width greater than
Cacheinfo->x.

- erik

Re: [9fans] problem using a vera font in rio

[Rudolf Sykora]

> likewise, i think that ttf2subf could set Fontinfo->width greater than
> Cacheinfo->x.
>
> - erik
>

And is it just my problem I can't find the source of ttf2subf?
(It seems that although the package ttf2subf installs the 386 binary
and a man page, the sys/src/cmd/ttf2subf directory is empty...)

Ruda

Re: [9fans] problem using a vera font in rio

[Federico G. Benavento]

I think ttf2subf was written by lucho, the code is in andrey's
site http://mirtchovski.com/p9/freetype/

the binary in my contrib is a modified version of that one
so it was compiled with ape's freetype, which involved
also having libmemdraw for ape, I lost the code when
I moved to another country in 2008...

On Sun, Feb 14, 2010 at 5:09 PM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
>> likewise, i think that ttf2subf could set Fontinfo->width greater than
>> Cacheinfo->x.
>>
>> - erik
>>
>
> And is it just my problem I can't find the source of ttf2subf?
> (It seems that although the package ttf2subf installs the 386 binary
> and a man page, the sys/src/cmd/ttf2subf directory is empty...)
>
> Ruda
>
>



--
Federico G. Benavento

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

> And is it just my problem I can't find the source of ttf2subf?
> (It seems that although the package ttf2subf installs the 386 binary
> and a man page, the sys/src/cmd/ttf2subf directory is empty...)

a p9p version of ttf2subf is in /n/sources/contrib/quanstro/ttf2subf

i've been able to fix the reported problem just by compiling against
a newer version of freetype and reconverting the vera font.  it's
completely unclear to me if this is a change in freetype, vera, or
something else.

there are two related bugs that are not fixed by reconversion.
using vera,

1.  type vj.  notice that the right arm of the v gets chopped off.
(boys and girls, keep your hands inside moving vehicles!)

2.  select the j just typed and cut it.  now move the tick
somplace out.  notice the grey goo left behind.

the second can be "fixed" by having ttf2subf by clamping right at 0.
this is wrong, since we're just chopping off the tail of the j.
one can get a feel for what's going wrong by looking at the first
problem.

consider the string vera itself.  you'll notice that the v is placed so
it overlaps the e.  this looks great, but it violates the unwarranted
(and most likely unintended) assumption — that characters live
inside bounding boxes.

this assumption is partially due to the fact that stringbg is used
by libframe to avoid α² problems when redrawing, and to avoid
severe performance penalities for fonts of depth>1.  frame
buffers are slow.

but even without using stringbg, things still don't look right.
(try a little highlighting with a ca. 2006 rio.)

i haven't had a chance to think this through, but naïvely, one
would think that also drawing adjacent characters and clipping
would solve the problem via the use a bigger hammer technique.

- erik

Re: [9fans] problem using a vera font in rio

[Russ Cox]

Or you could use a non-ugly font.

Russ

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

On Mon Feb 15 22:42:21 EST 2010, rsc@swtch.com wrote:
> Or you could use a non-ugly font.

helvetica has the similar properties, especially in reasonable point
sizes for programming.  if antialiased, the fs would run together.

http://www.linotype.com/526/helvetica-family.html?PHPSESSID=21f2dcac2d82c8a33f687cfb59ed88f3&subviewmode=FONTS&samplestr=vera+ffi

i hope you never need italic.  :-)

- erik

Re: [9fans] problem using a vera font in rio

[andrey mirtchovski]

perhaps this article could be of interest to this discussion. it only
considers fixed-width fonts but is worth a look if you're looking for
better fonts:

http://hivelogic.com/articles/top-10-programming-fonts

I have not attempted to convert any of these fonts to rio/acme. If you
do I'd love to see the results posted here.

Myself, I'm stuck with Monaco. Anti-aliased in the editor, aliased in
a terminal.

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

> Myself, I'm stuck with Monaco. Anti-aliased in the editor, aliased in
> a terminal.

at least that's better than a monacle.

it seems that you can have any two of the following
1.  free
2.  reasonable unicode coverage
3.  decent looking.
4.  doesn't need antialiasing.

(yes there are four.)

- erik

Re: [9fans] problem using a vera font in rio

[Skip Tavakkolian]

Syntax is a nice font for code;  i first saw it in Oberon,
though it predates Oberon.

http://en.wikipedia.org/wiki/Syntax_(typeface)

> perhaps this article could be of interest to this discussion. it only
> considers fixed-width fonts but is worth a look if you're looking for
> better fonts:
>
> http://hivelogic.com/articles/top-10-programming-fonts
>
> I have not attempted to convert any of these fonts to rio/acme. If you
> do I'd love to see the results posted here.
>
> Myself, I'm stuck with Monaco. Anti-aliased in the editor, aliased in
> a terminal.

Re: [9fans] problem using a vera font in rio

[Ethan Grammatikidis]

On 16 Feb 2010, at 04:57, andrey mirtchovski wrote:

> perhaps this article could be of interest to this discussion. it only
> considers fixed-width fonts but is worth a look if you're looking for
> better fonts:
>
> http://hivelogic.com/articles/top-10-programming-fonts
>
> I have not attempted to convert any of these fonts to rio/acme. If you
> do I'd love to see the results posted here.
>
> Myself, I'm stuck with Monaco. Anti-aliased in the editor, aliased in
> a terminal.
>
Bump the font size up by 1 in the terminal. Monaco stops being anti-
aliased at a far larger size than you'd expect.

Re: [9fans] problem using a vera font in rio

[andrey mirtchovski]

> Bump the font size up by 1 in the terminal. Monaco stops being anti-aliased
> at a far larger size than you'd expect.

it's not anti-aliased on purpose.

Re: [9fans] problem using a vera font in rio

[andrey mirtchovski]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

speaking of fonts, i took the time today to convert a few of the
freely downloadable microsoft fonts (they come with some XML tool
package that is freely available on the net, i can dig it out if you
really want to know the source).

ttf2subf does have its issues and they do crop up more and more often
nowadays -- constantia cuts off characters at the bottom for example,
also i'm not really sure the size calculations are correct (-s 14
definitely doesn't match default font's size 14)  but there are a
couple of fonts that seem usable: consolas and calibri.

i want pretty fonts in acme, but i'm not sure ttf2subf will get us
there without major work (and a new port of the freetype libraries).

andrey

[-- Attachment #2: calibri.png --]
[-- Type: image/png, Size: 77236 bytes --]

[-- Attachment #3: cambria.png --]
[-- Type: image/png, Size: 108033 bytes --]

[-- Attachment #4: candara.png --]
[-- Type: image/png, Size: 99251 bytes --]

[-- Attachment #5: consolas.png --]
[-- Type: image/png, Size: 85089 bytes --]

[-- Attachment #6: constantia.png --]
[-- Type: image/png, Size: 75512 bytes --]

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

> i want pretty fonts in acme, but i'm not sure ttf2subf will get us
> there without major work (and a new port of the freetype libraries).

i've been running ttf2subf with the freetype appendage cut off.
i'm using the system library directly from p9p.  that seems to work better
than porting the whole freetype blob to plan 9 or carting around an
old copy of freetype.  (generally, i'd rather port to plan 9.)

unfortunately, i haven't made time to clean this version up enough
to stick out for public consumption.  yet.

i think the cutoff problem has to do with not extending the antialiasing
all the way down to the true bottom of the character.  i notice that the
ds were cut off, but not gs and ys at least in the last font.

- erik

Re: [9fans] problem using a vera font in rio

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

an alternative is to use the p9p fontsrv to generate fonts.
here's acme with Calibri on OS X.

the glyphs are a little more washed out than in your
screen shot, but maybe it's easier to fix that than to
keep working on ttf2subf.  maybe not, but either way
it's there.

russ

[-- Attachment #2: Picture 1.png --]
[-- Type: image/png, Size: 95788 bytes --]

Re: [9fans] problem using a vera font in rio

[andrey mirtchovski]

> an alternative is to use the p9p fontsrv to generate fonts.
> here's acme with Calibri on OS X.

that may be a good solution for p9p's acme. i admit i hadn't looked at it.

> the glyphs are a little more washed out than in your
> screen shot, but maybe it's easier to fix that than to
> keep working on ttf2subf.  maybe not, but either way
> it's there.

I am curious why the difference in rendering. in your screenshot 't',
'f' and 'g' look especially blurry. subpixel rendering?

what font works well for go programming in acme nowadays? what do you
use? (doesn't matter if it's variable width)

Re: [9fans] problem using a vera font in rio

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Thu, Feb 25, 2010 at 3:36 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>> an alternative is to use the p9p fontsrv to generate fonts.
>> here's acme with Calibri on OS X.
>
> that may be a good solution for p9p's acme. i admit i hadn't looked at it.

it could be a general solution - fontsrv just spits out
ordinary font files that you could use on plan 9.

>> the glyphs are a little more washed out than in your
>> screen shot, but maybe it's easier to fix that than to
>> keep working on ttf2subf.  maybe not, but either way
>> it's there.
>
> I am curious why the difference in rendering. in your screenshot 't',
> 'f' and 'g' look especially blurry. subpixel rendering?

i don't know.  it's not libfreetype.  fontsrv asks the OS X
graphics code to render each glyph into a box and then
concatenates the boxes to make the subfont.
all the text was noticeably lighter (more grey)
than in your screen shot when i put them side by side.

> what font works well for go programming in acme nowadays? what do you
> use? (doesn't matter if it's variable width)

i still use /lib/font/bit/lucsans/euro.8.font
and it works great.  i just can't get used to how fuzzy
and grey the supposedly "better" fonts are.
when you put them side by side there's just no
comparison for contrast and readability.
the attached picture is a 9term and an OS X terminal
using lucm/unicode.9.font and Lucida Sans Typewriter 15pt,
respectively.  it's easy to forget that the fuzzy fonts are
so fuzzy until you see a side by side comparison.

russ

[-- Attachment #2: Picture 2.png --]
[-- Type: image/png, Size: 126369 bytes --]

Re: [9fans] problem using a vera font in rio

[erik quanstrom]

> it could be a general solution - fontsrv just spits out
> ordinary font files that you could use on plan 9.

ttf2subf is only about 150 lines of code, once liberated from
libfreetype.

> > I am curious why the difference in rendering. in your screenshot 't',
> > 'f' and 'g' look especially blurry. subpixel rendering?
>
> i don't know.  it's not libfreetype.  fontsrv asks the OS X
> graphics code to render each glyph into a box and then
> concatenates the boxes to make the subfont.
> all the text was noticeably lighter (more grey)
> than in your screen shot when i put them side by side.

this is due to apple's algorithm for rendering glyphs.
with freetype, if you get a purely vertical or horizontal
stroke that is pixel-aligned, then you get no grey fuzz.
with apple's algorithm, you will get grey fuzz.  overall,
the color density is more even with the apple algorithm,
but it results in many more grey pixels.  you can use the
built-in screen magnifier to see this.

i tend to like subpixel rendering, even the fuzz problem.
(i don't have an opinion on apple's algorithm.  i don't have one.)
this is because i use fonts small enough that the fuzz is
hard to see and a non antialised font looks poor.  the
font i use (/lib/font/bit/cyberbit/mod14.font) is about the
same pitch as /lib/font/bit/lucidasans/unicode.7.font.

maybe i just need better contacts :-).

- erik

Re: [9fans] problem using a vera font in rio

[Ethan Grammatikidis]

On 26 Feb 2010, at 02:43, erik quanstrom wrote:

>> it could be a general solution - fontsrv just spits out
>> ordinary font files that you could use on plan 9.
>
> ttf2subf is only about 150 lines of code, once liberated from
> libfreetype.
>
>>> I am curious why the difference in rendering. in your screenshot
>>> 't',
>>> 'f' and 'g' look especially blurry. subpixel rendering?
>>
>> i don't know.  it's not libfreetype.  fontsrv asks the OS X
>> graphics code to render each glyph into a box and then
>> concatenates the boxes to make the subfont.
>> all the text was noticeably lighter (more grey)
>> than in your screen shot when i put them side by side.
>
> this is due to apple's algorithm for rendering glyphs.
> with freetype, if you get a purely vertical or horizontal
> stroke that is pixel-aligned, then you get no grey fuzz.
> with apple's algorithm, you will get grey fuzz.  overall,
> the color density is more even with the apple algorithm,
> but it results in many more grey pixels.  you can use the
> built-in screen magnifier to see this.

I find Apple's easier to read, curiously enough. Perhaps those who
don't could use fontsrv from an X11 build of p9p.

>
> i tend to like subpixel rendering, even the fuzz problem.
> (i don't have an opinion on apple's algorithm.  i don't have one.)
> this is because i use fonts small enough that the fuzz is
> hard to see and a non antialised font looks poor.  the
> font i use (/lib/font/bit/cyberbit/mod14.font) is about the
> same pitch as /lib/font/bit/lucidasans/unicode.7.font.
>
> maybe i just need better contacts :-).
>
> - erik
>

[9fans] int errno / errno.h patch

[EBo]

While working on gentoo ebuilds for plan9port, glendix, etc., I came across a
patch in Powerman's portage overlay for plan9port.

===============================
--- plan9/src/cmd/9660srv/main.c.orig	2009-12-11 19:18:18.000000000 +0200
+++ plan9/src/cmd/9660srv/main.c	2009-12-11 19:18:43.000000000 +0200
@@ -38,7 +38,7 @@
 uchar mdata[Maxiosize];
 char fdata[Maxfdata];
 uchar statbuf[STATMAX];
-int errno;
+#include <errno.h>


 extern Xfsub	*xsublist[];
===============================

should the base source include this patch?

  Best regards,

  EBo --

Re: [9fans] int errno / errno.h patch

[Russ Cox]

It looks like deleting errno from that program
would be an even better fix.

Russ

Re: [9fans] int errno / errno.h patch

[EBo]

Russ Cox <rsc@swtch.com> said:

> It looks like deleting errno from that program
> would be an even better fix.

Hmmm... you are right.  All it does is set it to 0 and never uses it...

But for future reference should errno.h be used in Plan 9 programms or not?

  EBo --

Re: [9fans] int errno / errno.h patch

[Charles Forsyth]

>But for future reference should errno.h be used in Plan 9 programms or not?

not using plan 9's own libraries (it has neither errno nor errno.h),
but APE (ANSI/POSIX) programs should use <errno.h>

Re: [9fans] problem using a vera font in rio

[matt]

>>i don't know.  it's not libfreetype.  fontsrv asks the OS X
>>graphics code to render each glyph into a box and then
>>concatenates the boxes to make the subfont.
>>all the text was noticeably lighter (more grey)
>>than in your screen shot when i put them side by side.
>>
>>
>
>this is due to apple's algorithm for rendering glyphs.
>
I don't know if it is relevant but OSX uses a 1.8 Gamma whereas PC's (&
TVs) use 2.2

Re: [9fans] problem using a vera font in rio

[david bulkow]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Apple has switched to the 2.2 Gamma.  Don't know when though, probably the
10.5 or 10.6 era.

On Fri, Feb 26, 2010 at 9:01 AM, matt <maht-9fans@maht0x0r.net> wrote:

>
>  i don't know.  it's not libfreetype.  fontsrv asks the OS X
>>> graphics code to render each glyph into a box and then
>>> concatenates the boxes to make the subfont.
>>> all the text was noticeably lighter (more grey)
>>> than in your screen shot when i put them side by side.
>>>
>>>
>>
>> this is due to apple's algorithm for rendering glyphs.
>>
>>  I don't know if it is relevant but OSX uses a 1.8 Gamma whereas PC's (&
> TVs) use 2.2
>
>

[-- Attachment #2: Type: text/html, Size: 1245 bytes --]

Re: [9fans] problem using a vera font in rio

[Albert Skye]

An interesting article on text rasterization algorithms:

	http://www.antigrain.com/research/font_rasterization/index.html

After evaluating many fonts for programming, I found Verdana to be the most readable, for the same reasons described here (though I use 11pt anti-aliased by OS X):

	http://nickgravgaard.com/cgi-bin/elastictabstopsnews/blosxom.cgi/2009/12/22