SMC Malayalam fonts updated in Fedora 30

The Fedora package smc-fonts has a set of Malayalam fonts (AnjaliOldLipi, Kalyani, Meera, Rachana, RaghuMalayalamSans and Suruma) maintained by SMC. We used to package all these fonts as a single zip file hosted at https://savannah.nongnu.org/projects/smc. These fonts were last updated in 2014 for Fedora, leaving them at version 6.1.

Since then, a lot of improvements were made to these fonts — glyph additions/corrections, opentype layout changes, fontTools based build system and separate source repository for each font etc.. There were lengthy discussions on the release management of the fonts, and it was partially the reason fonts were not updated in Fedora. Once it was agreed to follow different version number for each font, and a continuous build+release system was put in place at Gitlab, we could ensure that fonts downloaded from SMC website were always the latest version.

To reflect the updates in Fedora, we had to decide how to handle the monolithic source package at version 6.1 versus the new individual releases (e.g. Rachana is at version 7.0.1 as of this writing). In a discussion with Pravin Satpute, we agreed to obsolete the existing fonts package and give each font its own package.

Vishal Vijayaraghavan kindly stepped up and did the heavy lifting of creating the new packages, and we now even build the ttf font file from the source. See RHBZ#1648825 for details.

With all that in place, in Fedora 30, all these fonts are in latest version — for instance, see Rachana package. The old package smc-fonts no longer exists, instead each individual package such as smc-rachana-fonts or smc-meera-fonts can be installed. Our users will now be able to enjoy the improvements made over the years — including updated Unicode coverage, new glyphs, improved existing glyphs, much better opentype shaping etc.

Advertisements

Okular: another improvement to annotation

Continuing with the addition of line terminating style for the Straight Line annotation tool, I have added the ability to select the line start style also. The required code changes are committed today.

Line annotation with circled start and closed arrow ending.

Currently it is supported only for PDF documents (and poppler version ≥ 0.72), but that will change soon — thanks to another change by Tobias Deiminger under review to extend the functionality for other documents supported by Okular.

Okular: improved PDF annotation tool

Okular, KDE’s document viewer has very good support for annotating/reviewing/commenting documents. Okular supports a wide variety of annotation tools out-of-the-box (enable the ‘Review’ tool [F6] and see for yourself) and even more can be configured (such as the ‘Strikeout’ tool) — right click on the annotation tool bar and click ‘Configure Annotations’.

One of the annotation tools me and my colleagues frequently wanted to use is a line with arrow to mark an indent. Many PDF annotating software have this tool, but Okular was lacking it.

So a couple of weeks ago I started looking into the source code of okular and poppler (which is the PDF library used by Okular) and noticed that both of them already has support for the ‘Line Ending Style’ for the ‘Straight Line’ annotation tool (internally called the TermStyle). Skimming through the source code for a few hours and adding a few hooks in the code, I could add an option to configure the line ending style for ‘Straight Line’ annotation tool. Many line end styles are provided out of the box, such as open and closed arrows, circle, diamond etc.

An option to the ‘Straight Line’ tool configuration is added to choose the line ending style:

New ‘Line Ending Style’ for the ‘Straight Line’ annotation tool.

Here’s the review tool with ‘Open Arrow’ ending in action:

‘Arrow’ annotation tool in action.

Once happy with the outcome, I’ve created a review request to upstream the improvement. A number of helpful people reviewed and commented. One of the suggestions was to add icon/shape of the line ending style in the configuration options so that users can quickly preview what the shape will look like without having to try each one. The first attempt to implement this feature was by adding Unicode symbols (instead of a SVG or internally drawn graphics) and it looked okay. Here’s a screen shot:

‘Line End’ with symbols preview.

But it had various issues — some symbols are not available in Unicode and the localization of these strings without some context would be difficult. So, for now it is decided to drop the symbols.

For now, this feature works only on PDF documents. The patch is committed today and will be available in the next version of Okular.

Meera font updated to fix issue with InDesign

I have worked to make sure that fonts maintained at SMC work with mlym (Pango/Qt4/Windows XP era) opentype specification as well as mlm2 (Harfbuzz/Windows Vista+ era) specification, in the same font. These have also been tested in the past (2016ish) with Adobe softwares which use their own shaping engine (they use neither Harfbuzz nor Uniscribe; but there are plans to use Harfbuzz in the future — the internet tells me).

Some time ago, I received reports that typesetting articles in Adobe InDesign using Meera font has some serious issues with Chandrakkala/Halant positioning in combination with conjuncts.

