Somvannda Kong | 6 Apr 18:49 2014

Request to change official Khmer font on Fedora

Hi everyone,

My name is Somvannda, I am from Cambodia, and I am a new Fedora Ambassador for Cambodia. 

Well, I noticed that the official Khmer font come within the Fedora was not a good one, since it does not give an easy-to-read for user and the font size is also big. I would like to make a request to change the official font from Khmer OS to Hanuman in the next release. You can find the font here You can also see the statistic that lots of Khmer people are like using this font right now. 

Please let me know if you have any question!

Kindly regards,


Senior IT Officer

Transparency International Cambodia
Address     :  No. 166, Preah Norodom Blvd,

                    Sangkat Tonle Bassac, Khan Chamkarmorn,
                    Phnom Penh, Kingdom of Cambodia
Tel            :  (+855) 23 21 44 30 / 23 21 42 11
HP             :  (+855) 16 34 55 69 / 77 57 78 99
URL           :

fonts mailing list
fonts <at>
Mayank Jha | 13 Mar 13:28 2014

Web Interface for Font Compare

I was wanting to have a web interface for the font quality metric tool FontCompare, which I developed last summer. It is now a plugin for fontforge and I am maintaining it currently. I wished to know if it suited for a GSoC Summer Project Idea 2014 ?
fonts mailing list
fonts <at>
Richard Hughes | 10 Mar 15:51 2014


On 10 March 2014 14:46, Paul Flo Williams <paul <at>> wrote:
>> Is there any precedent here? Like a Punjabi version of "How quickly
>> daft jumping zebras vex" that shows off the majority of the glyphs?

Yes, I saw that, but it doesn't seem to map the locale to the string,
just some languages. I figured (hoped) there'd be some kind of wiki
page with locale -> example text.

fonts mailing list
fonts <at>
Richard Hughes | 10 Mar 13:56 2014



I'm asking a couple of things -- is TT_NAME_ID_SAMPLE_TEXT specified
anywhere? I'd expect it to contain something like "How quickly daft
jumping zebras vex" but I wanted to check that was indeed the kind of
thing it might show.

The seconds is really asking why so few fonts actually use this
metadata item :) Would it be possible to add these in at package build
time, as showing something like "Sample text" using Lohit-Punjabi.ttf
doesn't make sense at all.

I'm also needing a much shorter text string for the icon (e.g. "Aa")
but I guess keying on 'lang' is the best way to do this.


fonts mailing list
fonts <at>
Pravin Satpute | 6 Mar 10:12 2014

Release of Lohit Odia 2.5.5 with names change from Oriya to Odia

Hi All,

   If you recall we had earlier discussion regarding changing name of
Lohit Oriya to Lohit Odia. [1]

   We had a chance to do it with lohit2 project with number of
improvements as we done for Lohit Gurmukhi. Still i think we are already
late for doing this change considering feeling from Odia community around.

   So without doing any further delay this is the release specifically
for renaming Lohit Oriya to Odia. I have updated lohit fedorahosted [2]
page for download details.

   Let me know if anything more needed in this regards.

Pravin Satpute

fonts mailing list
fonts <at>
Akira TAGOH | 4 Mar 05:30 2014

fontconfig config description


I'm adding a feature to enable/disable the fontconfig configuration files from packages for users and
per-users in fonts-tweak-tool and almost has already been implemented in git. I believe this feature
allows more customization around fonts.
One problem on this is, it is quite hard to see what it is for from those filenames. those might contains
multiple rulesets too.

So I'd like to propose adding the description in the certain syntax to the files and the template. and
according to this change I'd encourage packagers to have a separate rulesets if it's useful to do so.

Any comments?

fonts mailing list
fonts <at>
Pravin Satpute | 27 Feb 10:15 2014

Announcing alpha release 2.91.0 of lohit-gurmukhi from lohit2 project

Hi All,

   This time its Lohit-Gurmukhi (earlier know as Punjabi). We took decision couple of months back to rename Lohit Punjabi to Lohit Gurmukhi. [1] 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
    • Supports guru and gur2 open type script tags.
    • Follows AGL specification syntax.
    • Open type rules are available in .fea file for easy reusability
    • Open type gsub lookups reduction from 10 to 8.
    • Corrected glyph class of all glyphs.
    • Renamed anchors to GRAnchor.
  • Designing improvements
    • Improved shape of aivowelguru, oovowelguru, auvowelguru,aivowelguru_tippiguru, oovowelguru_tippiguru, auvowelguru_tippiguru,aivowelguru_addakguru, oovowelguru_addakguru,auvowelguru_addakguru, oovowelguru_bindiguru, auvowelguru_bindiguru.
    • "Copy Reference" feature implemented for better reusability of glyphs.
    • Improved grid fitting(GASP) table.
  • Testing
    • Tested with Harfbuzz NG and Uniscribe (W8)
    • Test file available with release tarball
    • Auto test integrated with Makefile ($make test).
    Updated lohit project page [2] for download details. Source tarball link [3], TTF tarball link [4] and webfonts format for Lohit is at [5].

    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.

Pravin Satpute

fonts mailing list
fonts <at>
Alec Leamas | 12 Feb 11:05 2014

Re: Q: Trying to package msttcore fonts.

On 2/11/14, Nicolas Mailhot <nicolas.mailhot <at>> 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.

fonts mailing list
fonts <at>
Alec Leamas | 11 Feb 21:55 2014

Q: Trying to package msttcore fonts.

On 2/11/14, Nicolas Mailhot <nicolas.mailhot <at>> wrote:
> Le Lun 10 février 2014 12:34, Alec Leamas a écrit :
>> - The upstream spec [2] 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
really knowing.

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 [1].

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 :)



fonts mailing list
fonts <at>
Alec Leamas | 10 Feb 12:34 2014

Q: Trying to package msttcore fonts.

Dear list,

The msttcore fonts package available  at [1] 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 [3] and [4]. 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 [2] 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,


[1] mscorefonts2/?source=directory
fonts mailing list
fonts <at>
Hadal Sandip | 21 Jan 11:51 2014

Please help

How to type hindi word " ज्ञ " in lohit hindi font.
Please reply as early as possible.
fonts mailing list
fonts <at>