Paratype PT Serif and PT Mono fonts are now available in Fedora

Paratype has a set of nice Latin/pan-Cyrillic typefaces including sans-serif, serif and monospace fonts. The sans-serif typeface, PT Sans, released in 2010 has been part of Fedora for a long time and it is the default font for Cyrillic/Russian. It is a nice font for display in desktop, documents and web.

In 2011, PT Serif and PT Mono were added to the collection. They both are nice looking and very good quality fonts. All the fonts are also made available under OFL (Open Font License) and all it needed was someone to package them for Fedora. Something in my todo list for a long time, couple of weeks ago I have leveraged the spec file of paratype-pt-sans-fonts and packaged the serif and monospaced fonts. Paratype distributes the source tar balls separately for each set and Fedora mandates to create individual packages in such cases. Thanks to the review and comments from Fedora Fonts-SIG, especially Parag Nemade, two new font packages – paratype-pt-serif-fonts and paratype-pt-mono-fonts are now in Fedora repositories.

Obligatory screenshot of both fonts:

Paratype-PT-Serif-Mono-fonts

Malayalam opentype specification – part 1

This post is a promised followup from last November documenting intricacies of opentype specification for Indic languages, specifically for Malayalam. There is an initiative to document similar details in the IndicFontbook, this series might make its way into it. A Malayalam unicode font supporting traditional orthography is required to correctly display most of the examples described in this article, some can be obtained from here.

Malayalam has a complex script, which in general means the shape and position of glyphs are determined in relation with other surrounding glyphs, for example a single glyph can be formed out of a combination of independent glyphs in a specific sequence forming a conjunct. Take an example: ക + ്‌ ‌+ ത + ്‌ + ര => ക്ത്ര in traditional orthography. Note that in almost all the cases glyph shaping and positioning change such as this example is due to the involvement of Virama diacritic ” ്‌ “. The important rules on glyph forming are:

  1. When Virama is used to combine two Consonants, it usually forms a Conjunct, such as ക + ്‌ ‌+ ത => ക്ത. This is known as C₁ conjoining as a half form of first consonant is joined with second consonant.
  2. The notable exceptions to point 1 are when the followed Consonants are either of യ, ര, ല, വ. In those cases, they form the ‘Mark’ shapes of യ, ര, ല, വ =>  ്യ, ്ര,  ്ല,  ്വ. This is known as C₂ conjoining as a modified form of second consonant is attached to the first consonant.
  3. When Virama is used to combine a Consonant with Vowel, the Vowel forms a Vowel Mark => such as ാ, ി, ീ.

Opentype organizes these glyph forming and shaping logic by a sequence of ‘Lookup tables (or rules)’ to be defined in the font. The first part gives an overview of the relevant lookup rules used for glyph processing by shaping engine such as Harfbuzz or Uniscribe.

Only those opentype features applicable for Malayalam are discussed. The features (or lookups) are applied in the following order:

  1. akhn (Akhand – used for conjuncts like ക്ക, ക്ഷ, ല്ക്ക, യ്യ, വ്വ, ല്ല etc)
  2. pref (Pre-base form – used for pre base form of Ra -  ്‌ + ര =   ്ര)
  3. blwf (Below base form – used for below base form of La – virama+La - ്‌ + ല =  ്ല)
  4. half (Half form – Not used in mlm2 spec by Rachana and Meera, but used in mlym spec and might be useful later. For now, ignore)
  5. pstf (Post base form – used for post base forms of Ya and Va - ്‌ +യ =  ്യ, ്‌ + വ = ്വ. Note that  യ്യ & വ്വ are under akhn rule)
  6. pres (Pre-base substitution – mostly used for ligatures involving pref Ra – like ക്ര, പ്ര, ക്ത്ര, ഗ്ദ്ധ്ര  etc)
  7. blws (Below base substitution – used for ligatures involving blwf La – like ക്ല, പ്ല, ത്സ്ല etc. Note that  ല്ല is under akhn rule)
  8. psts (Post base substitution – used for ligatures involving post base Matras – like കു, ക്കൂ, മൃ etc)
  9. abvm (Above base Mark  positioning – used for dot Reph - ൎ)

