TruFont the font-editing application written with Python3, ufoLib, defcon and PyQt5 now has support for pasting SVG images as glyphs. It now also support drag and dropping SVG files.
For my font design workflow I mainly use Inkscape to desgin master drawings and then use fonteditor for further editing. I am migrating the fonts we maintained to Trufont from Fontforge(It is no longer developed). But, not having SVG support with Trufont was a blocker for me. So today I filed two patches and got merged to Trufont master.
ഫോണ്ട് ഇപ്പോൾ TTF നു പകരം OTF ഫോർമാറ്റിൽ ആണ് സ്വതവേ വരുന്നതു്. മഞ്ജരി രൂപകല്പന ചെയ്തത് OTF ഫോർമാറ്റ് മുന്നിൽ കണ്ടായിരുന്നെങ്കിലും(ക്യുബിക് ബെസിയർ കർവുകൾ) എല്ലാ ഓപ്പറേറ്റിങ്ങ് സിസ്റ്റങ്ങളിലും കുറ്റമറ്റതായി കാണാത്തതുകൊണ്ട് TTF ൽ ആയിരുന്നു ആദ്യം പുറത്തിറക്കിയതു്. ഇപ്പോൾ ആ പ്രശ്നങ്ങളൊക്കെ പരിഹരിച്ചിട്ടുണ്ടു്. TTF, Webfonts എന്നിവയും വേണമെങ്കിൽ ഡൌൺലോഡ് ചെയ്യാം.
ഫോണ്ട് ഫോർജ് ആയിരുന്നു മഞ്ജരിയടക്കമുള്ള എല്ലാ ഫോണ്ടുകളും എഡിറ്റ് ചെയ്യാൻ ഞങ്ങൾ ഉപയോഗിച്ചിരുന്നതു്. വളരെ പഴയ ആ സോഫ്റ്റ്വെയർ അതിന്റെ ഡെവലപ്മെന്റ് പതിയെ നിർത്തുകയാണ്. Unified Font Object ഫോർമാറ്റിലേക്ക് എല്ലാ ഫോണ്ടുകളുടെയും സോഴ്സ് കോഡ് മാറുകയും Trufont പോലുള്ള പുതിയ എഡിറ്റർ വരുകയും ചെയ്യുന്നുണ്ട്. ഈ മാറ്റത്തിനൊപ്പം പോകാൻ ആദ്യമായി മഞ്ജരിയുടെ സോഴ്സ് കോഡ് UFO ഫോർമാറ്റിലേക്ക് മാറ്റി. ബാക്കി ഫോണ്ടുകളും പതിയെ അങ്ങനെ മാറ്റി ഫോണ്ട് ഫോർജുമായുള്ള ബന്ധം ഉപേക്ഷിക്കും.
Out of all my projects, this is the project that gave me highest satisfaction. I see people using it in social media every day for memes, banners, notices. I have seen the font used for Government publishings, notices, reports. I have seen wedding invitations, book covers, Movie titles with Manjari font. I am so happy that Malayalam speakers loved it.
Kavya and me are working on new version of Manjari with more glyphs to support latest Unicode, and optimize some of the ligature rules. The latest version of the font is always available at https://smc.org.in/fonts
In LibreOffice, select Tools -> Extension Manager from the menu bar.
In the Extension Manager dialog click Add.
A file browser window opens. Navigate to the folder where you saved the LibreOffice extension file(s) on your system. The extension’s files have the file extension ‘OXT’.
Find and select the extension you want to install and click Open.
If this extension is already installed, you’ll be prompted to press OK to confirm whether to overwrite the current version by the new one, or press Cancel to stop the installation.
After you are asked whether to install the extension only for your user or for all users. If you choose the Only for me option, the extension will be installed only for your user. If you choose For all users, you need system administrator rights. In this case the extension will be available for all users. In general, choose Only for me, that doesn’t require administration rights on the operating system.
Debian and Ubuntu
The above steps works for Debian and Ubuntu too. But there is a better way. Using your package manager install hyphen-ml package. This will install hyphenation not only for libreoffice, but for typesetting packages like LaTeX.
Using the hyphenation
To automatically hyphenate the current or selected paragraphs, choose Format – Paragraph, and then click the Text Flow tab.
To manually Hyphenate Single Words, click in the word where you want to add the hyphen, and then press Ctrl+Hyphen(-).
To manually Hyphenate Text in a Selection Select the text that you want to hyphenate. Choose Tools – Language – Hyphenation.
Malayalam and several other languages does not use visible hypen(-) at the end of line when a word is broken. Currently there is no way to control this in libreoffice.
I had developed hyphenation patterns for 10 other Indian languages too. Yet to upload them to libreoffice repository. But they are readily available in Debian and Ubuntu. You can install them by choosing hyphen-* package.
Malayalam script is known for its curly characters with beautiful loops. Encoded in unicode around 2001, it is relatively new to the digital age. The script has been evolving from rectangle shaped to oval shaped types of varying proportions. The popular culture is more of oval/ellipse shaped curves, mainly because writing methods using stensils or pens demanded less sharp corners. The character or ligature shapes has also been changing gradually towards the shapes that are easy with pens. The Manjari font takes that to another level by smoothening all curves to its maximum.
The curves are constructed along the spiral segments. The resulting shapes are extra smooth. The curve perfection resulted in whitespaces that aquired beautiful leaf and drop shapes between the bowls and loops of the script. It is illustrated in the specimen. The spiral smoothness of curves were complemented by rounded terminals which gives very soft feeling for the eyes.
The design of the curves in Manjari are theoretically based on the PHD thesis by Raph Levien – “From Spiral to Spline: Optimal Techniques in Interactive Curve Design” (http://www.levien.com/phd/thesis.pdf). The Inconsolata monospace humanist latin font known for its clean lines and elegant design by Levien himself is based on this theory.
Normal, Bold, Thin style variants are available. This is the first Malayalam unicode font with thin style variant
The curve strokes in Manjari were drawn in Inkscape using the spiral library written by Raph Levien himself and opentype feature compilation was done using FontForge. The font is about to release in next few days, SVGs, scripts and source is available at https://gitlab.com/smc/manjari
Orion Champadiyil prepared some illustrations using the font, you can see them in our font download page
The ContentTranslation tool provides machine translation as one of the translation tool, so that editors can use it as an initial version to improve up on. We used Apertium as machine translation backend and planning to support more machine translation services soon.
A big difference in editing using ContentTranslation, is it does not involve Wiki Markup. Instead, editors can edit rich text. Basically it is contenteditable HTML elements. This also means, what you translate is HTML sections of articles.
The HTML contains all possible markups that a typical Wikipedia article has. This means, the machine translation is on HTML content. But, not all MT engines support HTML content.
Some MT engines, such as Moses, output subsentence alignment information directly, showing which source words correspond to which target words.
$ echo 'das ist ein kleines haus' | moses -f phrase-model/moses.ini -t
this is |0-1| a |2-2| small |3-3| house |4-4|
The Apertium MT engine does not translate formatted text faithfully. Markup such as HTML tags is treated as a form of blank space. This can lead to semantic changes (if words are reordered), or syntactic errors (if mappings are not one-to-one).
$ echo 'legal <b>persons</b>' | apertium en-es -f html
$ echo 'I <b>am</b> David' | apertium en-es -f html
Other MT engines exhibit similar problems. This makes it challenging to provide machine translations of formatted text. This blog post explains how this challenge is tackled in ContentTranslation.
As we saw in the examples above, a machine translation engine can cause the following errors in the translated HTML. The errors are listed in descending order of severity.
Corrupt markup – If the machine translation engine is unaware of HTML structure, they can potentially move the HTML tags randomly, causing corrupted markup in the MT result
Wrongly placed annotations – The two examples given above illustrate this. It is more severe if content includes links and link targets were swapped or randomly given in the MT output.
Missing annotations – Sometimes the MT engine may eat up some tags in the translation process.
Split annotations -During translation a single word can be translated to more than one word. If the source word has a mark up, say <a> tag. Will the MT engine apply the <a> tag wrapping both words or apply to each word?
All of the above issues can cause bad experience to translators.
Apart from potential issues with markup transfer, there is another aspect about sending HTML content to MT engines. Compared to plain text version of a paragraph, HTML version is bigger in terms of size(bytes). Most of these extra addition is tags and attributes which should be unaffected by the translation. This is unnecessary bandwidth usage. If the MT engine is a metered engine(non-free, API access is measured and limited), we are not being economic.
An outline of the algorithm we used to transfer markups from source content to translated content is given below.
The input HTML content is translated into a LinearDoc, with inline markup (such as bold and links) stored as attributes on a linear array of text chunks. This linearized format is convenient for important text manipulation operations, such as reordering and slicing, which are challenging to perform on an HTML string or a DOM tree.
Plain text sentences (with all inline markup stripped away) are sent to the MT engine for translation.
The MT engine returns a plain text translation, together with subsentence alignment information (saying which parts of the source text correspond to which parts of the translated text).
The alignment information is used to reapply markup to the translated text.
This make sure that MT engines are translating only plain text and mark up is applied as a post-MT processing.
Essentially the algorithm does a fuzzy match to find the target locations in translated text to apply annotations. Here also content given to MT engines is plain text only.
The steps are given below.
For the text to translate, find the text of inline annotations like bold, italics, links etc. We call it subsequences.
Pass the full text and subsequences to the plain text machine translation engine. Use some delimiter so that we can do the array mapping between source items(full text and subsequences) and translated items.
The translated full text will have the subsequences somewhere in the text. To locate the subsequence translation in full text translation, use an approximate search algorithm
The approximate search algorithm will return the start position of match and length of match. To that range we map the annotation from the source html.
The approximate match involves calculating the edit distance between words in translated full text and translated subsequence. It is not strings being searched, but ngrams with n=number of words in subsequence. Each word in ngram will be matched independently.
To understand this, let us try the algorithm in some example sentences.
Translating the Spanish sentence <p>Es <s>además</s> de Valencia.</p> to Catalan: The plain text version is Es además de Valencia.. And the subsequence with annotation is además . We give both the full text and subsequence to MT. The full text translation is A més de València.. and the word además is translated as a més. We do a search for a més in the full text translation. The search will be successfull and the <s> tag will be applied, resulting <p>És <s>a més</s> de València.</p>.The seach performed in this example is plain text exact search. But the following example illustrate why it cannot be an exact search.
Translating an English sentence <p>A <b>Japanese</b> <i>BBC</i> article</p> to Spanish. The full text translation of this is Un artículo de BBC japonés One of the subsequenceJapanese will get translated as Japonés. The case of J differs and search should be smart enough to identify japonés as a match for Japonés. The word order in source text and translation is already handled by the algorithm. The following example will illustrate that is not just case change that happens.
Translating <p>A <b>modern</b> Britain.</p> to Spanish. The plain text version get translated as Una Gran Bretaña moderna. and the word with annotation modern get translated as Moderno. We need a match for moderna and Moderno. We get <p>Una Gran Bretaña <b>moderna</b>.</p>. This is a case of word inflection. A single letter at the end of the word changes.
Now let us see an example where the subsequence is more than one word and the case of nested subsequences. Translating English sentence <p>The <b>big <i>red</i></b> dog</p> to Spanish. Here, the subsequnce Big red is in bold, and inside that, the red is in italics. In this case we need to translate the full text, sub sequence big red and red. So we have, El perro rojo grande as full translation, Rojo grande and Rojo as translations of sub sequences. Rojo grande need to be first located and bold tag should be applied. Then search for Rojo and apply Italic. Then we get <p>El perro <b><i>rojo</i> grande</b></p>.
How does it work with heavily inflected languages like Malayalam? Suppose we translate <p>I am from <a href=”x”>Kerala<a></p> to Malayalam. The plain text translation is ഞാന് കേരളത്തില് നിന്നാണു്. And the sub sequence Kerala get translated to കേരളം. So we need to match കേരളം and കേരളത്തില്. They differ by an edit distance of 7 and changes are at the end of the word. This shows that we will require language specific tailoring to satisfy a reasonable output.
The algorithm to do an approximate string match can be a simple levenshtein distance , but what would be the acceptable edit distance? That must be configurable per language modules. And the following example illustrate that just doing an edit distance based matching wont work.
Translating <p>Los Budistas no <b>comer</b> carne</p> to English. Plain text translation is The Buddhists not eating meat.Comer translates as eat. With an edit distance approach, eat will match more with meat than eating. To address this kind of cases, we mix a second criteria that the words should start with same letter. So this also illustrate that the algorithm should have language specific modules.
Still there are cases that cannot be solved by the algorithm we mentioned above. Consider the following example
Translating <p>Bees <b>cannot</b> swim</p>. Plain text translation to Spanish is Las Abejas no pueden nadar and the phrase cannot translates as Puede no. Here we need to match Puede no andno pueden which of course wont match with the approach we explained so far.
To address this case, we do not consider sub sequence as a string, but an n-gram where n= number of words in the sequence. The fuzzy matching should be per word in the n-gram and should not be for the entire string. ie. Puede to be fuzzy matched with no and pueden, and no to be fuzzy matched wth no and pueden– left to right, till a match is found. This will take care of word order changes as welll as inflections
Revisiting the 4 type of errors that happen in annotation transfer, with the algorithm explained so far, we see that in worst case, we will miss annotations. There is no case of corrupted markup.
As and when ContentTranslation add more language support, language specific customization of above approach will be required.
You can see the algorithm in action by watching the video linked above. And here is a ascreenshot:
Credits: David Chan, my colleague at Wikimedia, for extensive help on providing lot of example sentences with varying complexity to fine tune the algorithm. The LinearDoc model that make the whole algorithm work is written by him. David also wrote an algorithm to handle the HTML translation using an upper casing algorithm, you can read it from here. The approximation based algorithm explained above replaced it.
A brief note on the workflow I used for font development is as follows
Prepared a template svg in Inkscape that has all guidelines and grid setup.
Draw the glyphs. This is the hardest part. For this font, I used bezier tool of inkscape. SVG with stroke alone is saved. Did not prepare outline in Inkscape, this helped me to rework on the drawing several times easily. To visualize how the stroke will look like in outlined version, I set stroke width as 130, with rounded end points. All SVGs are version tracked. SVGs are saved as inkscape svgs so that I can retain my guidelines and grids.
In fontforge, import this svgs and create the outline using expand stroke, with stroke width 130, stroke height 130, pen angle 45 degree, line cap and line join as round.
Simplify the glyph automatically and manually to reduce the impact of conversion of Cubic bezier to quadratic bezier.
Metrics tuning. Set both left and right bearings as 100 units(In general, there are glyph specfic tuning)
The opentype tables are the complex part. But for this font, it did not take much time since I used SMC’s already existing well maintained feature tables. I could just focus on design part.
Test using test scripts
Some more details:
Design: Santhosh Thottingal
Technology: Santhosh Thottingal and Kavya Manohar
Total number of glyphs: 676. Includes basic latin glyphs.
Project started on September 15, 2014
Number of svgs prepared: 271
Em size: 2048. Ascend: 1434. Descend: 614
242 commits so far.
Latest version: 1.0.0-alpha.20141027
All drawings are in inkscape. No paper involved, no tracing.
Thanks for all my friends who are helping me testing and for their encouragement.
Stay tuned for first version announcement 🙂