Contributing fixes to APL in FreeFont

[Aaron W. Hsu]

Unless someone knows better, the GNU FreeFont collection seems to be the
only coherent collection of Serif, Sans, and Mono fonts with reasonable
styling that support APL. Unfortunately, while they apparently want to use
good hinting, the APL character set leaves something to be desired when it
comes to good hinting. I wonder if anyone here who does font design might
be interested in helping out the FreeFont project to ensure that Serif and
Sans text containing APL actually renders nicely? I have never worked with
fonts before, and I am not sure that I want to spend the time to do it,
but I hope that someone will, so that I can reap the benefits. :-)

Either that, or someone could recommend a better combined set of fonts.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.

[phil chastney]

On 2012/Oct/11 20:12, Aaron W. Hsu wrote:
> Unless someone knows better, the GNU FreeFont collection seems to be the
> only coherent collection of Serif, Sans, and Mono fonts with reasonable
> styling that support APL. Unfortunately, while they apparently want to
> use good hinting, the APL character set leaves something to be desired
> when it comes to good hinting. I wonder if anyone here who does font
> design might be interested in helping out the FreeFont project to ensure
> that Serif and Sans text containing APL actually renders nicely? I have
> never worked with fonts before, and I am not sure that I want to spend
> the time to do it, but I hope that someone will, so that I can reap the
> benefits. :-)

is it actually the hinting you're unhappy with? i.e, are you generally
content with the rendered glyphs at large sizes, but find them difficult
to read at small sizes?

or are you unhappy with the glyphs at any size? because that's a
different problem altogether, because they're ugly

or is it simply that the glyphs provided are unfamiliar? because that is
yet another, different, problem

regards . . . /phil

[David Lamkins]

It has been a while since I'd looked at that collection, so my recollection may be wrong... But if we're talking about the same fonts, it looks like these fonts (at least the glyphs used for APL) were created by directly translating bitmap fonts into TrueType (or FreeType) by vectorizing the pixels. When you scale these fonts, the trick becomes apparent as the glyphs take on a "chunky" appearance. IIRC, the notes for these fonts say that they only look good at a 12pt size, which is presumably the size of the original bitmaps.

[phil chastney]

your recollection may well be right, but perhaps not true of the current
offering

I have just checked the contents of freefont-otf-20100919.zip in
Fontlab, and the fonts exhibit none of the chunkiness, spare points,
jaggies, etc, found in scanned outlines

the letter 'O', for instance, is defined with just eight points -- if
these fonts do have a fault, it isn't the drawing of the outlines

regards . . . /phil

[Aaron W. Hsu]

phil chastney wrote:

> is it actually the hinting you're unhappy with? i.e, are you generally
> content with the rendered glyphs at large sizes, but find them difficult
> to read at small sizes?

Hinting was probably the wrong word.

> or are you unhappy with the glyphs at any size? because that's a
> different problem altogether, because they're ugly

For the most part I am actually quite happy with the glyphs, they are good
enough for my purposes, though I wish that there was more distinction
between Squad (⌷) and Quad (⎕). I like Squad with some height as well as
width difference so that it is easier to distinguish them.

I am not a great fan of the ⍥ (Big Rank) glyph, which seems to be badly
spaced, or hinted, or whatever, as the diaresis mark above the ○ seems bad.
Likewise for the ⍠ (Quad-colon) glyph, which just seems off center to me. In
the FreeMono, the ⋄ (Diamond) is ridiculuously small to the point of being
basically a period, even on large font sizes. Otherwise, as far as the
actual glyphs go, things are pretty good.

> or is it simply that the glyphs provided are unfamiliar? because that is
> yet another, different, problem

They are actually quite familiar and nice, I especially appreciate that the
* glyph uses a five pointed rather than a six or more pointed star. :-)


