Unifont - Bugs: bug #52107, Problems with Saurashtra
You are not allowed to post comments on this tracker with your current authentication level.
bug #52107: Problems with Saurashtra
Submitter: | David Corbett <dscorbett> | ||
Submitted: | Sun 24 Sep 2017 01:47:13 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | Works For Me |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed |
Fri 24 Jul 2020 02:25:04 AM UTC, comment #4: |
Paul Hardy <unifoundry> |
Mon 20 Jul 2020 07:37:53 PM UTC, comment #3: Which font rendering engines are you thinking of specifically? |
David Corbett <dscorbett> |
Sat 11 Aug 2018 06:12:29 AM UTC, comment #2: I am marking this as "works for me" because the changes suggested will not render correctly given the shortcomings in the common font rendering engines. In particular, removing combining characters from combining character data files will not have the desired effect in common font rendering engines. If an individual glyph is incorrect, please submit a separate bug report.
|
Paul Hardy <unifoundry> |
Mon 30 Jul 2018 03:37:16 AM UTC, comment #1: I have gone back to leaving all combining glyphs in combining.dat files, if nothing else because some font rendering engines are making up their own minds about combining glyph placement. As a consequence, I think this is too tangled a mess for a font that is not a full, high-resolution vector font with intelligent double- and triple-glyph placement. Because of the limitations inherent in Unifont, further complicated by different rendering engines interpreting (or not interpreting) the combining character information differently, I intend to leave Saurashtra as it is. The same holds for Ahom. |
Paul Hardy <unifoundry> |
Sun 24 Sep 2017 01:47:13 PM UTC, original submission:
A Saurashtra syllable may consist of a consonant, a hāru, a vowel sign, and a syllable-final mark. Sixteen pixels too narrow for that, especially as some of the vowel signs are wider than some of the consonants. To make Saurashtra legible, all the General_Category=Spacing_Mark characters should have spacing glyphs. The exception is U+A8B4 SAURASHTRA CONSONANT SIGN HAARU, since no mark can precede it, so there is no reason it shouldn’t be combining.
|
David Corbett <dscorbett> |
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 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-08-11 | unifoundry | Status | None | Works For Me | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-758e.
Corresponding source code
David,
One example is Harfbuzz, and the situation has gotten worse recently because now Pango only uses Harfbuzz for font rendering. The Pango maintainers dropped FreeType support without soliciting public comment or even communicating with the FreeType maintainer to see if he wanted to help them work out a solution. And this has propagated to GNOME, which quickly adopted that new version of Pango (and as a result I am no longer using GNOME, but that is a tangential matter). That hasty decision has left font rendering on GNU/Linux less than what it could be.
So in general I think there needs to be a decent alternative to Pango that will still render Type 1 fonts (and I still use some Type 1 fonts privately that I created, and even Type 3 fonts but those are PostScript), BDF, etc. That isn't going to be solved right away though. Some have talked about forking Pango but I don't know if that will have long-term viability.
In addition, I thought Fontforge development would wind down by now. There has been talk for several years of other free font rendering engines being "the new Fontforge", yet as of today Fontforge is still actively maintained.
In the end regardless, I am hoping to not increase the complexity of Unifont. Providing consistent combining character information in a predictable way will help software that chooses to use it. The Harfbuzz maintainer does not want to fully support TrueType, to the point where he was one of the two Pango developers that removed FreeType from Pango without the above-mentioned solicitation of public comment or even contacting the FreeType maintainer. So for now if a code point is a combining code point, I at least want to have that information in the font in a consistent form and hopefully the degradation in font support in the GNU/Linux community will improve with non-Pango alternatives. If they do, the combining information will still be in Unifont.
Thank you,
Paul Hardy