[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font license issues
- To: General Arabization Discussion <general at arabeyes dot org>
- Subject: Re: Font license issues
- From: Meor Ridzuan Meor Yahaya <meor dot ridzuan at gmail dot com>
- Date: Wed, 27 Jul 2005 13:30:12 +0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EnIDzZ2bEbWPszXV7mNvrGe/3FgtvK6l2TpCi/11zosajhtlh7H+mkpg/DGPePApTtUcwZEuyHuTBaSPyLS0LhnN/rhDHvI63j+pM4aMls1onBsahHtYcJx9UObKeniADAFS88YkDVAZzbW8vxiyx6gJlVDrAcLg+qjypP/0DOs=
Thank for the input. What you say is true, but the license issues that
I'm trying to focuses on what we do have control, namely the font and
the XML file.
I'll try to contact FSF and creative common, but appreciate if we can
have a discussion here first so that we can have a rough idea on what
we would like to have. I've looked at BitStream license, it might fit
the requirement but I think it need some refinement to suite our need.
About certifying the entire toolchain, well, that is totally seperate
exercise. But I think it is not that difficult to verify it, because
we don't need to verify too many things here. Thing that we really
need to verify is uniscribe (usp10.dll in particular), pango and maybe
freetype (seems you a bit confused between Pango and freetype.
Freetype is just a font rasterizer, nothing to do with text
layout/opentype stuff. That's the job of Pango. The freetype group is
working on one, but in a very early stage). Firefox and Openoffice if
also need to be verified too, but at the moment they seems to have
problems in supporting a normal arabic font.
Regards.
On 7/25/05, Gregg Reynolds <gar at arabink dot com> wrote:
> Meor Ridzuan Meor Yahaya wrote:
> >
> > modified by someone else. When the user look at the font, they will
> > see the author's name. So, who's going to be blame in this case? The
> ...
> > So, this problem applies to the Quran XML files as well. I don't think
> > we can distribute it using GPL. We need something that will be adopted
> > by OSS distributor , but without some illegal modification that will
> > compromise the data.
> >
> > SO far, I don't have any suggestion /solution. Maybe others might have
> > a better suggestion.
> >
>
> I see several issues involved in certification and licensing:
>
> 1. The encoded text itself.
> 2. The font. You need to certify that the font has the glyphs and the
> Opentype tables necessary to render the encoded text properly.
> 3. The font services provider. You need to certify that the font
> service provider properly interprets the font; I don't think all font
> engines understand all Opentype features. (Obviously Freetype is the
> candidate here).
> 4. The rendering client. You need to certify that the client software
> correctly manages the encoded text and correctly requests the right font
> services and correctly displays the result.
>
> That's if you want to certify the entire toolchain involved in rendering
> Quranic text. Then you can offer some kind of assurance that what the
> viewer sees is what you intended, so long as the certified toolchain is
> used. Of course, the user could use any toolchain to view the text, but
> you can explicitly note that the results are then not warranted.
> Ideally, one would bundle the entire thing in one package.
>
> -gregg
>
>
> _______________________________________________
> General mailing list
> General at arabeyes dot org
> http://lists.arabeyes.org/mailman/listinfo/general
>