bugUnifont - Bugs: bug #45395, incorrect zero widths for some...

 
 

bug #45395: incorrect zero widths for some chars

Submitted by:  None
Submitted on:  Wed 24 Jun 2015 05:34:00 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Paul Hardy <unifoundry>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Mon 29 Jun 2015 05:29:14 AM UTC, comment #5:

The Unifont 8.0.01 package now contains zero widths from the Unicode 8.0.0 database.

Paul Hardy <unifoundry>
Project AdministratorIn charge of this item.
Sat 27 Jun 2015 04:57:20 PM UTC, comment #4:

I rebuilt the combining character file for Plane 0, and verified that 0x0F8D does show as a combining character (zero width) in the upcoming Unifont 8.0 build, which I expect to release tomorrow evening.

I had been holding out on the fraktur glyphs because they were incomplete. The missing fraktur glyphs were hard to draw as single-width, but I didn't really want to have dual-width fraktur glyphs. However, for Unifont 8.0 I am just going to release them. That way someone can see the state they're in and contribute improvements.

Unifont has complete coverage of the Basic Multilingual Plane (Plane 0). Unifont does not have complete coverage of the Supplemental Multilingual Plane (Plane 1). About 1500 glyphs still remain to be drawn in Plane 1 that could fit in a 16 by 16 pixel grid. The ordinary Unifont will not have Plane 1 scripts that are too complex for a 16 by 16 grid; those complex scripts are Cuneiform, Cuneiform Numbers and Punctuation, Early Dynastic Cuneiform, Egyptian Hieroglyphs, Anatolian Hieroglyphs, and Bamum Supplement. Sutton Sign Writing might be too complicated too. Unifont 8.0 will add about a dozen Plane 1 scripts, the largest of which is Linear A.

For Plane 1 scripts that are not yet part of Unifont, I'm happy to get contributions of complete scripts from volunteers. Just be willing to have the work distributed under the same license as the rest of Unifont.

I do not intend to have Plane 2 glyphs (CJK extensions) be a part of Unifont. Anyone needing those glyphs can get what Wen Quan Yi has, and contribute missing glyphs to that effort.

If you build the Unifont sources, "make" will create the file lib/wchardata.c. That has alternative wcwidth and related functions based on Unifont glyph widths. You might find that useful.

Paul Hardy <unifoundry>
Project AdministratorIn charge of this item.
Sat 27 Jun 2015 03:06:17 PM UTC, comment #3:

We also noticed that some bold fraktur symbols (e.g. U+1D56C) seemed to be missing.

Steven G. Johnson <stevengj>
Sat 27 Jun 2015 02:26:03 PM UTC, comment #2:

Thanks!

(Correction: 0x0f8d is a nonspacing mark and hence should have zero width.)

FYI, the reason that we noticed this is that the utf8proc library is using metric data from GNU Unifont (plus some other sources) to generate a portable up-to-date replacement for wcwidth.

See https://github.com/JuliaLang/utf8proc/pull/27

In checking that codepoints with symbol-like categories (Lu, Nd, Sc, etc) have nonzero width, as part of updating utf8proc for Unicode 8, we noticed these discrepancies in Unifont's widths: https://github.com/JuliaLang/utf8proc/pull/47

Steven G. Johnson <stevengj>
Fri 26 Jun 2015 12:50:28 AM UTC, comment #1:

Thank you for bringing this to my attention. I planned to have the Unifont 8.0 release done this coming Sunday. I will go over all of the combining characters in Unicode Plane 0 before releasing Unifont 8.0.01 though.

Unifont 7.0.06 conforms to the Unicode 7.0 specification. The upcoming Unifont 8.0.01 release will conform to the Unicode 8.0.0 release, so the New Tai Lue script will no longer have combining characters that it had under Unicode 7.0, reflecting the Unicode 8.0 changes.

Paul Hardy <unifoundry>
Project AdministratorIn charge of this item.
Wed 24 Jun 2015 05:34:00 PM UTC, original submission:

The codepoints 0x0f8d, 0xf8c, 0x0bd0, 0x06de apparently have zero width in Unifont 7.0.06, which seems incorrect.

Also, 0x19b0 etc have zero width, which seems reasonable in Unicode 7 where they are in category Mc, but in Unicode 8 these "New Tai Lue vowel shorteners" were changed to category Lo. I don't know anything about this language, but does that mean that they are no longer supposed to be treated as combining chars?

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by stevengj (Posted a comment)
  • -unavailable- added by unifoundry (Posted a comment)
  •  

    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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 20 Jul 2015 12:54:37 AM UTCunifoundryOpen/ClosedOpen=>Closed
    Mon 29 Jun 2015 05:29:14 AM UTCunifoundryStatusIn Progress=>Fixed
    Fri 26 Jun 2015 12:50:28 AM UTCunifoundryStatusNone=>In Progress
      Assigned toNone=>unifoundry

    Back to the top


    Powered by Savane 3.1-cleanup1