fonts February 2009

fonts@lists.fedoraproject.org

20 participants
25 discussions

fontforge scripting change
by Kevin Fenzi 28 Feb '09

28 Feb '09

Greetings. I took a deeper look tonight as to why one of my fonts failed in the mass rebuild, and tracked it down. The last version of fontforge I built, I enabled the python extensions, thinking they were just an extra nice feature, and it was requested. However, this has one side effect: the default scripting lang changes to python. In order to use old "legacy" fontforge scripts, you have to pass fontforge '-lang=ff'. I don't know how many other fonts hit this issue, but I thought I would mention it here. We could revert the python bindings being enabled, but I think this is a nice feature our users would want, and with fontforge calling the old scripts "legacy", I think it's what people will expect moving forward. So, if you had a font build failure and you use a old style fontforge script, please pass '-lang=ff' and see if that fixes things. kevin

1 0

Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by Roozbeh Pournader 25 Feb '09

25 Feb '09

> Chinese, Korean and Japanese fonts are an old source of pain for font > packagers, due to: ... CJK information processing being very hard to do correctly. See Ken Lunde's amazing 900-page tome, "CJKV Information Processing", which recently appeared in its second edition: http://oreilly.com/catalog/9780596514471/ > 1. the way Unicode.org decided it would be a good idea to have them > share codepoints ("Han unification"), so CJK packagers compete with each > other to make their pet font the default I can't relate these two. By the same reasoning, Fraktur fonts would compete with modern Latin fonts, Urdu fonts would compete with Arabic fonts, and Hindi fonts would compete with Marathi fonts. Font packagers competing with each other in pushing their fonts is not acceptable either. If that doesn't stop, we should perhaps centralize our fontconfig configuration files to avoid such fontconfig wars. On a separate note, it wasn't unicode.org who decided to unify Han characters. It was a consensus effort, supported by various national standardization bodies, including those of China, Japan, and Korea. Please don't spread FUD ;-) You can read about the actual history of Han Unification here: http://unicode.org/versions/Unicode5.0.0/appE.pdf Roozbeh

8 10

Fwd: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by Qianqian Fang 23 Feb '09

23 Feb '09

sorry, forget to cc the list ---------- Forwarded message ---------- From: Qianqian Fang <fangqq(a)gmail.com> Date: Mon, Feb 23, 2009 at 11:40 PM Subject: Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) To: Jens Petersen <petersen(a)redhat.com> On Mon, Feb 23, 2009 at 8:04 PM, Jens Petersen <petersen(a)redhat.com> wrote: > ----- "AKanda" <welovebemani(a)gmail.com> wrote: > > The last update for VLgothics "vlgothic-fonts-20090204-2.fc10.noarch" > > is perhaps not good. (Install by yum.) > > Since this update, the "japanese-fonts" of my system (all my sytem : > > nautilus, openoffice, website ...) is not beautifull. > > > > http://forums.fedora-fr.org/viewtopic.php?id=39426 > > What is your locale (desktop language)? > > yes, I have the same question. The offending characters are the embedded bitmaps from Uming. > It looks like you are suffering from the Han unification issue Nicolas > mentioned. I am not sure. This used to happen when the local is non-CJK: the Japanese fonts has the highest priorities, and Uming/Ukai mixed to show the rest. > > Jens > > _______________________________________________ > Fedora-fonts-list mailing list > Fedora-fonts-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-fonts-list >

1 0

Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by Jens-Ulrik Petersen 23 Feb '09

23 Feb '09

----- "AKanda" <welovebemani(a)gmail.com> wrote: > The last update for VLgothics "vlgothic-fonts-20090204-2.fc10.noarch" > is perhaps not good. (Install by yum.) > Since this update, the "japanese-fonts" of my system (all my sytem : > nautilus, openoffice, website ...) is not beautifull. > > http://forums.fedora-fr.org/viewtopic.php?id=39426 What is your locale (desktop language)? Have you read: http://docs.fedoraproject.org/release-notes/f10/fr/What_is_the_Latest_on_th… (fr) http://docs.fedoraproject.org/release-notes/f10/en_US/What_is_the_Latest_on… (en) ? It looks like you are suffering from the Han unification issue Nicolas mentioned. Jens

1 0

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by AKanda 23 Feb '09

23 Feb '09

Hello, The last update for VLgothics "vlgothic-fonts-20090204-2.fc10.noarch" is perhaps not good. (Install by yum.) Since this update, the "japanese-fonts" of my system (all my sytem : nautilus, openoffice, website ...) is not beautifull. For see "thumbnail exemple" : http://forums.fedora-fr.org/viewtopic.php?id=39426 But, I can't solve this problem by myself. Best Regards, -- Ben

