Problem enabling new language on gdm language selection list
by Rahul Bhalerao
For adding a language on gdm's login screen, apart from having a
locale file, few translations and required fonts, it is required that
language is recognized by fontconfig.
To make a fontconfig recognize the language, a related lang.orth file
is required. With my experiment on this, I think there is also need to
add an entry to fcfreetype.c of fontconfig and related language code
entry in ttnameid.h of freetype2. After making all these changes the
language is listed in the gdm's list. But this has a problem, as the
entries of language code in ttnameid.h are MS and MAC codes for these
languages and there are languages that do not have these codes but are
included in iso639-2 language codes.
Thus my question is, how much important is it to have an entry for the
language in the file fcfreetype.c of fontconfig and related entry in
the header file ttnameid.h of freetype2? And what is to be done for
the language that does not have MS or MAC code? Is it possible to use
our own codes?
Can anyone please help resolving this?
--
Rahul.
http://b.rahul.pm.googlepages.com/home
- http://rahulpmb.blogspot.com
- http://samadiyami.blogspot.com
- http://mazikavita.blogspot.com
15 years, 8 months
Best way to add a line to a config file from another package?
by Vasile Gaburici
I need to add line to /usr/share/texmf/dvips/config/config.ps to get
some extra functionality enabled for lcdf-typetools, namely Type 42
support. The config.ps file is properly marked as a config file in
texlive-texmf-dvips. Is there some infrastructure that's normally used
to hack config files or should I just echo "..." >> config.ps?
15 years, 8 months
Re: [Fedora-packaging] Are there *any* guidelines for what "Group:" an application should go in?
by Vasile Gaburici
Thanks for the info. I see it is possible to add a package to multiple
comps.xml groups, which is more flexible that what "Group:" can
express. Still, it would be nice if anaconda had a search box like
PackageKit...
On Fri, Aug 8, 2008 at 9:34 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> Vasile Gaburici wrote:
>>
>> Furthermore, are there any guidelines for the creation of new groups?
>>
> Pretty much no. We've settled on using comps for grouping of packages
> rather than the Group: tag. That said, it's probably best to use one of the
> existing groups (listed in /usr/share/doc/rpm-%{version}/GROUPS
>
> -Toshio
>
>
15 years, 8 months
Re: TeXGyre fonts licensing concern
by Nicolas Mailhot
Hi,
I'm afraid these answers are utterly unconvincing. I've just checked
Debian made the very same analysis as us, and you're on your way to get
yourself blacklisted in all major Linux distributions.
https://bugs.launchpad.net/ubuntu/+source/texlive-extra/+bug/135911/comme...
In case that's not clear enough, you have a problem.
On Sat, 2008-07-26 at 12:48 +0200, Hans Hagen wrote:
> Jonathan Underwood wrote:
> > Dear Hans,
> >
> > Some legal concerns have arisen regarding the licensing of the TeX
> > Gyre fonts - please see
> > https://bugzilla.redhat.com/show_bug.cgi?id=456580. In particular,
> > this part is most relevant:
> >
> > 2. The textlive-texfm includes tex-gyre fonts. As the authors freely
> > admit they lifted the GNU Ghostscript GPL fonts, changed their format,
> > modified the result,
> > and relicensed it all under their own license [1]. They don't list any
> > authorization for this from the previous rights holders in their
> > package. Since we can not ship the GPL bits they lifted under another
> > license, and we can not ship the bits they added under the GPL without
> > tex-gyre people authorization, the whole thing is un-distributable and
> > must be removed [2]
> >
> > [1] page 8 of http://www.gust.org.pl/projects/e-foundry/tex-gyre/afp05.pdf
> > [2] http://www.redhat.com/archives/fedora-fonts-list/2008-July/msg00111.html
> >
> > I wonder if you would take a few moments to look at this and comment
> > on the correctness of the analysis and help to resolve these issues? I
> > am sure you'd agree with me that resolving this is important for the
> > TeX Gyre project, and free software fonts in general.
> >
> > Finally, in case it's not clear, I'd just like to point out that I am
> > *not* contacting you in my capacity as chair of the UKTUG funding
> > sub-committee in this instance, but as a member of UKTUG, and also a
> > Fedora contributor. Nonetheless, as a UKTUG member I would not be
> > happy to think that UKTUG is financially supporting a project which is
> > in violation of the GPL, if that is indeed the case.
>
> a short reply (i have to catch up many mails after the tug conference)
>
> - the gust font licence is mostly the lppl licence which is accepted as ok
Irrelevant. We are not complaining about the Gust font license we are
complaining about re-licensing without previuous authors authorization.
> - the main 'additions' concern packaging (file names, internal font
> names, etc. since any simple replacement/extension can mess up doc
> production and could put a stress on user group support), which is an
> important issue for tex distributions
That's still a lot of work. We respect licensing regardless of the size
of the contribution
> - gpl is targeted at programs and fonts are not exactly programs
Given the number of fonts we ship under GPL, LGPL or derived licenses
(including Liberation), this argument is not receivable. "I don't like
this license I'll just use another and no one's the wiser" — you're not
serious.
> - we try to contact e.g. urw on some other issues (it's currently not
> even clear of some of the fonts were ever legally gpl'd!) but they don't
> react (such a kind of 'disappearing responsibility' happened before with
> some other font where eventually responsibility was transfered to tug)
You can not work just with URW. The right contacts are Artifex and all
the people who contributed to the fonts since their release.
> - some of the 'original' fonts contain additions of rather poor quality
> (greek and cyrillic) and when/how they ended up in there withoput any
> quality assurance is unclear, so in general one can say that these fonts
> have a somewhat fuzzy history
Quality as nothing to do with licensing. You can make bad contributions
under a good license, and good contributions under a bad license. We can
ship the first but not the other.
> we're currently convinced that eveything is ok with respect to the
> licence (btw, the amount of changes to the fonts are pretty large so one
> might as well wonder if we're dealing with new digitizations)
Again, this is the kind of fuzzy logic that can not stand legaly.
> Jerzy might have a more detailed answer since he's in charge of the
> licencing
--
Nicolas Mailhot
15 years, 8 months
Re: TeXGyre fonts licensing concern
by Nicolas Mailhot
On Mon, 2008-07-28 at 11:25 +0200, Hans Hagen wrote:
> Nicolas Mailhot wrote:
>
> > I'm afraid these answers are utterly unconvincing. I've just checked
> > Debian made the very same analysis as us, and you're on your way to get
> > yourself blacklisted in all major Linux distributions.
>
> hm, you == tex-community or gust-foundry or ?
Just TEX-Gyre so far but it does raise questions about all the entities
that redistributed this work.
Regards,
--
Nicolas Mailhot
15 years, 8 months
Maithili language support gdm problem in Fedora
by Parag Nemade
Hi,
We have already missed F10 Alpha release and I am still struggling
to get Maithili language support included in rawhide. The problem I see
is that we need to modify fontconfig package to include Maithili
language. I submitted bug[1] to add Maithili in bugzilla against
fontconfig 3 months back. But package maintainer of fontconfig closed it
instantly and made it upstream[2].
I submitted required input in upstream bug. But, still no response
from upstream. If package maintainer is not willing to do code level
changes and also upstream then I will see no progress to add Maithili
language support in Fedora. So even if we will get translations and all
other changes done in Fedora by F10 release to support Maithili, users
will not able to see Maithili language selection in gdm.
Can anyone provide inputs on this issue? Otherwise I will move ahead
and will commit required changes in rawhide and build new package as I
can see ACLs are open on fontconfig.
Regards,
Parag.
[1] *Bug 441995* <https://bugzilla.redhat.com/show_bug.cgi?id=441995> -
[mai_IN] fc-list does not show Maithili language name
[2] https://bugs.freedesktop.org/show_bug.cgi?id=15821
15 years, 8 months
TeXLive 2008 in F10?
by Vasile Gaburici
Are there any plans to include TeXLive 2008 in F10? Currently a
preview is available, which is essentially a release candidate. I
works fine for me on F9, but I have not packaged it.
I understand that the new TeXLive 2008 installer and packaging system
is a lot of work to deal with, but TeXLive includes LuaTeX, which is
the designated successor to pdfTeX, being developed by the same people
that maintain pdfTeX, which won't get any signifiicant new features.
So, for all practical purposes LuaTeX is the "new TeX".
LuaTeX can already use OpenType fonts (towards which Fedora is
moving), although not for math for which there are no usable *free*
Unicode fonts available right now (the only usable one being Cambria
Math from MS). There is no OpenType support planned for pdfTeX, so
it's important to get users exposed to LuaTeX as early as possible,
and Fedora is a good way of doing this :)
The entire TeXLive 2008 system uses a new kpathsea replacement written
in Lua, which is *many* times faster the original. This results in
major speed improvements for all TeX programs.
The "packetization" of TeXLive, plus the support in LuaTeX for
OpenType fonts should make the TeX fonts mess (bug 456580) a more
tractable problem, even though it won't solve it right away.
Also, TeXLive 2008 includes lcdf-typetools, which I was planning to
package separately - the package has been orphaned around FC6 or so.
The main issue that I see is how to deal with 1Gb+ of TeXLive 2008
packages (over 1000). Perhaps something similar to cpan2rpm is in
order?
15 years, 8 months
Fwd: Maithili language support gdm problem in Fedora
by Rahul Bhalerao
forwarding on fedora-i18n-list as well.
---------- Forwarded message ----------
From: Rahul Bhalerao <b.rahul.pm(a)gmail.com>
Date: Wed, Aug 6, 2008 at 3:42 PM
Subject: Re: Maithili language support gdm problem in Fedora
To: "Parag N(पराग़)" <panemade(a)gmail.com>
On Wed, Aug 6, 2008 at 1:03 PM, Parag N(पराग़) <panemade(a)gmail.com> wrote:
> Hi,
> We have already missed F10 Alpha release and I am still struggling
> to get Maithili language support included in rawhide. The problem I see
> is that we need to modify fontconfig package to include Maithili
> language. I submitted bug[1] to add Maithili in bugzilla against
> fontconfig 3 months back. But package maintainer of fontconfig closed it
> instantly and made it upstream[2].
> I submitted required input in upstream bug. But, still no response
> from upstream. If package maintainer is not willing to do code level
> changes and also upstream then I will see no progress to add Maithili
> language support in Fedora. So even if we will get translations and all
> other changes done in Fedora by F10 release to support Maithili, users
> will not able to see Maithili language selection in gdm.
> Can anyone provide inputs on this issue? Otherwise I will move ahead
> and will commit required changes in rawhide and build new package as I
> can see ACLs are open on fontconfig.
>
How much important is it to have an entry for the language in the file
fcfreetype.c of fontconfig and related entry in the header file
ttnameid.h of freetype2?
I observed that to have the language listed in gdm selection list,
both of these entries are necessary. But that raises one more question
that is, for languages that do not have MS or MAC codes, what has to
be done as all the language and their codes listed in these files are
defined according to the MS and MAC codes? There are many languages
including Maithili, in iso639-2 that do not have such codes.
_
Rahul.
--
Rahul.
http://b.rahul.pm.googlepages.com/home
- http://rahulpmb.blogspot.com
- http://samadiyami.blogspot.com
- http://mazikavita.blogspot.com
15 years, 8 months