fonts July 2008

fonts@lists.fedoraproject.org

20 participants
55 discussions

Re: contact kurditgroup
by Michal Nowak 13 Oct '08

13 Oct '08

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 > > > > > > 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. > > > > > > > > > http://www.fsf.org/licensing/licenses/gpl-faq.html#FontException > > > > > > Please reply to my email mnowak(a)redhat.com for further information or > > > point me to someone whom can I talk to. > > > > > > Thank you for you time, > > > Michal Nowak > > > > > > Michal Nowak   uid:0 > > > > > > 2008-07-15 > > > </div> > > >

3 5

Re: TeXGyre fonts licensing concern
by Nicolas Mailhot 08 Aug '08

08 Aug '08

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/comment… 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

4 10

457281: Review Request: unikurd-fonts - A widely used Kurdish font
by Michal Nowak 30 Jul '08

30 Jul '08

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

1 0

TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici 30 Jul '08

30 Jul '08

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-op… http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-and-… 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_othe… > >> > 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 > >

5 15

freetype 2.3.6+ has significant improvements in hinting
by Vasile Gaburici 30 Jul '08

30 Jul '08

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

2 1

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 29 Jul '08

29 Jul '08

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

1 1

Font Exception thoughts Was: Mukti fontset license
by Michal Nowak 28 Jul '08

28 Jul '08

----- "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net> wrote: > Michal, > > I think we're all very impressed by the writing of the messages you > sent > to various font projects. If you have the time, please contribute > some > of it to > http://fedoraproject.org/wiki/User:Pfrields/DraftUpstreamRequestEmail > > You seem quite capable of helping make it a terrific template. Good idea Nicolas, just contributed few thoughts and 'd appreciate review from the list. https://fedoraproject.org/w/index.php?title=User%3APfrields%2FDraftUpstream… -- Michal Nowak BaseOS QE (Apps/Toolchain sub-group) Engineer

1 0

FarsiWeb Font licensing
by Jon Stanley 27 Jul '08

27 Jul '08

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

1 0

[Fwd: FarsiWeb fonts]
by Nicolas Mailhot 27 Jul '08

27 Jul '08

-------- Forwarded Message -------- From: Behdad Esfahbod To: Nicolas Mailhot Subject: FarsiWeb fonts Date: Tue, 22 Jul 2008 12:55:18 -0400 Hey, Who should I bribe to get farsiweb-fonts packaged? http://www.farsiweb.ir/wiki/Persian_fonts Cheers,

2 1

Re: [Fontconfig] TTF/OTF packaging thoughts?
by Behdad Esfahbod 25 Jul '08

25 Jul '08

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts July 2008