Last 3 forms (pres, blws, psts) are presentation forms, they have lower priority in the glyph formation. They usually form the large number of secondary glyphs. The final one (abvm) is not a GSUB (glyph substitution lookup) but a GPOS (glyph position lookup) – this is used to position dotreph correctly above the glyphs.

  • akhn: Use this for conjuncts (കൂട്ടക്ഷരങ്ങള്‍) like ക്ക, ട്ട, ണ്ണ, ക്ഷ, യ്യ, വ്വ, ല്ല, മ്പ. This rule has the highest priority, so akhn glyphs won’t be broken by the shaping engine.
  • pref: Used only for pre-base form of Ra ര –  ്ര
  • blwf: Used only for below base form of La ല -  ്ല
  • pstf: Used for the post base forms of Ya, Va യ, വ – ്യ, ്വ
  • pres: One of the presentation forms, mostly used for ligatures/glyphs with pref Ra ര – like ക്ര, പ്ര, ക്ത്ര, ഗ്ദ്ധ്ര etc. This could also used together with the ‘half’ forms in certain situations, but that is for later.
  • blws: Used for ligatures/glyphs with blwf La ല – like ക്ല, പ്ല, ത്സ്ല etc.
  • psts: Used by a large number of ligatures/glyphs due to the post base Matras (ു,ൂ,ൃ etc) – like  കു, ക്കൂ, മൃ etc. Other Matras (ാ,ി,ീ,േ,ൈ,ൈ,ൊ,ോ,ൌ,ൗ) are implicitly handled by the shaping engine based on their Unicode properties (pre-base, post-base etc) as they don’t form a different glyph together with a consonant – there is no need to define lookup rules for those matras in the font.

I will discuss these lookup rules and how they fit in the glyph shaping sequence with detailed examples in next episodes.

(P.S: WordPress tells me I started this blog 7 years ago on this day. How time flies.)

KDE Touchpad configuration ported to Frameworks 5

Fedora 20 with KDE SC 4.14 has been very stable, and after a while it gets…boring – especially when Plasma 5 is already released and you see screenshots everywhere. If you cannot hold the urge and feel sufficiently adventurous, Dan Vratil has built the Fedora 20 and 21 rpms here. If you install i386 versions, beware that baloo-widgets cannot be installed due to unmet dependencies. So, once you install dvratil’s copr repo, just do:

dnf copr enable dvratil/kde-frameworks dvratil/kde-frameworks-unstable dvratil/plasma5
dnf remove kde\* && dnf install kf5\* plasma5\* --exclude=kf5-baloo-widgets\*

I had to manually edit /usr/share/xsessions/plasma.desktop to change "/usr//usr/bin" to "/usr/bin” so that “Plasma 5″ appears in gdm list. After logging in, the desktop runs smooth, but you notice the lack of many applications because they are not yet fully ported to KF5/Plasma5.

KDE Plasma 5 desktop

KDE Plasma 5 desktop

Once I had the Qt5/KF5/Plasma5 based workstation fully operational, I could also develop, build and test KF5 based applications. Most of the KDE apps are ported or being ported to KF5 under 'frameworks' git branch. As the OpenSuSe team already have started building KF5 based apps in an unstable repository, I could leverage the spec files to build rpms.

The first itch I scratched was unavailability of touchpad configuration kcm. Not being able to enable touch-to-tap, vertical and horizontal scrolling is no fun. Looking at the git repo for kcm-touchpad showed that it is not yet ported to KF5. Checked out the git repo and started porting. There are quite some references, blogposts and tools available online to guide and ease the porting effort. As it is a kcm that is being ported, the first place to go is Frameworks Porting Notes. The subtopic of ECM (extended cmake modules) source incompatible changes is also handy updating CMakeLists.txt files. The next thing is reference to Martin Graesslin’s post on porting kcontrol module. And the final tool that is quite useful to port API changes is the kde-dev-scripts. Run the source files through relevant script - like "find -iname "*.cpp" -o -iname "*.h" -o -iname "*.ui" | xargs ~/Programs/Projects/kde-dev-scripts/kf5/<porting-script.pl>". When you hit an API change that cannot be automatically converted by the script, check frameworks at api.kde.org. Then port away, setup a build directory, compile, note the build failure, fix the build – repeat.

