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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #45395: incorrect zero widths for some chars

Submitter:  None
Submitted:  Wed 24 Jun 2015 05:34:00 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  unifoundry
Open/Closed:  Closed

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>
Group administrator
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>
Group administrator
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>
Group administrator
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.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-20 unifoundry Open/ClosedOpen Closed
    2015-06-29 unifoundry StatusIn Progress Fixed
    2015-06-26 unifoundry StatusNone In Progress
        Assigned toNone unifoundry

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code