2 1

Fedora needs your help
by Nicolas Mailhot 22 Feb '09

22 Feb '09

Dear all, As some of you know Fedora 11 will feature automatic font installation¹. This is a genuinely new feature that does not try to ape what other operating systems do and play on Linux's traditional attention to localization and internationalization. It's a free/libre alternative to the DRM-ed distribution channels proprietary foundries are pushing right now². However, awesome new installation code is not sufficient. To work well this feature requires a large and sane font package pool to draw on. To provide this pool the Fonts SIG has worked hard to define clear and sane packaging guidelines last year³. The maintainers of affected packages were notified two months ago of needed changes⁴. However, while many reacted fast, others have still not started looking at it⁵. With only one month left before Fedora 11 beta it's time for others to step up and help adapt the remaining packages. Please take a look at the bugzilla tracker⁴, adopt an open bug, and propose spec file changes there. Extensive documentation was written⁶ for this operation and you do not need to be a font expert to participate. Also, changing such a large pool of packages is never mistake-free, and we also need testers to QA⁷ the changes. Please take a look at the bugzilla tracker⁴, adopt a closed bug, and check the corresponding package was converted properly. I'm afraid we are massively short-handed right now. Please help. _________ ¹ http://fedoraproject.org/wiki/Features/AutomaticFontInstallation ² http://en.wikipedia.org/wiki/Embedded_OpenType ³ Finally ratified in January 2009, but their expected content was public a long time before) https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00007… ⁴ https://bugzilla.redhat.com/show_bug.cgi?id=477044 ⁵ http://blog.stevecoinc.com/2009/02/help.html ⁶ http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29 http://fedoraproject.org/wiki/Packaging:FontsPolicy ⁷ http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts#How_To_T… http://fedoraproject.org/wiki/Improving_existing_font_packages -- Nicolas Mailhot

1 0

Re: Help with licensing questions
by Stephen Hartke 16 Feb '09

16 Feb '09