Alexander Mezin and Hrvoje Senjan reviewed the patches and after 6 revisions the patch is committed in kcm-touchpad frameworks branch.

KCM Touchpad on KF5

KCM Touchpad on KF5

RPMs for Fedora 20 and 21 (i386, x86_64) are built and available in my copr repo. It contains builds of kmix and konsole as well. More to build and I’ll make them available in the same repo once build completed. You are welcome to try at your own risk :-)

SMC mentoring for GSoC 2014 too

Swathanthra Malayalam Computing is a free software collective engaged in language computing, development, localization, standardization and popularization of various Free and Open Source Softwares in Malayalam language. SMC developers have contributed to various Indian language computing efforts including fonts, spell checkers, hyphenation patterns (used by TeX, Libreoffice, Firefox), input methods etc. Last year, SMC was selected as a mentor for Google Summer of Code program and we successfully mentored 3 student projects – a web application to store and process bibliography data of books with i8n support, port SILPA into Flask application and restructure into standalone modules and Automated Shaping&Rendering testing, primarily for HarfBuzz.

Together with Santhosh, I have mentored the Automated Shaping&Rendering testing framework which we use to test Malayalam font changes against HarfBuzz. It can also be used to test Uniscribe shaping engine if compiled in Windows, or used against HarfBuzz with Uniscribe backend.

SMC is selected as an organization to mentor for GSoC again this year. If you are a student who wants to work on interesting problems, look at our project ideas. One of the problems I am particularly interested and to mentor is adding Indic shaping support to ConTeXt. Apart from the listed ideas, you can propose other ideas as well. Read the FAQ, you can reach us by mailing list or via IRC #smc-project on freenode.net.

SMC Malayalam fonts updated versions released

The Unicode fonts for Malayalam maintained by Swathanthra Malayalam Computing were last updated almost 2 years ago. They all were supporting just the v1 Indic opentype spec. But there were rendering problems with the fonts under Harfbuzz.

I was fortunate to attend the Open Source Language Summit 2012 (last year!) organized by Wikimedia Foundation and Red Hat (thank you, guys!) where many of the Indic language experts came together to work on issues at hand. The 2-days workshop helped me greatly to get much more insight into fonts, opentype spec and Harfbuzz in general. Since then I have been spending a lot of effort in updating and fixing the Malayalam fonts and also testing git snapshots of Harfbuzz and reporting issues to harfbuzz development list.

In the meantime, Harfbuzz matured enough and fixed many rendering issues. Thanks to the last Udupi hackfest by Behdad and Jonathan Kew, all known issues with Malayalam shaping has been addressed. And we were busy updating the fonts, opentype lookup rules and fixing bugs to work with old shapers (old pango, Qt, ICU Layout Engine, Windows XP) as well as the new ones (Harfbuzz, Uniscribe, Adobe). The v1 Indic opentype spec was a mess due to ‘undesirable’ Halant reordering (Consonant+Halant forms were ligated while it should have been Halant+Consonant). It has caused a lot of grief on the font developers and shaping engine developers side. With the v2 spec (mlm2 script tag for Malayalam), this has been changed and there is no need to perform Halant shifting anymore by shaping engines. I was leading the effort of porting to mlm2 spec of Malayalam fonts. We could port only Meera and Rachana for now, and RaghuMalayalam taken care by a few sed scripts.

During the 12th anniversary celebrations of Swathanthra Malayalam Computing group, the new version of fonts (5.1 supporting old shapers and 6.0 supporting new shapers) were released. See the email to smc-discuss for details. Remaining fonts also need to be updated, there is interest from community to collaborate on that. The new release will show up in Fedora 20.

