Good Computing needs Good fonts
I am blogging after a long break. Last entry was posted during foss.in. In between I posted some occasional responses on my Malayalam blog. But some situations force me to blog, and this is one such
I am specifically referring to recent posts by Pravin Satpute and Rahul Balerao. Since they already set the flame on Planet FLOSS india and Planet Fedora , I am contributing my share to it
Some Background
- Swathanthra Malayalam computing (SMC) team was reorganised in 2006 September by Praveen & me and it developed a lot of tools and improved malayalam support in GNU/Linux Desktop. We feel our major achievement is contributing atleast 20 new developers committed to free software.
- SMC works on upstream, but running our own yum repositories for Fedora 6, 7, & 8 & CentOS 5 and apt repositories for Debian etch, lenny & sid to support old versions in use & to address the delay in getting projects/patches in upstream.
Malayam Rendering & Fonts
- While working on Malayalam Rendering Issues the first bug we need to clear was a bug created by Rahul Balerao by fixing rendering engine against a buggy font called Lohit malayalam. ( ref#357790 and this flickr image). Later Rahul understood his mistake and was ready to work with us for fixing upstream bugs.
- We started with a pango patch by Suruma for perfect malayalam rendering. It was a rendering engine patch + font patch based solution to the issues regarding the shaping of post-base forms of consonants viz. YA,RA,LA & VA , in certain contexts when they are the rendered in pango & QT Treating them as ordinary consonants in the shaping engine means they can be used with ‘akhand’ tag in the font substitution table.ie, the respective form will appear whenever we input followed by the above mentioned consonant, irrespective of the context.
- Another issue solved is the post GSUB reordering of the isolated RA sign(used in reformed script),wherein it should be placed in front of the base glyph.This reordering is still to be achieved by any of the rendering mechanisms except the uniscribe.Moreover, using the post base forms for RA and LA leads to weird shaping results when they are followed by NGA, RA, RRA etc. and may more
- Suresh Worked on restoring uniscribe rendoring support in font and solved shaping issues of post-base forms of YA and VA at font level by adding half form(pre base).The half forms for other consonants are also used for the better shaping of complex syllabic cluster. This leads to 04 version of SMC fonts. It is compatible to upstream pango now.
- Only bug remaining in pango now is the Bug #441654 . A work around is available to fix it. But not accepted in upstream yet.
- In the meantime SMC developed new Traditional fonts Meera (K.H Hussain & Suresh P), Dyuthi (Hiran & K.H Hussain) following the model of Rachana Movement , which restored the traditional script of the language. Meera font become very popular and is now used/recommented by 2 major newspapers (Mathrubhumi & Mangalam) for their online versions.
- Praveen fixed/tested most of the upstream bugs on Mozilla Firefox 3.0 related to Indic rendering and Indic Printing
Reply to Pravin Satpute’s Posts
- In your post comparing Rachana & Meera fonts , you seem to be unaware of the differences between fonts. In Malayalam we only have 51 basic alphabets but we have nearly 1000 glyphs in usage. Unlike latin, font perfomance for indic languages need to be measured based on how it performs with conjuncts. I am not joining with Malayali-non-malayali comments on the post. But people may get angry while seeing the bugs in Lohit and its design mistakes.(see last part of my post for more details on this). Language is always linked with peoples emotions .
- Relative size seems to be your major point. Meera using Ascent = 560, Descent = 440, for Em size 1000 while Lohit-malayalam is using Ascent = 650, Descent = 374, for Em size 1024. Meera is using smaller sizes to prevent cutting of glyphs below baseline because it is a traditional lipi font.Relative satus can be configured using proper fontconf scripts. We already used it in SMC Debian Repository.
- You did a great job in packaging smc-fonts for Fedora9. But In the post you are saying ” license inside fonts but not easily viewable, person should have fontforge or any other font tool to actually see that license” . It is a bug with Gnome font Viewer & not with the font. See bug #407605 . So detaching Licence text is not the right solution.
Reply to Rahul Bhalerao’s comments & advices
- On the post Lohit Fedora & Community , Rahul starts with the the complaint “huge agitation by Malayalam community” . Does fedora thinks reporting bugs is “agitation”? We are just showing the issues we have come across. We also helped him. Accepting issues and solution to better the technology is the duty of a good programming artist. And Hiran Venugoplan, a student & font developer with SMC helped him to fix Lohit-malayalam’s critical bugs . It is available for download here. It still works better than the official 2.2.1 Version of Lohit-malayalam against Upsteam pango
Current release: |
 |
- I am not in favour of malayali vs non-malayali debate. But Can you think why people are becoming angry?. After reporting bugson lohit in 2007 beginning, and after community offered help, it has not been fixed till date. And first Instruction in SMC Fedora Repos are yum remove lohit-fonts-malayalam
- Your Contribution is not much in solving rendering issues of Malayalam till date and you created enough harm for malayalam rendering. Without your help language community studied it and found the solutions. People may get angry when you are claiming the authority without contributing your ability.
- Inclusion of smc-fonts in Fedora 9 gives you the authority to blame SMC for pointing bugs . But i am considering it is not as a “favour” but as your duty. I am sure without its inclusion you will loose the merit of Language support, because all you have are 2 typewriter script fonts , Lohit-malayalam & samyak-malayalam(Fixed by Hiran Venugopalan). Most of the people who are using Malayalam in Fedora are already using SMC repositories for Fedora 6, 7, and 8.
- See the below image for current rendering bugs in Lohit. Also read the section on Design mistakes in Lohit-malayalam. I am comparing it with Meera a Traditional Lipi font and Raghu-Malayalam, a typewriter script font by R.K Joshi
Design Issues in Lohit-malayalam glyphs
These issues are listed with the help of Hiran Venugoplan, who helped rahul to fix critical bugs in Lohit Malayalam and Samyak-Malayalam. (both are in Fedora 9). For the analysis I have used the Lohit Malayalam font that Fedora 9 contains as its default font. Its just an analysis, not comparision with any other. Issues over rendering is not discussed here.
- In general, the glyphs are just drawn and not designed scientifically. The font as per my analysis is done by using only one font as for reference, which is unfair while design a language which designer does not uses and knows. The size of circles, curves, proportions as foursquare is impressive. The circles need more radius, more lovely curves to be added to glyphs in order to attain better visibility.
- The previously considered four square, is a method that calligraphist suggests over Malayalam language. By that they suggest to divide the glyph to four parts using one vertical and other horizontal lines (as Rule of the thirds in photography). The calligraphist suggest for equal quantity of ink/darkness for all squares (exceptions are there).
- Malayalam digit 0 : The glyph contains a circle, which is NOT the Malayalam digit ZERO.
- Lohit Malayalam contains indo-arabic numbers : As far as I know, no other lohit fonts contains the numeral glyphs, U+0004 to U+000D. As lohit is done in a way “let other fonts replace the unknown”, they where not necessary. The design of numerals is not matching with Malayalam glyphs, in shape and in size.
- Vocalic R : The design of Vocalic R (U+0D43) is imperfect, irregular and unattractive. The glyph design starts before the LBearing hence in certain cases the glyph is overlaps the previous.
- Malayalam digits 3 (U+0D6A) and 9 (U+0D6F) : The glyph used for 3 and 9 digit representation is the similar to that of glyphs 0×00f2 and 00×00f1 respectively. This causes confusion while reading, typing and can cause spoofing.
- Proportion of vertical combination glyphs : The major problem the lohit has is that it fails over readability over screen and print which is supposed to be the major karma for a default typographic language font. The glyphs from glyph157 to glyph165, of X + la form, the size of joined part to X (which represents la) is imperfect, over sized. Similar disproportions can be seen widely over the font for vertical glyphs, glyph152 glyph154 glyph155 glyph202 and so. 0×010D is also having issue over proportion.
- For the same vertical glyphs, the vertical size relation between two such glyphs are not same and hence makes issue over readability as it make the reader a thought that he is reading a zigzag content.
- The issues are still more over readability. The font is unimpressive in screen and unreadable in papers. It is quite disappointing to see version of fedora is the one which contain many Malayalam localisation efforts and packages with such a unimpressive font as its default font. A bad font results in bad computing.
Related posts
Comments
5 Responses to “Good Computing needs Good fonts”
Leave a Reply
Few factual corrections and comments:
1. About the pango bug 357790 and the patch on it:
The patch on this bug is a mere clean up version of the patch on bug 121672 (http://bugzilla.gnome.org/show_bug.cgi?id=121672) which was originally created by LingNing. This was also based on the inputs given by Ani about the grammar of 0d30 and 0d31 which was later resolved (to 0d30 only) through discussions with smc.
Point is not to transfer the responsibility, but to acknowledge that pango(and even other layout engines) genuinely has a problem that it does not behave the way Uniscribe does. Another problem in this case is that, Uniscribe behavior has changed from its version in XP to Vista and we are yet to fix this bug completely. Anyway, my patch was reverted one year back (see Comment #32 on bug 357790 http://bugzilla.gnome.org/show_bug.cgi?id=357790#c32). Ever since then I have urged on concentrating on the original issue which I still continue to. And Lohit was agreed to be fixed temporarily to suite the current pango.
2. About the size details of Meera font:
First, as can be seen from the comments on Pravin’s blog, he is not the only one to complain about this issue.
Second, the Ascent-Descent and Em-size you mentioned here defer from the font that was given for inclusion in fedora. The font given for fedora has Ascent=1147, Descent=901 and Em Size=2048.
3. About Hiran’s fixes and bug reports:
Reporting a specific bug is always welcome , but comments like ‘a font with 1000 bugs’ and ‘unfixable font’ are the ones that I “personally” felt were ‘agitation’.
Thanks to Hiran for his contributions towards lohit and samyak, and I still encourage him to do that. But there are reasons for not accepting his fixes directly. I think they should be understood in detailed and learned as a student to be more efficient in an open source development environment. The reasons are:
i. The font provided by Hiran as a fixed version did not appear to be based on the latest version of .sfd in the cvs (now svn) repository.
ii. I was not sure of all of his intended changes. As in any other project, Lohit needs to put a Changelog for every commit. So I had to copy the changes based on his email(I regret not forcing the bugzilla then) and the visible fixes in the ttf file.
iii. Not being based on the original .sfd and not being submitted as an .sfd, there was possibility of cvs conflicts to occur. So it was necessary to create a cleaned diff patch out of his fixed font so that changes could be both recorded and committed without any hassles in the repository.
iv. I should have made him aware of all these factors, but I thought it would be kind of discouraging for him to do all the procedural details, so I did it on my own. May be I was wrong on this. I might post a detailed description of ‘How to contribute to opensource font projects’ sometime soon.
4. Thanks for notifying the incorrect link on http://www.fedorahosted.org/lohit. It is corrected now.
5. The bug fixing on Lohit started long back in 2006. But continuous changes in the requirements given by various people (bugzillas have all the records), changes in pango, changes to OpenType and recently the changes required with reference to my 1st point above, the bugs were ought to be popped up every now and then. Thanks again for notifying the current rendering issues, which are mostly recent. I would appreciate to see them in bugzilla too. Anyone who wishes to do that please refer to http://fedoraproject.org/wiki/I18NBugGuidelines.
6. Thanks for documenting the design issues in Lohit. In addition, I would also mention the kerning and spacing between glyphs is not accurate, which is a major issue IMO that the font looks bad when viewed in paragraphs. This probably was introduced by the original designers when they resized the font to match the readable size.Anyway it needs to be fixed.
Hope we work with more cooperation and harmony.
To issues that happened due to me :
I am not familiar with Fedora and Redhat stuffs, and NOT a core FreeSoftware/OSS developer. Some one told about the issues, I got a font, I never posted bugs but debugged. It was a fast move not scientific (only since I was not interested to work for a typewriter glyph collection).
[i] On legal permission, what the file which I got contained such. I dont remember actually.
[ii]I am sorry for that. But my version works better than any lohit versions!
[iii] Thats my fault. I was lazy to make a change log file!
[iv] My move was something a “from scratch” effect.
[v]Waiting for some one to teach me how to “contribute”, I am still unable to do.:)
‘a font with 1000 bugs’ and such comments was personal. Its due to pain as a language user and my bad communication. I never said any thing bad about the bugs. Bugs are supossed to be there! My comments are on bad design. Please check my comments again. I have specified that the bugs are solvable.
1. Thanks for notifying about 2003 bug
2. I admit my mistake in Ascent-Descent and Em-size mensioned on the post. I used the version on my system and not the upstream. But main point stands, It is simply configurable through Fontconfig scripts and we are laready using it. So complaints are because you didn’t include it on fedora
3. I still feel Lohit is a unfixable font now. Its design mistakes need a fix from the scratch. Patch’s will not work . For me hirans fix is bugfree compared to the official versions. If you fails to incorporate the changes in it it only shows your inability
5. I am not a Fedora user. So you cant see my comments in Fedora bugzilla. But you can see my comments about the font in Debian bugzilla, the distro i am using now
6.I am aware about the spacing and Kerning issues in Lohit. But making this font as the default font for a distro is unbearable
Anivar
« You did a great job in packaging smc-fonts for Fedora9. But In the post you are saying ” license inside fonts but not easily viewable, person should have fontforge or any other font tool to actually see that license” . It is a bug with Gnome font Viewer & not with the font. See bug #407605 . So detaching Licence text is not the right solution. »
Anivar,
1. I’m not a Malayalam user
2. I don’t care a fig about your clashes with the Lohit team
3. However, as the main coordinator of Fedora’s Fonts SIG, I can tell you this is not acceptable.
— Licenses must be accessible to users and hiding them in specialized metadata is an absolute no-go (You’d feel the same about any other info someone hid in metadata. You’re only finding this one acceptable because of your familiarity with fonts.)
— font metadata does not fit in general-purpose processes used in auditing the whole distribution (yes we do that)
— we’re badly lagging in packaging of free/open fonts. Somehow packaging fonts seems uninteresting to font authors and to software packagers. The number of font packagers in Fedora is very small. Every font project that decides its practices are “good enough” and refuses to adapt to help the distro packagers, is wasting the volunteer time that could have been spent packaging other worthwhile fonts.
I totally agree with you. Licenses must be accessible to users. But what is the logic of putting License on Copyright Field? For every Free Software License is a most important field. I know it need to be visible. But I am against putting License data on Copyright field because gnome-font viewer does not show License Field.
Here “hiding” is a bug with gnome-font-viewer.
Copyright field is not for putting License.
Swathanthra Malayalam computing is addressing the need of packaging very well. We are running rawhide repositories. Debian treats SMC repository as the upstream. One person from smc team (Rajeesh) is a co-maintainer of smc-fonts package and maintainer of other malayalam computing packages in Fedora
Anivar