The real problem I am having with these fonts is the inter-character spacing
(kerning?). If you have ⍉ and ⊖ next to each other, rather than having a bit
of space between them, you end up with the circles touching one another. I
think of APL characters as mathematical operators, and as such, I would like
them to have a nice spaced feel appropriate to their kind, even in
monospaced fonts, within the constraints of the monospacing. However, many
of the combinations just seem kind of cramped when you put them next to one
another, or they appear too far away if you give them some space. It's that
sort of things that I would like to see improved in this font set.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

Programming is just another word for the lost art of thinking.

[phil chastney]

OK, I'll take a look at the issues you raise, but it will take time

hinting is a closed issue, as far as I'm concerned

default letter spacing is defined within the font, but can usually be
over-ridden in word processors -- math symbols definitely need (and
can be given) more white space than plain text, but it's sometimes
difficult to detect automatically whether a string of Greek characters
is math or plain text -- neither of these fixes are appropriate with
monospaced fonts though, which is why I find it difficult understand the
continuing preference programmers have for fixed widths

if something in particular is driving you mad, feel free to contact me
off-list, and I'll let you know whether I can fix it quickly

[Aaron W. Hsu]

phil chastney wrote:

> OK, I'll take a look at the issues you raise, but it will take time

Hey, no problem. :-)

> default letter spacing is defined within the font, but can usually be
> over-ridden in word processors -- math symbols definitely need (and
> can be given) more white space than plain text, but it's sometimes
> difficult to detect automatically whether a string of Greek characters
> is math or plain text -- neither of these fixes are appropriate with
> monospaced fonts though, which is why I find it difficult understand the
> continuing preference programmers have for fixed widths

Indeed, I feel much the same way, but in the case of a text editor, you
still rely mostly on the letter spacing of the font, and you do not
generally want to mess with spacing of the letters while editing text. Most
of the work that I with this is in plain text documents rather than in a
word processor. When I do need to use a word processor I tend to use TeX
rather than a word processor.

> if something in particular is driving you mad, feel free to contact me
> off-list, and I'll let you know whether I can fix it quickly

Eh, it's just the general stuff. I am in particular combining ⟪⟫⇒∃∀ with APL
characters, and doing it in plain text, so it is nice to have good letter
spacing for those when they are combined with APL characters in various
ways.

[phil chastney]

well, I've started work on it...

I have contacted the guy in charge of the GNU FreeFont initiative, but
have not yet heard back from him

On 2012/Nov/30 14:17, Aaron W. Hsu wrote:
> phil chastney wrote:
>

>> are you unhappy with the glyphs at any size? because that's a
>> different problem altogether, because they're ugly
>
> For the most part I am actually quite happy with the glyphs, they are good
> enough for my purposes, though I wish that there was more distinction
> between Squad (⌷) and Quad (⎕). I like Squad with some height as well as
> width difference so that it is easier to distinguish them.

FreeMono's Quad symbol is unusual -- it's as wide as can be (no white
space either side), its top and bottom don't line up with any of the
usual guidelines, and it's not symmetric about the math axis

in fact, it's the minimum size necessary to fully enclose the
apostrophe, the colon, and left and right arrows, while still allowing
for one stem width of white space between the symbol and its enclosing quad

it's interesting to see how somebody who's never seen a 2741 golf-ball
tackles a largely unwritten requirement -- right now, I wouldn't
change that quad in any way (but this may change)

I have left the squish-quad with the same vertical dimensions, but it is
now 65% of the width of the quad -- the reduced width and the extra
white space either side make the glyph more easily distinguishable

centering the colon on the math axis makes the quad-colon look a lot
tidier, and likewise the quad-diamond

the diamond itself is rather sloppily drawn -- this suggests a need to
check out the other geometric characters, but than can have wider
repercussions, and needs to be handled carefully

>
> I am not a great fan of the ⍥ (Big Rank) glyph, which seems to be badly
> spaced, or hinted, or whatever, as the diaresis mark above the ○ seems bad.
> Likewise for the ⍠ (Quad-colon) glyph, which just seems off center to me. In