In the process, I have learned quite some intricacies of the Indic opentype spec and would try to document them in a series of posts.

Adventues in upgrading to Fedora 19 using ‘fedup’

So… after upgrading Fedora 18 installation to Fedora 19 (using DVD ISO image) via 'fedup' tool which was quite event-less* (not quite, read below); decided to upgrade second laptop running Fedora 17 to 19 directly using network (note that F17->F19 upgrade is not supported, IIRC).

Downloaded the latest f18 fedup noarch rpm (hey, it’s python!) from Koji directly and installed on F17 system. Did a 'fedup-cli --verbose --network 19'. After half an hour and around 2.0 GB of package downloads including third party ones, new ‘Upgrade’ boot entry is set up and reboot into it.
Boots into F19 upgrade plymouth screen… nothing happens – instead of progressing upgrade, system simply reboots after few minutes. After some head-scratching and trying to capture systemd errors, found the culprit to be a mount point entry in /etc/fstab with ntfs-3g file system – mount attempt was timing out and boot fails. Commented out that part, and then upgrade ran successfully. Reboot again, new Fedora 19 boot menu appears, boot into it. The reboot saga continues, this time with different systemd errors. Then recollect that I probably did something stupid while fedup was running (probably installing another kernel), looking at the grub entry shows that the boot target is still 'system-upgrade.target' which does not exist anymore after the upgrade. Manually correct the grub entry and voila – booting succeeds. Fixed the screw-up later by regenerating grub config – 'grub2-mkconfig -o /boot/grub2/grub.cfg' and later re-enable ntfs-3g mount point in /etc/fstab which was commented.

(*) Coming back to the first upgrade of Fedora 18 to Fedora 19 using ISO image – I had a weird setup – that is, the F18 installation was on an external USB hard disk and I boot from USB (it suffices to say there are non-technical reasons why I can’t install Linux on that laptop). But the internal hard disk of the laptop is faster and I tend to keep data there. As someone following ‘diskless install’ for a few years now and FAT filesystem cannot hold the DVD images, I was always interested if the NTFS filesystem was supported for install from. The DVD ISO image was kept in the ‘internal’ hard disk with NTFS partition  but 'fedup-cli --verbose --iso /path/to/Fedora-19-i386-DVD.iso' loudly complains that the ISO file is on ‘external’ hard disk (which is true because the OS is running from USB disk and thus the ‘internal’ hard disk is considered ‘external’) and it is not supported at the moment.
The next option to try was 'fedup-cli --device' method. For this, mount the NTFS partition which has DVD ISO image, then loop-mount the ISO image in another mount point – add these in /etc/fstab, assuming that packages need to be taken from loop-mounted location during actual upgrade run. Run  'fedup-cli --device /media/Fedora' which prepares the upgrade (this option does not copy the rpm packages into /var/lib/fedora-upgrade as the mounted device already have them – a sane thing to do). Reboot into the ‘Upgrade’ boot entry but this quickly failed and resulting in cleaning up the boot entry followed by a reboot – the error scrolled down were all related to not finding the rpm files. I didn’t investigate the issue further then, but now realize that it must be related to the mount points added in /etc/fstab failing.
In the end I copied the DVD ISO image into slow external USB hard disk itself  with Ext4 partition (from which the OS runs) followed by a 'fedup-cli --verbose --iso /home/rajeesh/Fedora-19-i386-DVD.iso' which worked flawlessly.

This is the first time I tried 'fedup' tool  and it is remarkably good – stable, fast, polished and easy. What was really impressive is that the well thought and sane behaviours – if you upgrade via network and something went wrong on the first try, the packages already downloaded to /var/lib/fedora-upgrade were kept and not downloaded again – huge win on usability and bandwidth. Also the ‘Device’ method do not copy packages unnecessarily either. What would I love to see in the future? Support for keeping ISO images in ‘external’ hard disks, and of course for NTFS partitions. Also, even packages excluded from update in yum.conf were also considered for upgrade and downloaded – perhaps a feature request for fedup to skip them?

fedup is a great tool, I want to thank the developers for making it so.