fonts February 2014

fonts@lists.fedoraproject.org

5 participants
6 discussions

Announcing alpha release 2.91.0 of lohit-gurmukhi from lohit2 project
by Pravin Satpute 27 Feb '14

27 Feb '14

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 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, auvowelguru,aivowelguru_tippiguru, oovowelguru_tippiguru, auvowelguru_tippiguru,aivowelguru_addakguru, oovowelguru_addakguru,auvowelguru_addakguru, oovowelguru_bindiguru, auvowelguru_bindiguru. o "Copy Reference" feature implemented for better reusability of glyphs. o Improved grid fitting(GASP) table. * Testing 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 [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. Thanks, Pravin Satpute 1. https://bugzilla.redhat.com/show_bug.cgi?id=1047373 2. https://fedorahosted.org/lohit 3. https://fedorahosted.org/releases/l/o/lohit/lohit-gurmukhi-2.91.0.tar.gz 4. https://fedorahosted.org/releases/l/o/lohit/lohit-gurmukhi-ttf-2.91.0.tar.gz 5. https://fedorahosted.org/releases/l/o/lohit/lohit-gurmukhi-web-2.91.0.tar.gz

1 0

[Announce] Released 2.94.0 version of the Lohit Devanagari (Lohit2 project)
by Pravin Satpute 19 Feb '14

19 Feb '14

Hi All, We identified couple of bugs against 2.93.0 release of lohit-devanagari. While more working on same bugs we saw some more opportunity for improvements from glyph positioning tables (GPOS) and using references of glyphs (reusing existing glyphs) rather than copying complete shape. * Following ***improvements *done in this release:* * Positioning lookups cleanup. (Removed 3 unnecessary lookups) * Improved grid fitting (GASP) table. * Renamed anchor points to DVAnchor, it will help in long term for making single Lohit font having all scripts. * Using copy reference instead of copying whole glyph points. * Auto test integrated with Makefile ($make test). * Added Santali language (sat) in fontconfig file. * Resolved #32: "???????? does not render correctly" * Resolved #33: "improper rendering for word : "??????????"" Updated lohit project page [1] for download details. Source tarball link [2], TTF tarball link [3] and webfonts format for Lohit is at [4]. I will soon build this for Fedora. Feel free to report any issues in github[5] I am happy with each release we are moving towards the perfection. Regards, Pravin Satpute 1. https://fedorahosted.org/lohit 2. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-2.94.0.tar.gz 3. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-ttf-2.94.0.tar… 4. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-web-2.94.0.tar… 5. https://github.com/pravins/lohit/issues/new

1 0

Announcing 2.92.0 (Beta-1) release of Lohit Malayalam from lohit2 project
by Pravin Satpute 18 Feb '14

18 Feb '14

Hi All, Here comes the 2.92.0 release of Lohit Malayalam. We done number of improvements and bug fixes over the earlier release [1]. I am happy we able to resolve all reported bugs against alpha in 2.92.0 release. * Following are the highlights:* * We had around 9 below base glyphs not used in any lookup, we removed those glyphs. * Using "copy reference" for glyphs instead of copying whole glyph points in most of the places. * Sfd file size is now 384K, 2.91.0 release was 408K. * Renamed anchor point, it will help in long term for making single Lohit font having all scripts. * Removed Samvruthokaram ligature. * Resolved 10 issues reported on github [2] : #35,#36,#37,#38,.#39,#40.#41,#42,#43,#44. * More test cases in test file. * Auto test integrated with Makefile ($make test) For this release special thanks to Santhosh Thottingal for his detailed review of Alpha. It helped lot to identify key issues. I feel this release is near to final release of Lohit Malayalam and we can consider this as a Beta. Our goal with Lohit2 is to make effective and efficient font which can be used as a reference for new font developments activity. We still need help from community to test it and make sure Lohit is following all standards. Updated lohit project page [3] for download details. Source tarball link [4], TTF tarball link [5] and webfonts format for Lohit is at [6]. Feel free to report any issue AT github. [7] 1. https://www.redhat.com/archives/lohit-devel-list/2014-January/msg00019.html 2. https://github.com/pravins/lohit/issues/<ISSUE-NUM> 3. https://fedorahosted.org/lohit/ 4. https://fedorahosted.org/releases/l/o/lohit/lohit-malayalam-2.92.0.tar.gz 5. https://fedorahosted.org/releases/l/o/lohit/lohit-malayalam-ttf-2.92.0.tar.… 6. https://fedorahosted.org/releases/l/o/lohit/lohit-malayalam-web-2.92.0.tar.… 7. https://github.com/pravins/lohit/issues/new

1 0

Re: Q: Trying to package msttcore fonts.
by Alec Leamas 12 Feb '14

12 Feb '14

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. --alec

1 0

Q: Trying to package msttcore fonts.
by Alec Leamas 12 Feb '14

12 Feb '14

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 [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 Hmm... 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 :) Cheers! --alec [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2483#c53

2 1

Q: Trying to package msttcore fonts.
by Alec Leamas 11 Feb '14

11 Feb '14

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, --alec [1] http://sourceforge.net/projects/ mscorefonts2/?source=directory [2] http://leamas.fedorapeople.org/mscore-fonts/0/msttcore-fonts-2.1-2-1.spec [3] http://leamas.fedorapeople.org/mscore-fonts/0/mscore-fonts.spec [4] http://leamas.fedorapeople.org/mscore-fonts/0/mscore-fonts-1.0-1.src.rpm

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts February 2014