Sun 26 Jun 2016 07:52:08 AM UTC, comment #7:
Hi Adam,
Good to hear. As it hapens, another fellow had written to me privately complaining about Braille in a very old version of FreeFont... so I was confused, but felt compelled to review the whole thing.
Really the small circles match FreeSerif better anyway, as big dots match FreeMono better.
Which console are you using? Something is doing a very poor job rendering, if ttf vs otf makes that big of a difference. This is part of your legibility problem.
Cheers!
|
Sat 25 Jun 2016 11:12:47 PM UTC, comment #6:
I've only now got to test your regenerated version. TTF is different but still utterly unreadable, but OTF became recognizable. Not perfect (it's still lightgrey on dark grey), but far better.
Your commit moving embossed to FreeSerif came as I was about to respond. It does solve my use case, thanks!
I attached samples on my setup (mostly run of the mill current Debian unstable) at 10pt. It's a bit apples-to-oranges comparison though as the effective width differs despite nominal size being the same.
(file #37578, file #37579)
|
Sat 25 Jun 2016 10:39:16 PM UTC, comment #5:
Moved the "embossed" version to FreeSerif. In FreeMono is now a version with no "empty" dots.
|
Sat 25 Jun 2016 05:00:42 PM UTC, comment #4:
You know what...
I misread the specs in that very document. It talks about the distancd from corresonding dots in neighboring cells, and I understood adjacent dots.
All this time, the patterns in FreeMono have been much too small, even according to the standard I thought I had followed.
This is not to say a different style is out of the question. But first let's get the most important details right.
Adam, are you able to build the font yourself, or shall I get a copy to you?
|
Sat 25 Jun 2016 03:42:55 PM UTC, comment #3:
Hi Adam,
I'm not married to the particular form of the glyphs. To change their particular form, or to re-generate the whole range, is very easy. And yes I could do something similar in any face.
I followed the specifications here: http://loc.gov/nls/specs/800_march5_2008.pdf for general proportions.
For FreeMono, other technical requirements hold. No glyph can exceed the bounds (800,-200) EM (precisely so that lines of text will fit properly in terminals.) I made the patterns the same height as the capital letters... so the overall size could be increased.
I have a question: how is the blank pattern U+2800 to be distinguished from a blank space?
|
Fri 24 Jun 2016 11:46:23 PM UTC, comment #2:
I wonder, what if you moved current Braille to a face other than Mono, and either put non-embossed dots into Mono or leave that range empty?
My rationale being, the Mono face is used almost exclusively for terminals or to represent terminal text, where readability is paramount. It's other faces that are used for fancy display.
I've played with different display settings a bit, and found that non-default antialiasing values make the problem even worse. With antialiasing off, dots start getting recognizable only at massive 24pt.
Freefont can't use fancy "smart font" techniques that alter glyphs based on some variables like size, right?
(In case someone else reads this bug report: that initial request was #22995)
|
Fri 24 Jun 2016 11:10:08 PM UTC, comment #1:
Hi Adam.
I can see the dots pretty well at 12 point on my system, but I would concede that at any smaller size, they would be very hard to make out.
You will find that there was a bug report some years ago, insisting on embossed dots for Braille.
The range in the current release was, by the way, generated by a script that I wrote, and was based on the best standards I could find at the time. I could probably dig up my notes. But I do remember that the proportions come directly from a standards document.
I have toyed with the idea of a different style perhaps in one of the other faces. There are other possibilites.
Please keep in mind, different people have different purposes for different fonts. What is perfectly suited for one purpose, doesn't work well for another purpose. In my judgment at the time, standards compliance was of greatest importance.
Pardon the long delay in writing: previously, I was being emailed about all bug reports. Something changed, and I've been busy.
|
Sat 30 Apr 2016 06:47:12 AM UTC, original submission:
I'm afraid the Braille range (U+2800..U+28FF, FreeMono only) is useless in its current form. At font sizes typically used for text I get nothing but greyish rectangles. At 96 DPI, only around size 16 characters start getting recognizable, requiring a size of 22ish+ to be recognizable without difficulty.
Other fonts don't show non-embossed dots, and thus are perfectly readable even at very small sizes.
This is especially bad as FreeMono tends to get a high priority when searching for font substitutions, and thus prevents fonts with usable glyphs in this range from being used.
I'd suggest one of two solutions:
- remove Braille from FreeMono completely, letting other fonts such as DejavuSans, NotoSansSymbols, Symbola, etc fill in
- copy the range from a freely-licensed font. This is generally not acceptable for Freefont, but as these characters don't involve any creativity, there's no "style" to be talking of.
An image sample attached, if you want some text that includes real Braille writing you can use for example https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
|