Summary: | [ebuild] Lohit fonts (fonts-indic) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arun Raghavan (RETIRED) <ford_prefect> |
Component: | [OLD] Unspecified | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | dschridde+gentoobugs, fonts |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://hi.wikipedia.org | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Initial verstion -- lohit-2.0.9.ebuild
Simpler, all-fonts version Ebuild for 2.1.3, with some extra dodoc stuff Updated SRC_URI pointing to tarball Minor header change over the last ebuild |
Description
Arun Raghavan (RETIRED)
2006-12-06 07:53:36 UTC
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. |