Re: contact kurditgroup
by Michal Nowak
ping?
On 09:57 Wed 16 Jul , Michal Nowak wrote:
> Hi Bardaqani,
>
> sorry for not being clear on this for the first time.
>
> The problem with GPL licensed font is that when you for example
> create PDF file (like a book) the you usually embed the font inside
> the document and then is anyone able to see it correct even
> when he does not have the Kurdish font in system (really good thing).
>
> But: When you have used GPL font (like Unikurd Web) inside PDF file
> then you must license the file/book as a GPL too! And that's the
> problem.
>
> Because of this there's special Font Exception which solves that
> problem.
>
> What would help us a lot:
>
> 1. Re-license the fonts from 'GPLv3' to 'GPLv3 + exception'.
> Here's the link to such text:
> http://www.gnu.org/licenses/gpl-faq.html#FontException
>
> 2. Write the text from the above link to the file gpl.txt inside
> unikurdweb.zip file.
>
>
> Solving points 1. and 2. will help us to distribute Your font in
> Fedora and thus helpfull for Kurdish writing/speaking users in
> general.
>
> Don't hesitate and write me in case of another questions or if
> you need any further guidance.
>
> Thank you,
> Michal
>
>
> On 23:43 Tue 15 Jul , bardaqani bardaqani wrote:
> > Dear Michal,
> > How can help you? should we out the license inside a PDF or what?
> > let me know
> >
> > cheers
> >
> >
> >
> > On Wed, Jul 16, 2008 at 12:47 AM, <mnowak(a)redhat.com> wrote:
> >
> > > <div dir='rtl' style='direction: rtl; text-align: right' align='right'>.Hi,
> > > I wish I package some Unikurd fonts to Fedora Linux distribution<br />
> > > <br />
> > > The problem is actually the chosen license, which is plain GPLv3. Here you
> > > can read why is the license not so well usable for usage e.g. inside PDF.
> > > <br />
> > > <br />
> > > http://www.fsf.org/licensing/licenses/gpl-faq.html#FontException <br />
> > > <br />
> > > Please reply to my email mnowak(a)redhat.com for further information or
> > > point me to someone whom can I talk to. <br />
> > > <br />
> > > Thank you for you time,<br />
> > > Michal Nowak<br />
> > > <br />
> > > Michal Nowak uid:0<br />
> > > <br />
> > > 2008-07-15<br />
> > > </div>
> > >
15 years, 1 month
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, 3 months
457281: Review Request: unikurd-fonts - A widely used Kurdish font
by Michal Nowak
SSIA but ... :)
* Tue Jul 30 2008 Michal Nowak <mnowak(a)redhat.com> - 1.00-1
- initial packaging
- this package should be prepared for another unikurd fonts
in sub-packages because on the KurdIT group/unikurd web there
are dozens of them, but probably not under suitable licenses
--
Michal Nowak
BaseOS QE (Apps/Toolchain sub-group) Engineer
15 years, 4 months
TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici
I did not have time finish writing all the details below, I'll write
some more tonight, but before this Type 1 bashing gets out of hand,
read the stuff below. If you don't want the gory details, the bottom
line is that the mainstream TeX still works best with type-1 fonts.
And it isn't likely to go away soon. So I would not rush to deprecate
type 1 fonts, unless you want TeX users to stop using Fedora. This
isn't likely to change anytime soon. XeTeX is not as robust as the old
TeX, and still lacks some features next to pdftex. XeTeX's acceptance
with academic publishers is virtually nil today. And they, the
publishers dictate what most academics use to write papers, books etc.
The mainstream TeX (and by that I mean dvips, dvipdfm and pdftex)
cannot currently use OpenType/CFF, but only Type 1 (and some TeX font
specialties that are irrelevant in this discussion). CFF fonts need to
be converted to Type 1 using otftotfm. Several tools exist to automate
the CFF to Type 1 conversion for large font families because this can
be a LOT of work using otfotfm directly for fonts that have optical
sizes (like the Adobe Pro series). The most notable automation tools
are, in order of how complete they are: autoinst from fontools,
otfinst, and otftofd. Each has some features the other lacks, however.
Most notably fontools lacks optical size support. Some LaTeX packages,
like MinionPro, have their own otfotfm wrapper scripts, which are a
lot easier to use because some files (enc, fd) come pre-generated.
Furthermore, dvips and dvipdfm cannot use TrueType fonts directly
(regardless whether they have OpenType features), but can convert them
to bitmap PK fonts, which print ok, but may look bad on screen. In
contrast pdftex can embed TrueType as outlines in the pdf using
\DeclareTruetypeFont. Unfortunately, generating the TeX infrastructure
(tfm font metrics, encodings) for TrueType fonts requires MORE work
than generating the Type 1 from a CFF. This happens because a
different, less featured tool must be used: ttf2tfm. There are some
wrappers like ttf2tex (no longer maintained), and fontinst, which is
rather outdated. Autoinst (from fontools) is the only tool that
handles both OpenType CFF and TrueType.
Most tutorials for using TrueType with pdftex recommend using ttf2tfm directly.
FYI: XeTeX uses dvipdfmx as backend, which supports all flavors of
OpenType, but this requires xdv input that is not the same as the
traditional dvi produced by TeX. pdftex does not produce any
intermediate format.
For some simple usage examples see (note - first one is XeTeX):
http://existentialtype.net/2008/07/12/fonts-in-latex-part-one-xelatex/
http://existentialtype.net/2008/07/12/fonts-in-latex-part-two-pdftex-and-...
http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-an...
A complex example using Gentium via ttf2tfm:
http://tclab.kaist.ac.kr/ipe/pdftex_3.html
To be continued...
On Fri, Jul 25, 2008 at 2:33 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote:
>> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote:
>> >
>> > Frankly, the other font formats are so much less useful than modern font
>> > formats, the probability someone did creative legal restructuring is
>> > much lower.
>
> Anyway, I've amended the proposal in a less format-oriented version
> https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_ot...
>
>> > The big exception are Type1 fonts but I just hope they can
>> > die die die (and if the Tex-Gyre situation is fixed and we can use OTF
>
>> I don't think this may happen in a while because some very interesting
>> apps (though not mainstream desktop apps, fortunately) uses type1
>> fonts, mostly using t1lib, like xfig, xdvi, grace.
>
> Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that
> OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be
> surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly.
>
> Do we really have so much interecting stuff that depends on Type1 once
> TEX and GS are out of the way?
>
>> > In the meanwhile, it may make sense to add Type1 to the list.
>>
>> For tex I believe that it will be too complicated to use the system
>> fonts.
>
> TEX now uses the same formats as everyone else (TTF and OTF). I frankly
> do not think we can afford (or have the resources) to duplicate megs of
> fonts in TEX-specific packages. If TEX can not use the fonts in
> fontconfig directories, it just has to symlink them somewhere it can.
>
> Regards,
>
> --
> Nicolas Mailhot
>
> --
> Fedora-packaging mailing list
> Fedora-packaging(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
>
>
15 years, 4 months
freetype 2.3.6+ has significant improvements in hinting
by Vasile Gaburici
I've been using a CVS snapshot of freetype 2.3.8 for a few days and I
have to say I'm impressed by the improvements in hinting, even when
it's just the auto-hinter. From the Changelog it seem that all the
hinting improvements occurred in 2.3.6, which is currently in rawhide.
There was improvement across the board: PS, CFF and TTF, but the CFF
hinting had significant portions rewritten, which should bode well
with the strategy to prefer OpenType CFF fonts.
I think that freetype 2.3.6 (at least) should be pushed to F9 updates
too, unless you want to list "better hinting" as a feature for F10 :p
15 years, 4 months
Fwd: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici
Forwarding to the lists what I've just sent Jonathan...
---------- Forwarded message ----------
From: Vasile Gaburici <vgaburici(a)gmail.com>
Date: Sun, Jul 27, 2008 at 7:23 PM
To: Jonathan Underwood <jonathan.underwood(a)gmail.com>
On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
> 2008/7/27 Vasile Gaburici <vgaburici(a)gmail.com>:
>> So, Fedora would still have to ship TeX font files separately (for
>> some fonts) until the tool set and upstream OTF packaging matures. But
>> for mundane OTF fonts, which don't have optical sizes, I don't see
>> serious show stoppers for the proposal to (i) generate their .tfm TeX
>> metrics automatically, and (ii) convert them to type 1 on the user's
>> machine.
>
> Why do (ii) on the users machine instead of at package build time?
Nicolas had some concerns on the size of font packages we ship,
especially when duplication is involved. I agree that doing the work
on the user's machine is somewhat contrary to the idea of RPM... BTW,
generating the tfm takes far more time and space. An extreme example
is MinionPro (full commercial set, from Adobe):
- OTFs: 10Mb
- PFBs: 20Mb
- TFMs: 180Mb
A single type 1 pfb file can contain more than 256 glyphs, but these
are addressable only by AGL (Adobe Glyph List) name. Traditinoal TeX
encodings (T1, LY1) are limited to 256 glyphs per font, so in order to
access all glyphs (e.g. small caps, lining figures) multiple tfm files
are generated for the same pfb. This wouldn't be much of a problem if
the tfm files didn't ALSO have to contain the kerning info! Take the
class-based kerning info from the OTF and make it pairwise, then put
overlapping subsets in multiple encodings and the disk usage
explodes... Sadly TeX cannot use Adobe's afm file format which could
at least store all the kerning pairs without duplication.
Btw, Linux Libertine or DejaVu have more glyphs than MinionPro...
> These to jobs could be handled by a simple invocation of
>> autoinst (with some parameters, like telling it if the font is serif
>> or not). So, for most fonts the foo-font-tex package could be just
>> some emtpy dirs and a %post invocation of autoinst. This method needs
>> some testing with various fonts before we commit to it.
>>
>
> Again - why not use autoinst during package build time?
If Nicholas doesn't object, I surely don't. It would be a lot easier
to control what happens.
>> TrueType fonts can be used used without conversion by pdftex, but TeX
>> metrics still have to be generated. Other TeX drivers, like dvips and
>> dvipdfm, can use TrueType fonts only if they are converted to bitmaps;
>> I don't think this is worth the hassle since the output would suck on
>> screen.
>
> I agree they suck.. but, not doing so would be a problem for legacy
> users, I fear...
I doubt any legacy user uses »TrueType« fonts while generating
PostScript from TeX. Most legacy users that still rely on PostScript
output stick with Type 1 fonts, usually those that come with TeX
(Computer Modern, standard 35 PostScript fonts), because these can be
embedded as outlines in PostScript. Using TrueType fonts in TeX for
PostSript output is no different than using METAFONT fonts: PK bitmaps
have to be generated at the output resolution. Now, TeX doesn't ship
any bitmap PK fonts when METAFONT sources are available. TeX generates
(and caches) them as needed. Remember the old days when you had to
wait for "kpathsea: Running mktexpk --mfmode ..." I'm not aware of any
program that can do the magic for TrueType fonts, but I haven't used
TrueType fonts for PostScript output either. My point is that PK
bitmap generation is not something we want to do at packaging time!
-- Vasile
15 years, 4 months
FarsiWeb Font licensing
by Jon Stanley
Hello,
I'm interested in packaging the FarsiWeb fonts for Fedora, and I
noticed that the license of the fonts is GPL. Would you consider
adding the font exception as described here:
http://www.gnu.org/licenses/gpl-faq.html#FontException
Basically what this exception allows is for the font or portions of it
to be embedded, unmodified, in other documents (for example a PDF)
without causing that document to come under the scope of the GPL.
Thank you for your consideration in this matter.
-Jon
15 years, 4 months
Re: [Fontconfig] TTF/OTF packaging thoughts?
by Behdad Esfahbod
On Fri, 2008-07-25 at 14:06 +0900, mpsuzuki(a)hiroshima-u.ac.jp wrote:
>
> What is the advantage to pack TrueType and CFF OpenType?
> I guess, the shareable contents are limited as TTC-packed
> CFF OpenType, so, such request comes from the people looking
> for an easy archiver of font files.
Yes, I was just meaning having one file for a face.
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
15 years, 4 months
