bugFree UCS Outline Fonts - Bugs: bug #47809, Braille is completely unreadable

 
 

bug #47809: Braille is completely unreadable

Submitter:  Adam Borowski <kilobyte>
Submitted:  Sat 30 Apr 2016 06:47:12 AM UTC
   
 
Category:  character range Severity:  3 - Normal
Item Group:  glyph(s) ugly Status:  Fix posted
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * development
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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!

Steve White <Stevan_White>
Group administrator
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.


Adam Borowski <kilobyte>
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.

Steve White <Stevan_White>
Group administrator
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?

Steve White <Stevan_White>
Group administrator
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?

Steve White <Stevan_White>
Group administrator
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)

Adam Borowski <kilobyte>
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.

Steve White <Stevan_White>
Group administrator
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

Adam Borowski <kilobyte>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37578:  ttf.png added by kilobyte (3KiB - image/png)
file #37579:  otf.png added by kilobyte (5KiB - image/png)
file #37566:  Braille-FreeMono.pdf added by Stevan_White (219KiB - application/unknown - Current FreeMono Braille test page)
file #37026:  braille10.png added by kilobyte (5KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by kilobyte (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-25 kilobyte Attached File- Added ttf.png, #37578
        Attached File- Added otf.png, #37579
    2016-06-25 Stevan_White StatusProceeding Fix posted
    2016-06-25 Stevan_White StatusNone Proceeding
    2016-06-25 Stevan_White Attached File- Added Braille-FreeMono.pdf, #37566
    2016-06-24 Stevan_White Assigned toNone Stevan_White
    2016-04-30 kilobyte Attached File- Added braille10.png, #37026

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code