Bug 433584 - [ml_IN] Traditional scripts (smc-fonts) to be included in fonts-indic
Summary: [ml_IN] Traditional scripts (smc-fonts) to be included in fonts-indic
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: lohit-fonts
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Rahul Bhalerao
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-20 05:30 UTC by Ani Peter
Modified: 2016-08-01 01:31 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-04-24 11:28:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ani Peter 2008-02-20 05:30:23 UTC
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

Comment 1 Praveen A 2008-02-20 05:45:18 UTC
Looking forward to seeing it in Fedora repos. One package less to worry about in
smc repo :-)

Comment 2 libregeek 2008-02-20 06:51:42 UTC
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. 

Comment 3 Nicolas Mailhot 2008-02-20 08:38:47 UTC
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

Comment 4 Rahul Bhalerao 2008-02-20 09:29:01 UTC
(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.

Comment 5 Praveen A 2008-03-12 17:44:11 UTC
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.

Comment 6 Rahul Bhalerao 2008-03-13 10:53:45 UTC
(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? 


Comment 7 Praveen A 2008-03-13 15:14:57 UTC
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.

Comment 8 Praveen A 2008-03-13 17:43:16 UTC
Dyuthi is also added to the release now, making the number of fonts to 5.

Comment 9 Rahul Bhalerao 2008-03-13 20:30:04 UTC
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

Comment 10 Pravin Satpute 2008-03-19 09:37:37 UTC
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


Comment 11 Rahul Bhalerao 2008-03-24 11:59:10 UTC
(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?



Comment 12 Praveen A 2008-03-26 11:58:51 UTC
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.

Comment 13 Ani Peter 2008-03-26 12:18:56 UTC
(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

Comment 14 Pravin Satpute 2008-03-26 12:55:34 UTC
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 :)

Comment 15 Santhosh Thottingal 2008-03-26 14:59:46 UTC
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

Comment 16 Nicolas Mailhot 2008-03-26 15:20:47 UTC
A detached license is much more user-friendly, and our guidelines forbid
creating it in the project stead

Comment 17 Praveen A 2008-03-31 12:33:30 UTC
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.

Comment 18 Pravin Satpute 2008-04-03 06:49:29 UTC
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 


Comment 19 Praveen A 2008-04-14 06:22:43 UTC
* 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.

Comment 20 Rahul Bhalerao 2008-04-14 07:06:02 UTC
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. 

Comment 21 Nicolas Mailhot 2008-04-14 07:34:13 UTC
(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.

Comment 22 Praveen A 2008-04-14 08:04:39 UTC
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.


Comment 23 Nicolas Mailhot 2008-04-14 08:54:45 UTC
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)

Comment 24 Pravin Satpute 2008-04-14 09:09:40 UTC
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 :)


Comment 25 Pravin Satpute 2008-04-16 05:53:35 UTC
Done, smc-ftons is now in fedora-cvs
once it is sink with repos, you can install it from fedora-rawhide

Comment 26 Pravin Satpute 2008-04-16 06:04:17 UTC
sorry for typo
package name is smc-fonts

Comment 27 Nicolas Mailhot 2008-04-16 07:17:24 UTC
Please do not forget to update comps in cvs and the
http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline page

Comment 28 Pravin Satpute 2008-04-16 09:22:34 UTC
nicolas thanks for reminder :)
surely i will do this 

Comment 29 Ani Peter 2008-04-16 09:25:32 UTC
Pravins, Nicolas, Rahul, Jensp, thanks a lot for all help to include smc-font in
Fedora.

Regards
Ani

Comment 30 Pravin Satpute 2008-04-24 11:28:55 UTC
included in fedora
package name: smc-fonts


Note You need to log in before you can comment on or make changes to this bug.