> the FreeMono, the ⋄ (Diamond) is ridiculously small to the point of being

> basically a period, even on large font sizes. Otherwise, as far as the
> actual glyphs go, things are pretty good.
>

the problem here is that, when the APL symbols were mapped onto the
Unicode Character Set, the geometric shapes were rather vaguely
specified, but the codepoints were fixed

the geometric shapes were subsequently specified more precisely, but the
new definitions didn't fit the traditional APL appearance for circles
and "diamonds"

there is more detail here:
http://www.chastney.com/~philip/SImPL/APL_fonts_are_different.pdf

(that document is sliding slowly out-of-date, but it won't be change
until the decision to incorporate WingDings into the UCS is finalised)

Unicode has limited flexibility, due to a number of "no change"
guarantees given to other national and international bodies, so the only
solution here is for the APL vendors to provide the missing flexibility

users can choose their preferred APL font -- it would be nice if users
could also choose which glyphs within that font should be used to
display which Unicode values -- it's just one more translate table: a
lot more work, no doubt, but no great technical difficulties that I can see

>> or is it simply that the glyphs provided are unfamiliar? because that is
>> yet another, different, problem
>
> They are actually quite familiar and nice, I especially appreciate that the
> * glyph uses a five pointed rather than a six or more pointed star. :-)
>

the proposal to include WingDings in the UCS may have side-effects on
stars and asterisks similar to those mentioned above for geometric
shapes -- there may soon be a variety of 5- and 6-pointed stars, and
5- and 6-pointed asterisks, with fixed codepoints (and 8- and
12-pointed, should you feel you need them), and one day the individual
user may be able to choose the one s\he wants

>
> The real problem I am having with these fonts is the inter-character spacing
> (kerning?). If you have ⍉ and ⊖ next to each other, rather than having a bit
> of space between them, you end up with the circles touching one another. I
> think of APL characters as mathematical operators, and as such, I would like
> them to have a nice spaced feel appropriate to their kind, even in
> monospaced fonts, within the constraints of the monospacing. However, many
> of the combinations just seem kind of cramped when you put them next to one
> another, or they appear too far away if you give them some space. It's that
> sort of things that I would like to see improved in this font set.
>

that one's easy: a simple fix is to increase the fixed width, while a
better long term solution might be to redraw all the alphabets

the first method might make plaintext looking straggly, and the second
just isn't going to happen -- there aren't enough disposable man-hours

in the meantime, transpose could be redrawn, and if you were to switch
to U+03D1 GREEK THETA SYMBOL, that too could be redrawn, without
affecting Greek plaintext

[phil chastney]

On 2012/Nov/30 14:17, Aaron W. Hsu wrote:

> The real problem I am having with these fonts is the inter-character spacing
> (kerning?). If you have ⍉ and ⊖ next to each other, rather than having a bit
> of space between them, you end up with the circles touching one another. I
> think of APL characters as mathematical operators, and as such, I would like
> them to have a nice spaced feel appropriate to their kind, even in
> monospaced fonts, within the constraints of the monospacing. However, many
> of the combinations just seem kind of cramped when you put them next to one
> another, or they appear too far away if you give them some space. It's that
> sort of things that I would like to see improved in this font set.
>

that isn't a theta, is it? it looks like one with my default reader
font, but it's actually circle-minus

and yes, the FreeMono glyphs do touch, when viewed on screen -- the
font gives these two glyphs left and right side-bearings of a little
less than the stem width -- that's nowhere near enough

this is just another example of the (sometimes) over-generous sizing of
geometric shapes

and, except where joined with another glyph, all the geometric shapes
are resting on the base line -- Unicode Technical Report 25 recommends
that such shapes should actually be vertically centered on the math axis

I think the shapes need a thorough overhaul -- I'll see if the GNU
project admin will accept it, and if not, then we'll have to abandon
the idea, or fork off