[This message is supposed to continue the thread about licensing questions, but I just subscribed to the mailing list, so I can't reply directly to those messages.] * From*: Nicolas Mailhot <nicolas mailhot laposte net>* Subject*: Re: Help with licensing questions* Date*: Tue, 10 Feb 2009 22:39:47 +0100 > 12. The author thinking the metatype sources would require him to use > some other license than the OFL because they look more software-ish is > just confusing things (pretty common occurrence unfortunately). GPL-ing > the build scripts would probably be more interesting, but a. they're > lost and b. this would not change the font licensing at all. I'm confused by this comment. My font Aurulent Sans is created by MetaType1 programs that look like this: %% \-------------------------------------------------------------------- %% The letter n %% % %% \PICT{n} %% \-------------------------------------------------------------------- beginfontglyph("n",ASCII("n"),.83lowwidth,lowsp_vert,lowsp_vert,xht,lowdepth); x0=x1=leftstemloc; y0=xht; y1=0; x2=x0; y2=.4[xht,y1]; x4=x41=x5=rightstemloc; y4=.3[xht,y1]; y5=0; x3=.76[rt x1,lft x4]; % we choose the point to make "hump" farther to the right so the divot is big. % However, we have to be careful about bold fonts, so that x3 doesn't go farther right than the left edge of x4. top y3=top y31=xht+low_overshoot; x31=.6[x3,x4]; y41=.75[y4,y3]; % works because the point put in is 1.75 expand_font_stroke.leftstem (butt_end(0,1)) (z0--z1); pen_stroke_method:=1; expand_font_stroke.rightstem (cut(fix_nib(join_px,join_py,prot),170)(0); cut(extreme_angle(x4,px,x3,py,x2,.5))(1); butt_end(last)) (z2{curl .3}..z3{right}..controls z31 and z41..z4{down}--z5); pen_stroke_method:=0; path P; P:=rightstem; P:=smooth_straight_to_curve(P,5); P:=smooth_curve_to_straight(P,2); Fill smooth_curve(P); Fill leftstem; I think this is a program and very different than the MetaType1 sources for Latin Modern and similar fonts that contain mainly just tables of data points. In that sense, the GPL for the MetaType1 sources seems very reasonable to me. Why do you think that it is inappropriate? > 10. Lastly, font sources in metatype format can be non-trivial to build, > and seem to require specific build scripts tuned to the TEX variant the > distro ships. Building any font from metatype would probably require > help from TEX specialists such as Jonathan Underwood. > > 11. In your case the author has lost those scripts, and does not intend > to work from metatype anymore (preferring direct fontforge editing), so > it's probably no great loss to forget the original metatype source. Just > get him to publish an authoritative sfd version of his font, and use it > as your source. I have not lost the source for the MetaType1 programs, but rather for the build scripts. As you point out, it's tricky to build MetaType1 files, and I had created files that were particularly tuned to work with teTeX. I don't really feel that it is advantageous to recreate these files. I would much prefer to work on rewriting the MetaType1 programs using FontForge's Python scripting. Best wishes, Stephen

4 8

another font packaged, awaiting reviews.
by Stephen Carter 13 Feb '09

13 Feb '09

My 2nd font has been packaged and the package review request can be found here, along with links to the .spec file and the package itself: https://bugzilla.redhat.com/show_bug.cgi?id=485542 . Hooray! :) Now I just need it reviewed... This font is called "breip", and it's a handwriting font that was made by Alan Hussey. You can check it out and see what it looks like on it's homepage: http://stalefries.googlepages.com/fontsbreip . I'm not normally a big fan of handwriting fonts, but this one caught my eye, and I actually kinda like it. Stephen Carter

1 0

Font previewer requirements
by Nicolas Mailhot 10 Feb '09

10 Feb '09

Hi, As several people asked recently both privately and publicly to add font previews to different static medias (release notes, wiki pages, packagekit info), and proposed various solutions that didn't cut it, here are my requirements for a font preview generator. If such a utility was available adding font previews to all the places people asked of would probably not be too difficult. Note that those requirements are different from the ones you want in a dynamic context (such as a font preview application or a dynamic web site) A good static previewer: 1. would take a list of ttf/otf/ttc/pfa/pfc/pcf files as argument 2. would generate one small (size) standalone file from them 3. without needing any further input (even if an option to force a specific preview text wouldn't hurt) 3. would give a good idea of the unicode coverage of the font files, probably using pangrams for the most interesting unicode/script blocks included in them. Wikipedia has a pangram list: http://en.wikipedia.org/wiki/List_of_pangrams and fontconfig in fedora-devel has a command to detect the script coverage of a font: $ fc-query --format ':lang= %{lang}\n' /usr/share/fonts/gfs-theokritos/GFSTheokritos.otf :lang=eu|fj|gv|ho|ia|id|ie|io|nds|nr|om|so|ss|st|sw|ts|vo|xh|zu so it's just a matter of hooking one with the other (of course finding the right heuristic is going to be tricky, and pangrams do not work for CJK, and listing the full glyph list of a font is out of the question) 4. would generate vector shapes (probably svgz) so the preview does not degrade on high pixel density displays. 5. would work with complex scripts such as indic, which requires using a shaper such as pango 6. would not embed the font files themselves, or be a conversion of the fonts to some other format, as this would result in hairy licensing problems 7. would be reasonably fast and not have insanely big or exotic sofwtare dependencies If someone is interested in working on this it can probably be a fun little project. If successful it would be used all over the place by all the entities interested in free/open fonts (font authors, distributions, oflb, etc) Best regards, -- Nicolas Mailhot

2 1

Help with licensing questions
by Paul Lange 10 Feb '09

10 Feb '09

Hey, I'm currently packaging up Aurulent Sans. (http://fedoraproject.org/wiki/Hartke_Aurulent_fonts ) At the moment there are only some compiled *.otf files available. Because of this I asked the author for sources to compile from. But the answer is going a bit over my current horizon. The answer I got an the question if it would be possible to provide some sources is: This is a tricky issue, for a couple of reasons: First, the font is created with MetaType1. This is not particularly easy to install or setup. Will you be able to do that? Since my hard drive crashed over the summer, I lost some of the changes that I had made to MetaType1 so that it would run in Fedora (mainly shell scripts and the like). At the moment, I cannot compile the sources. Second, I have ceased work on the MetaType1 version of Aurulent Sans. I am re-creating the font using Python scripting in FontForge, and I think this is a more promising approach. However, I don't have much time to spend on it, so this is definitely a long term project. Third, it's not clear what license the source files should be released under. Since they are code, it seems that the GPL would be appropriate, not the OFL. However, it's not clear what the effect of using the GPL would be; certainly I'd want people to be able to directly modify and redistribute the "binary" font file. So I don't have some experience with font building and need some hints here. Also I don't have a clear answer on the licensing question. Regards, Paul

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts February 2009