This time its Lohit-Gurmukhi (earlier know as Punjabi). We took
decision couple of months back to rename Lohit Punjabi to Lohit
Gurmukhi.  During this name change we also done the improvements
planned in lohit2 project to make font more efficient and effective
across platform. We have done number of improvements from technical as
well from designing (specifically matra) perspective.
*Highlights of 2.91.0 release**are as follows:
* Technical improvements
o Supports guru and gur2 open type script tags.
o Follows AGL specification syntax.
o Open type rules are available in .fea file for easy reusability
o Open type gsub lookups reduction from 10 to 8.
o Corrected glyph class of all glyphs.
o Renamed anchors to GRAnchor.
* Designing improvements
o Improved shape of aivowelguru, oovowelguru,
o "Copy Reference" feature implemented for better reusability of
o Improved grid fitting(GASP) table.
o Tested with Harfbuzz NG and Uniscribe (W8)
o Test file available with release tarball
o Auto test integrated with Makefile ($make test).
Updated lohit project page  for download details. Source tarball
link , TTF tarball link  and webfonts format for Lohit is at .
I would specifically like to thanks A S Alam, Amandeep Saini for
there help in identifying improvements in Lohit Gurmukhi and Sneha to
make this release happen.
Need your help in spreading this news in relevant communities for
testing and identifying critical issues.
On 2/11/14, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
> Le Mar 11 février 2014 21:11, Alec Leamas a écrit :
>> You have good reasons not to give users these fonts. So, this then
>> boils down to "Give users what they should have" vs "Give users what
>> they want". For me, this is not a clear-cut decision.
> What the users want is windows users stopping referencing closed fonts in
> their documents or, as a workaround, access to windows fonts. You can't
> give them either one (you're not giving them windows fonts you're giving
> the old windows fonts with old bugs they won't have under windows).*
> And actually making them think you can give them windows fonts only helps
> perpetuate the problem that required them in the first place.
In any case, FWIW the descriptions should be changed to tell users
that these fonts are outdated and not on pair with current Windows
fonts. OTOH, they buy some compatibility with Windows (same bugs...)
which might be worth it in certain usecases, e. g., when printing
files using these fonts when created.
I should perhaps also lower the config priority from 55 to 60+ (?)
That said, in the best of worlds these fonts should not be used by
other OS:s. But in a situation where Linux has ~1% of the desktop
users (Macos licenses the MS fonts) we don't really create much
pressure to by not being able use them.
Part of the game: many other distros (notably Debian/Ubuntu) packages
msttcorefonts one way or another.
Another argument is that by forcing those who (think they) need these
fonts to use whatever is out there they will probably install a
package which is less up to standard then this one will be (after
review...). After reading the description, they might even decide not
to install it.
I'm not saying you are wrong, just testing the arguments. For now,
let's see if there is anyone interested enough to review these. If
no-one wants to review, then the requests are dead. If there are
reviews, let's test the arguments on a per-case basis there.
On 2/11/14, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
> Le Lun 10 février 2014 12:34, Alec Leamas a écrit :
>> - The upstream spec  does a lot of stuff in %post: (mkfontscale,
>> mkfontdir...). How should I cope with this?
> Legalities aside the upstream spec just uses a packaging style that was
> current in Fedora at the start of the millenium. It tries very hard to
> make stuff like X core fonts work, when Fedora and all knowledgeable
> people have long since determined it was hopeless and should be left to
> die quietly (go wayland go).
> I guess the only reason it was not updated is that everyone with a clue
> has realised it was not a good idea to propagate an obsolete set of fonts
> that can not be updated or fixed due to legal reasons.
> So to answer you questions:
> 1. you won't lose anything significant by using our current font packaging
> templates instead of the upstream one
> 2. it's a very very bad idea to package those fonts and expose them to
> anyone. It encourages developer laziness "I can hardcode windows fonts
> metrics they're available under Linux", it's a legal trap "I can bundle
> windows fonts with my app, after all the Linuxes do it", it's a lie (the
> actual MS fonts people get with windows are several generations later,
> with lots of technical fixes and coverage enhancements, so you'd be
> pushing spoiled goods to innocents).
> Really there is a ton of nicer and more modern fonts on Google fonts
> library waiting for someone to package. Just ignore the mscorefonts
> "common knowledge" which has been cargo-culted in Linux user FAQs for
> years and you'll render a service to everyone involved. We're not in the
> 90's any more there are lots of other opentype fonts to choose from (don't
> you realise "core fonts" means "we are crushing you now Netscape". That's
> ancient history, a few browser wars away!)
> Nicolas Mailhot
Thanks for input! It clarified some things I somehow suspected without
My overall idea so far has been to try to cope with these "Fedora post
installation" guides by incorporating the things often recommended in
rpmfusion. This is basically a "give users what they want" strategy
which of course cannot be used in each and every case.
You have good reasons not to give users these fonts. So, this then
boils down to "Give users what they should have" vs "Give users what
they want". For me, this is not a clear-cut decision.
Part of this is also a question how these fonts works in different
locales. Karel Volny gave some interesting remarks on this in .
Anyway, I have submitted three review requests 3176, 3177 and 3178 for
mscore-fonts, mscore-tahoma-fonts and cleartype-fonts. Perhaps there
are different trade-offs in each case, dunno.
I'm definitely open to just throwing some or all of these requests in
the trash, should this be the right thing to do. After all, I write
this after installing all the stuff, and it does *not* look better on
the screen, on the contrary :)
The msttcore fonts package available at  is a widely used add-on
package for Fedora/rpmfusion. I'm trying to make an official rpmfusion
package (using lpf) to make it possible to install this without
resorting to "out of Fedora" guides etc.
It's just that packaging fonts is real hard, at least for me. I have
made a first attempt available in  and . If anyone has time, it
would be real nice to get some input... some questions:
- All fonts has as of now a .conf file, most of which are just
placeholders. What should I do? Should there be alias or similar stuff
defined for these fonts? Or should I just drop the .conf file?
- The upstream file packages a file in /etc/X11/xorg.conf.d/. What
should I do with this? Drop it? Put into a sub-package? Leave as-is?
- The upstream spec  does a lot of stuff in %post: (mkfontscale,
mkfontdir...). How should I cope with this?
- Although not strictly about fonts, since this gives me the creeps:
are the Obsoletes/Provides OK?
- Other thoughs?
Thanks for any help,
 http://sourceforge.net/projects/ mscorefonts2/?source=directory