Unifont - Bugs: bug #52630, Unifont Expansion and Contraction
You are not allowed to post comments on this tracker with your current authentication level.
bug #52630: Unifont Expansion and Contraction
Submitter: | Paul Hardy <unifoundry> | ||
Submitted: | Sun 10 Dec 2017 02:01:59 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | unifoundry |
Open/Closed: | Closed |
Discussion locked!
Jump to the original submission
Mon 30 Jul 2018 03:40:40 AM UTC, comment #10: |
Paul Hardy <unifoundry> |
Wed 06 Jun 2018 12:14:34 AM UTC, comment #9: If a glyph is a combining character, I intend to leave it in a *combining.txt file.
|
Paul Hardy <unifoundry> |
Thu 28 Dec 2017 03:45:52 PM UTC, comment #8: Now that the Miao spacing marks are back in plane01-combining.txt, the Miao consonants should be two cells wide again to compensate. |
David Corbett <dscorbett> |
Thu 28 Dec 2017 03:23:57 AM UTC, comment #7: I have decided to leave all combining characters in *combining.txt files. Doing otherwise gets more complicated, and at least for now HarfBuzz will treat them as combining characters so for now they should be handled as such. The ones I removed for Miao are back in the Unifont 10.0.07 release.
|
Paul Hardy <unifoundry> |
Wed 20 Dec 2017 03:31:12 PM UTC, comment #6: Okay, I understand. |
David Corbett <dscorbett> |
Wed 20 Dec 2017 07:02:32 AM UTC, comment #5: David,
|
Paul Hardy <unifoundry> |
Tue 19 Dec 2017 06:46:53 PM UTC, comment #4: I know that Latin’s width is not hard-coded. I was making an analogy: just as Latin’s width is not hard-coded, Indic’s width should not be hard-coded.
|
David Corbett <dscorbett> |
Mon 18 Dec 2017 03:42:43 AM UTC, comment #3: David,
|
Paul Hardy <unifoundry> |
Mon 18 Dec 2017 01:08:07 AM UTC, comment #2: Even in plane 0, not all scripts have a single width in Unifont: examples include Latin, Cyrillic, and Arabic. Hard-coding some ranges to be double-width actually makes it harder to contribute for those with artistic talent who can’t read programs, because they may assume they may draw glyphs of whatever width is appropriate, not realizing their design choices are overridden.
Unifont’s Devanagari looks good in a code chart, but in text, the marks overlap the bases. I think it is possible to fix it with minimal disruption to the original maintainers’ legacy. By making the left and right matras thinner, shifting the top matras higher, shrinking the candrabindus, and shaving a row or two off the stem of most consonants, it should look okay. This goes for Bengali, Newa, and Tirhuta too, more or less. The suggestions I made for Tibetan were not to redraw everything, but to change the block to be single-width. The glyphs would mostly look the same but include less white space. OpenType is too complex for Unifont, I agree. It may yet be worth making it into an OpenType font. (I know this sounds contradictory.) When HarfBuzz processes Unifont, it treats it not as a TrueType font, but as an OpenType font that happens to be missing all its OpenType tables. It therefore does Indic reordering, which breaks Unifont, since its vowel signs work by overstriking. The only way to convince HarfBuzz not to second-guess the font is to add a stubbed OpenType GSUB table with the 'DFLT' script. Similarly, some Thai clusters (e.g. ฟิ) are garbled in Uniscribe. I suspect a stubbed table would work around that. Adding this table is a ≅1-line change to the SFD preamble hard-coded in hex2sfd. I think it is worth that to make Unifont work with OpenType shapers. |
David Corbett <dscorbett> |
Sun 10 Dec 2017 05:05:12 AM UTC, comment #1:
|
Paul Hardy <unifoundry> |
Sun 10 Dec 2017 02:01:59 AM UTC, original submission:
|
Paul Hardy <unifoundry> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-07-30 | unifoundry | Status | In Progress | None | |
Open/Closed | Open | Closed | |||
Discussion Lock | None | Locked |
Powered by Savane 3.13-3230.
Corresponding source code
I am closing this because I have gone over all I intend to go over in this somewhat narrative bug entry, and have settled on changes such as leaving combining character code points in combining.dat files. Rendering is somewhat at the mercy of font rendering engines anyways, no matter what Unifont does.
Thank you,
Paul Hardy