When the Savmruthokaram/Chandrakkala ് (U+0D4D) follows a consonant or conjunct, it should be placed at the ‘right shoulder’ of the consonant/conjunct. But in InDesgin (CC 2019), it appears incorrectly on the ‘left shoulder’. This incorrect rendering is highlighted in figure below.

Wrong chandrakkala position before consonant in InDesign.

The correct rendering should have Chandrakkala appearing at the right of ത as in figure below.

Correct chandrakkala position after consonant.

This issue manifested only in Meera, but not in other fonts like Rachana or Uroob. Digging deeper, I found that only Meera has Mark-to-Base positioning GPOS lookup rule for Chandrakkala. This was done (instead of adjusting leftt bearing of the Chandrakkala glyph) to appear correctly on the ‘right shoulder’ of consonant. Unfortunately, InDesign seems to get this wrong.

To verify, shaping involving the Dot Reph ൎ (U+0D4E) (which is also opentype engineered as Mark-to-Base GPOS lookup) is checked. And sure enough, InDesign gets it wrong as well.

Dot Reph position (InDesign on left, Harfbuzz/Uniscribe on right)

The issue has been worked around by removing the GPOS lookup rules for Chandrakkala and tested with Harfbuzz, Uniscribe and InDesign. I have tagged a new version 7.0.2 of Meera and it is available for download from SMC website. As this issue has affected many users of InDesign, hopefully this update brings much joy to them to use Meera again. Windows/InDesign users make sure that previous versions of the font are uninstalled before installing this version.

New package in Fedora: python-xslxwriter

XlsxWriter is a Python module for creating files in xlsx (MS Excel 2007+) format. It is used by certain python modules some of our customers needed (such as OCA report_xlsx module).

This module is available in pypi but it was not packaged for Fedora. I’ve decided to maintain it in Fedora and created a package review request which is helpfully reviewed by Robert-André Mauchin.

The package, providing python3 compatible module, is available for Fedora 28 onwards.

Smarter tabular editing with Vim

I happen to edit tabular data in LaTeX format quite a bit. Being scientific documents, the table columns are (almost) always left-aligned, even for numbers. That warrants carefully crafted decimal and digit alignment on such columns containing only numbers.

I also happen to edit the text (almost) always in Vim, and just selecting/changing a certain column only is not easily doable (like in a spreadsheet). If there are tens of rows that needs manual digit/decimal align adjustment, it gets even more tedious. There must be another way!

Thankfully, smarter people already figured out better ways (h/t MasteringVim).

With that neat trick, it is much more palatable to look at the tabular data and edit it. Even then, though, it is not possible to search & replace only within a column using Visual Block selection. The Visual Block (^v) sets mark on the column of first row till the column on last row, so any :<','>s/.../.../g would replace any matching text in-between (including any other columns).

To solve that, I’ve figured out another way. It is possible to copy the Visual Block alone and pasting any other content over (though cutting it and pasting would not work as you think). Thus, the plan is:

• Copy the required column using Visual Block (^v + y)
• Open a new buffer and paste the copied column there
• Edit/search & replace to your need in that buffer, so nothing else would be unintentionally changed
• Select the modified content as Visual Block again, copy/cut it and come back to the main buffer/file
• Re-select the required column using Visual Block again and paste over
• Profit!

Here’s a short video of how to do so. I’d love to hear if there are better ways.

Demo of column editing in Vim

Powerline git dirty status without powerline_gitstatus

With git-prompt it is possible to display the dirty state (when a tracked file is modified) by setting the env variable GIT_PS1_SHOWDIRTYSTATE=true. Powerline can display the status of a git repository, such as number of commits ahead/behind, number of modified files etc. using the powerline_gitstatus module. Unfortunately, Fedora doesn’t have it packaged. I did some digging in, and found that there’s colour highlighting for branch_dirty and powerline.segments.common.vcs.branch function (which displays the current branch name) takes 2 parameters  to modify its behaviour. Modify the shell theme /etc/xdg/powerline/themes/shell/default.json under the left segment (because only left works in shell) then as follows:

...
    {   "function": "powerline.segments.common.vcs.branch",
        "args": {"ignore_statuses": ["U"], "status_colors": true},
        "priority": 20
    }
...

The branch will now be highlighted if a tracked file is modified (ignore_statuses = ["U"] causes untracked files to be ignored). Clean repository:

Clean repo

Once a tracked file is modified:

Dirty repo