Here's an ebuild to install the Lohit indic fonts from the Fedora Core tree. This pulls in the source RPM, unwraps, and installs. There are 9 supported languages, and the user can select the required ones using LINGUAS. It's like the acroread-asianfonts ebuild -- if none of the languages are set in LINGUAS, the ebuild dies. IUSE is set up using a small for loop in global scope. It helps make the language name <-> linguas mapping simple. Will rewrite if this is a no-no.
Created attachment 103454 [details] Initial verstion -- lohit-2.0.9.ebuild
I am willing to maintain this package if someone can sanitize and check in changes. I think that this would be a useful package -- it provides a lot of popular language Indian language fonts under one heading, and the fonts are quite decent.
I'm not quite sure it's a good idea to use LINGUAS for compile time font selection. LINGUAS is about translations, not support for rendering the fonts correctly. Why not supply them all unconditionally or another possibility is splitting up the package ?
(In reply to comment #3) > I'm not quite sure it's a good idea to use LINGUAS for compile time font > selection. LINGUAS is about translations, not support for rendering the fonts > correctly. Okay. How about plain old USE-flags? I started with USE-flags but then I switched to LINGUAS because that's how acroread-asianfonts does it. My original behaviour was actually to install all if no languages are specified. > Why not supply them all unconditionally or another possibility is splitting up > the package ? We don't want to supply them all unconditionally because a user might prefer some other font for a given language. I didn't split it into separate ebuilds because it's nice to be able to pull in all these fonts at one shot (and have most of the Indian languages on Wikipedia just work). With the USE-flags behaviour I described above we get a good tradeoff between allowing the user to pick what (s)he wants, and a nice default. That first ebuild I wrote is available at http://nemesis.accosted.net/temp/lohit/lohit-2.0.9.ebuild
I don't particulary like introducing USE flags for such corner cases either. I really see no reason still to not install all of them, with font configuration you can select which font to use as preffered one for a certain script. Are these fonts overlapping eachothers unicode blocks ?
(In reply to comment #5) > I don't particulary like introducing USE flags for such corner cases either. I > really see no reason still to not install all of them, with font configuration > you can select which font to use as preffered one for a certain script. Okay. Is this a simple task? Another alternative is a separate ebuild per language, and a meta-ebuild to pull in everything? Keep all (imaginary?) camps happy? > Are these fonts overlapping eachothers unicode blocks ? They are in separate Unicode blocks corresponding to the respective languages.
Created attachment 103661 [details] Simpler, all-fonts version Okay, this version just installs all the fonts. Maybe we can just put this in, and if users want per-language functionality, we can just add that? If per-language builds and a meta-build are preferable, I can write that, but I figured it's easier to keep things simple rather than provide for a need which may or may not exist.
(In reply to comment #7) > Created an attachment (id=103661) [edit] > Simpler, all-fonts version > > Okay, this version just installs all the fonts. Maybe we can just put this in, > and if users want per-language functionality, we can just add that? > > If per-language builds and a meta-build are preferable, I can write that, but I > figured it's easier to keep things simple rather than provide for a need which > may or may not exist. > is this project dead...?
(In reply to comment #8) > (In reply to comment #7) > > Created an attachment (id=103661) [edit] > > Simpler, all-fonts version > > > > Okay, this version just installs all the fonts. Maybe we can just put this in, > > and if users want per-language functionality, we can just add that? > > > > If per-language builds and a meta-build are preferable, I can write that, but I > > figured it's easier to keep things simple rather than provide for a need which > > may or may not exist. > > > > is this project dead...? I just got a whole bunch CVS commit mails on lohit-devel, so I don't think it is.
> I just got a whole bunch CVS commit mails on lohit-devel, so I don't think it > is. On a related note. The latest version is 2.0.12 -- a simple bump of the ebuild will suffice. Could someone commit this if it looks okay (I would be glad to maintain the package)?
Created attachment 112241 [details] Ebuild for 2.1.3, with some extra dodoc stuff This bumps to the latest version on Fedora development, and adds some dodoc stuff.
Hi Arun, I did wind up making some changes to your submitted ebuild: 1. I employed the versionator eclass, which allowed me to version the ebuild as 2.1.4.1 instead of just 2.1.4 (yeah, there was a version bump upstream so 2.1.3.1 wasn't even on their download site). 2. We dont' need to explicitly call rpm_src_unpack, since portage calls that automatically. 3.. I moved the fonts relocation stuff into src_compile() instead, and employed the find command, so that it will be a little more scaleable (and we don't have to keep explicit track of the available fonts). 4. The font.eclass is capable of installing docs, you just have to let it know what they are with the DOCS variable in the ebuild. 5. Miscellaneous: changed the package name to fonts-indic, to match upstream. Thanks for submitting the ebuild, I hope you'll be active in helping to maintain it!
Created attachment 114903 [details] Updated SRC_URI pointing to tarball This should be slightly cleaner * rpm and versionator eclasses not required any more * Corresponding MY_* variables also not required * SRC_URI uses mirror://gentoo/ * the tarball needs to be manually put into distfiles :(
Newer, cleaner ebuild.
Created attachment 114904 [details] Minor header change over the last ebuild Sorry for the spam.
thanks arun for future version bumps, please file a new bug.
