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

 
 

bug #47809: Braille is completely unreadable

Submitted by:  Adam Borowski <kilobyte>
Submitted on:  Sat 30 Apr 2016 06:47:12 AM UTC  
 
Category: character rangeSeverity: 3 - Normal
Item Group: glyph(s) uglyStatus: Fix posted
Privacy: PublicAssigned to: Steve White <Stevan_White>
Open/Closed: OpenRelease: development

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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)

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
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
  • -unavailable- added by Stevan_White (Posted a comment)
  • -unavailable- added by kilobyte (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 25 Jun 2016 11:12:47 PM UTCkilobyteAttached File-=>Added ttf.png, #37578
      Attached File-=>Added otf.png, #37579
    Sat 25 Jun 2016 10:39:16 PM UTCStevan_WhiteStatusProceeding=>Fix posted
    Sat 25 Jun 2016 05:00:42 PM UTCStevan_WhiteStatusNone=>Proceeding
    Sat 25 Jun 2016 12:12:52 AM UTCStevan_WhiteAttached File-=>Added Braille-FreeMono.pdf, #37566
    Fri 24 Jun 2016 11:10:08 PM UTCStevan_WhiteAssigned toNone=>Stevan_White
    Sat 30 Apr 2016 06:47:45 AM UTCkilobyteAttached File-=>Added braille10.png, #37026

    Back to the top


    Powered by Savane 3.1-cleanup1