Description of problem: Majority of Kerala community work using traditional script fonts. Thus there is a huge demand to include the popular traditional scripts like Rachana, Meera in fonts-indic package. There is an archive called smc-fonts-malayalam in smc upstream containing Rachana, Meera, Mal0tf fonts. Rachana, Meera are traditional scripts and Mal0tf is based on a new script. Since all these fonts are popular and in great demand from community, these fonts also have to be included in fonts-indic. smc-fonts-malayalam available at: http://download.savannah.nongnu.org/releases/smc/fedora/8/SRPMS/ Thanks Ani
Looking forward to seeing it in Fedora repos. One package less to worry about in smc repo :-)
The smc-fonts-malayalam package in SMC repo works fine in Fedora 7 & 8 and it will be really useful for those who use Malayalam in Fedora.
Hi all, Please remember the following points: 1. There is no need to integrate all the indic fonts on earth in the fonts-indic packages. If different fonts are released by different groups it is much easier to manage separate packages (multi-source multi-project srpms are a maintenance hell, you never know what release number or license to use). So please track the original source of every font you want added and propose them separately. 2. We have an official fonts wishlist there http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes 3. Given those fonts should be packaged separately, and waiting for someone else to work on them can be long and frustrating, I invite you all to try your hand at fonts packaging. It's not difficult (if time consuming) and mostly requires actively using the fonts and liaising with their upstream. We have very detailed font packaging guidelines there: http://fedoraproject.org/wiki/SIGs/Fonts/Packaging If there is a problem in those instructions and you don't understand something you can ask help on the Fedora fonts list http://fedoraproject.org/wiki/SIGs/Fonts#ML Once you've packaged some fonts following those guideline Fedora inclusion process follows the usual Fedora process http://fedoraproject.org/wiki/PackageMaintainers/Join The only block on including more fonts in Fedora right now is lack of people working on font packaging, new package review is usually blinding fast, so if you know one or several font you'd like in packaging them directly will be faster and easier than opening bugs on existing packages
(In reply to comment #3) > Hi all, > > Please remember the following points: > > 1. There is no need to integrate all the indic fonts on earth in the fonts-indic > packages. If different fonts are released by different groups it is much easier > to manage separate packages (multi-source multi-project srpms are a maintenance > hell, you never know what release number or license to use). So please track the > original source of every font you want added and propose them separately. > True. I think fonts-indic should be marked for removal now. Its better to handle fonts grouping in comps. As of now most of the fonts (Indic, arabic,hebrew etc.) are packaged according to the upstream projects, all separated. So fonts-indic, fonts-hebrew etc. are not useful anymore. > 2. We have an official fonts wishlist there > http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes > Thanks for this link. <snip> > The only block on including more fonts in Fedora right now is lack of people > working on font packaging, new package review is usually blinding fast, so if > you know one or several font you'd like in packaging them directly will be > faster and easier than opening bugs on existing packages As I observe, people have started taking interest in font packaging. I hope things will improve soon. @Ani(or smc guys), Instead of a link to srpm, can you provide a link to upstream sources of either the font files or the tarballs? btw, I assume we were waiting for a latest bug free release of these font.So just wait for a while, I will handle the packaging and review by next week.
Latest upstream release with the fixes are available now from http://download.savannah.nongnu.org/releases/smc/fonts/ Hoping to see the package in rawhide soon.
(In reply to comment #5) > Latest upstream release with the fixes are available now from > http://download.savannah.nongnu.org/releases/smc/fonts/ I can see four different fonts here. Is it fine to call them collectively as smc-fonts-malayalam, especially RaghuMalayalamSans is a concern?
RaghuMalayalamSans needed some modifications and it is now maintained by smc. I guess it is ok, but if you feel just malayalam-fonts is better go ahead and use that.
Dyuthi is also added to the release now, making the number of fonts to 5.
I would prefer just smc-fonts-malayalam or have separate packages with names corresponding to each upstream project with all due credits :) The guidelines for this are here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines
I just noticed in upstream tar ball except suruma all fonts license is "All rights reserved", and it doesn't mention any opensource license. According to fedora licensing guideline, it is difficult to include these fonts in fedora. If possible please change license to 'Gplv3 with Font Exception' or OFL 1. http://www.gnu.org/licenses/gpl-faq.html#FontException 2. http://scripts.sil.org/OFL
(In reply to comment #10) > I just noticed in upstream tar ball except suruma all fonts license is "All > rights reserved", and it doesn't mention any opensource license. > According to fedora licensing guideline, it is difficult to include these fonts > in fedora. > If possible please change license to 'Gplv3 with Font Exception' or OFL > 1. http://www.gnu.org/licenses/gpl-faq.html#FontException > 2. http://scripts.sil.org/OFL > Any update please?
All fonts have GPL as license and it is embedded in the font itself. You can open it in fontforge and see the license. If you prefer separate license file you can copy those license texts to another file.
(In reply to comment #10) > I just noticed in upstream tar ball except suruma all fonts license is "All > rights reserved", and it doesn't mention any opensource license. > According to fedora licensing guideline, it is difficult to include these fonts > in fedora. > If possible please change license to 'Gplv3 with Font Exception' or OFL > 1. http://www.gnu.org/licenses/gpl-faq.html#FontException > 2. http://scripts.sil.org/OFL > When opening the fonts in fontforge, under the option Element->Font Info->TTF names->License you have all necessary information regarding the license. Thanks Ani
Normally developer includes License information in copyright section itself, so people even without fontforge can see license, as copyright section is viewable in gnome-font-viewer also, even in suruma font you have done that. Thanks for Information!!! I will do the needful and comment about updates :)
Yes, Users should able to see license and other metadata info of the font. And Praveen have submitted a patch to gnome-font-viewer for the same. Please refer http://bugzilla.gnome.org/show_bug.cgi?id=477784 and http://bugzilla.gnome.org/show_bug.cgi?id=407605
A detached license is much more user-friendly, and our guidelines forbid creating it in the project stead
OK. I have created a detached copyright/license file - COPYING.txt I hope there is no further issues blocking this. Also please comment at the gnome bugzilla if you think gnome font viewer should show the license along with copyright notice.
done packaging waiting for review https://bugzilla.redhat.com/show_bug.cgi?id=440373 some comment on upstream tarball fonts version should be inside fonts, no need for fontname_version since all ready tarball has version malayalam-fonts doesn't mention upstream project name it will be good if you change its name to 'smc-fonts' or 'smc-malayalam-fonts' since all fonts content different license it will be nice if you can keep the same license for all fonts if possible
* We don't want to have version embedded with font names - we used to have Rachana_w01, Rachana_g01 inside the fonts and we decided best way is not to have the versions as a newer version font cannot show the documents which use older version of fonts. We needed the version difference to be visible to the users, so we are keeping the version in filename. * It is not necessary that everyone use the entire tarball but individual fonts and so we are keeping version for each font. * you can change the rpm package name to anything you wish. * All fonts are developed by different authors and we can't decide on a common license. I don't see it as a problem because the package is an aggregation and not a derivative work.
Pravin, its really upto you how to name and version the upstream project. My concern about version is, the version '04' for a tarball looks odd, unlike many other project that would follow 'a.b.c' kind of format. But its ok as far as its not creating any problem. Another concern is since it is an aggregation of multiple projects, how are you going to going to maintain the version of aggregation w.r.t. the individual fonts' versions? Will the version '04' be updated to a higher value for any change in any of the files inside the tarball, as is the case with lohit and samyak? This came to my mind because, it was observed earlier that, some font was added to the tarball without the version of tarball being updated.
(In reply to comment #19) > * We don't want to have version embedded with font names It's your choice to make of course. My advice as a packager would be to have a foo-a.b.tar.bz2 for font foo with license X packaged as foo-fonts-x.y, and a bar-c.d.tar.bz2 for font bar with license Y packaged as bar-fonts-c.d, but you can perfectly choose srpm multiplexing hell with a single source archive mixing all sorts of different stuff. The user will mostly not see the difference (except when trying to locate the right component to report bugs on), all the complexity will be packager-side.
The updates required till now is applicable for all the fonts and we have to update al the fonts and hence a common version made sense to us. I don't see we might need to change that. As for adding packages to the tarball - we created this tarball mainly for Fedora - as everyone else (debian packaging and other users) were happy with using individual fonts. So I thought till Fedora is fully happy with the tarball and start packaging it, we can change it as needed.
In that case I strongly advise you to go with one tarball per font project (one version, one license file), with simple packages that follow closely the Fedora guidelines. I'm sure Debian will be happy about it too (in fact we share an irc channel with the debian font packagers and they moan about the same things as us)
Now no need for this now, i have handled all the complexity at packaging side already since i have done subpackaging for this tarball according to fedora packaging guidline's, and it is in process of new package review https://bugzilla.redhat.com/show_bug.cgi?id=440373 Soon it will get included in Fedora :)
Done, smc-ftons is now in fedora-cvs once it is sink with repos, you can install it from fedora-rawhide
sorry for typo package name is smc-fonts
Please do not forget to update comps in cvs and the http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline page
nicolas thanks for reminder :) surely i will do this
Pravins, Nicolas, Rahul, Jensp, thanks a lot for all help to include smc-font in Fedora. Regards Ani
included in fedora package name: smc-fonts