From roozbeh at gmail.com Sun Feb 1 07:42:03 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sat, 31 Jan 2009 23:42:03 -0800 Subject: Lost in translation, part II: Lost in orthographies Message-ID: I was trying to avoid fontconfig, but it caught me at the end. Trying to figure out which languages in comps are supported by which font, to be able to include them in the language group, I compared the list of languages in F11's comps file with the orthography lists fontconfig supports. To my surprise, some were missing/problematic. The list is here: http://fedoraproject.org/wiki/I18N/LanguageSupportCriteria/Missing_fontconfig I also found quite a few problems with existing orth files in fontconfig that I'm working on fixing: http://tinyurl.com/dbk6a8 Since fontconfig support is critical for any language Fedora claims to support [1], I think we should remove the language groups from comps file if we don't have a fontconfig orthography file for it. I went and updated the language criteria page we have here, adding a fontconfig step: https://fedoraproject.org/wiki/I18N/LanguageSupportCriteria For the specific language cases, I went and filed upstream bugs against fontconfig for all I could find, except for Berber, which is a bit problematic by nature (language code used is actually for a family of languages, glibc locales are incomplete, Latin/Tifinagh/Arabic script division is not along country lines...). This is a report. I would appreciate help and feedback, especially your thoughts about fontconfig .orth requirements for claiming language support in Fedora. Roozbeh [1]: Ask fc-list which fonts support Kinyarwanda (rw) by running "fc-list :lang=rw": it gives you nothing, while in real life, almost every font on your machine supports it. From nicolas.mailhot at laposte.net Sun Feb 1 10:40:46 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 11:40:46 +0100 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: References: Message-ID: <1233484846.6961.24.camel@arekh.okg> Le samedi 31 janvier 2009 ? 23:42 -0800, Roozbeh Pournader a ?crit : > I was trying to avoid fontconfig, but it caught me at the end. Trying > to figure out which languages in comps are supported by which font, to > be able to include them in the language group, I compared the list of > languages in F11's comps file with the orthography lists fontconfig > supports. > > To my surprise, some were missing/problematic. The list is here: > > http://fedoraproject.org/wiki/I18N/LanguageSupportCriteria/Missing_fontconfig I'd be very careful to redefine tagalog for example. The tagalog script is definitely not latin and has a specific unicode block, iso 15924 script tag, and specific supporting fonts http://www.unicode.org/iso15924/iso15924-codes.html http://fedoraproject.org/wiki/Pmorrow_Tagalog_Doctrina_1593_fonts IMHO we've been conflating too many different notions (country, region, language, script) in a few short locale tags and what you see is just the system breaking appart for non-mainstream languages/scripts. > I also found quite a few problems with existing orth files in > fontconfig that I'm working on fixing: http://tinyurl.com/dbk6a8 This is something for Behdad. I hear he's cutting a new fontconfig version right now, you may want to catch him before he's done and the projects wents back to its usual 6-8 months sleepiness ;). > Since fontconfig support is critical for any language Fedora claims to > support [1], I think we should remove the language groups from comps > file if we don't have a fontconfig orthography file for it. That's not really helpful, all the different parts of language support are done by different groups with different agendas and different time scales so of course initial support is going to be incomplete. Expecting one contributor to provide all the parts in one go is illusory. What you want is to help the different contributors to a language group to: ? identify other bits are missing ? ping in the right place so they get added Otherwise everyone will just wait for everyone else. Some people will claim that ? full ? language support means a system dictionnary and thesaurus BTW, completeness is a slipery slope. > I went and > updated the language criteria page we have here, adding a fontconfig > step: > > https://fedoraproject.org/wiki/I18N/LanguageSupportCriteria > > For the specific language cases, I went and filed upstream bugs > against fontconfig for all I could find, except for Berber, which is a > bit problematic by nature (language code used is actually for a family > of languages, glibc locales are incomplete, Latin/Tifinagh/Arabic > script division is not along country lines...). This again is because iso-639 is not well suited to identify scripts. > This is a report. I would appreciate help and feedback, especially > your thoughts about fontconfig .orth requirements for claiming > language support in Fedora. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roozbeh at gmail.com Sun Feb 1 13:34:12 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sun, 1 Feb 2009 05:34:12 -0800 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: <1233484846.6961.24.camel@arekh.okg> References: <1233484846.6961.24.camel@arekh.okg> Message-ID: On Sun, Feb 1, 2009 at 2:40 AM, Nicolas Mailhot wrote: > I'd be very careful to redefine tagalog for example. The tagalog script > is definitely not latin and has a specific unicode block, iso 15924 > script tag, and specific supporting fonts > > http://www.unicode.org/iso15924/iso15924-codes.html > http://fedoraproject.org/wiki/Pmorrow_Tagalog_Doctrina_1593_fonts No worries. I know all that. According to the Unicode Standard, that script has not been much used for Tagalog since mid-1700s. The Tagalog script in Unicode is an archaic script only, mostly for scholarly use: http://bugs.freedesktop.org/show_bug.cgi?id=19846 > IMHO we've been conflating too many different notions (country, region, > language, script) in a few short locale tags and what you see is just > the system breaking appart for non-mainstream languages/scripts. That's very true. I've been talking with Behdad to try to do a bit or redesigning, and we had a few ideas, like this bug, trying to get BCP 47 into fontconfig and somehow solving the glibc locale naming problem: http://bugs.freedesktop.org/show_bug.cgi?id=19869 I would appreciate your feedback. (Of course, we can't fix this in this release.) > This is something for Behdad. I hear he's cutting a new fontconfig > version right now, you may want to catch him before he's done and the > projects wents back to its usual 6-8 months sleepiness ;). I'm working with him. Actually he insisted that I rush it :) > all the different parts of language support > are done by different groups with different agendas and different time > scales so of course initial support is going to be incomplete. Expecting > one contributor to provide all the parts in one go is illusory. > > What you want is to help the different contributors to a language group > to: > ? identify other bits are missing > ? ping in the right place so they get added > > Otherwise everyone will just wait for everyone else. I'm sorry Nicolas, but I don't understand. Would you consider rewording? Are you saying that I should not have been trying to create the missing orth files myself? Or fix the buggy ones? > Some people will claim that ? full ? language support means a system > dictionnary and thesaurus BTW, completeness is a slipery slope. I agree. But we are talking about very basic language support here. If we cannot bring up and show a language in a proper font, we cannot claim to support it. Our layout system would not know what which font to use, so it will be just DejaVu first, instead of a font that actually supports the full glyph set for a language. Since we're also doing the automatic language detection in RPM thing, wouldn't that be based on orth files too? How can we claim we support a language in Fedora if none of our font rpms would report that they support it? Also, the orth files are very simple, much easier to create than glibc locale files for example. Thanks a lot for all your time, :) Roozbeh From nicolas.mailhot at laposte.net Sun Feb 1 13:46:26 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 14:46:26 +0100 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: References: <1233484846.6961.24.camel@arekh.okg> Message-ID: <1233495986.13582.22.camel@arekh.okg> Le dimanche 01 f?vrier 2009 ? 05:34 -0800, Roozbeh Pournader a ?crit : > On Sun, Feb 1, 2009 at 2:40 AM, Nicolas Mailhot > > What you want is to help the different contributors to a language group > > to: > > ? identify other bits are missing > > ? ping in the right place so they get added > > > > Otherwise everyone will just wait for everyone else. > > I'm sorry Nicolas, but I don't understand. Would you consider > rewording? Are you saying that I should not have been trying to create > the missing orth files myself? Or fix the buggy ones? No, I'm saying completeness should not be a requirement to create a new language group, but the aim should be to help people identify the missing bits so they can ping someone else (like you:;)) to provide them. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roozbeh at gmail.com Sun Feb 1 13:50:15 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sun, 1 Feb 2009 05:50:15 -0800 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: <1233495986.13582.22.camel@arekh.okg> References: <1233484846.6961.24.camel@arekh.okg> <1233495986.13582.22.camel@arekh.okg> Message-ID: On Sun, Feb 1, 2009 at 5:46 AM, Nicolas Mailhot wrote: > No, I'm saying completeness should not be a requirement to create a new > language group, but the aim should be to help people identify the > missing bits so they can ping someone else (like you:;)) to provide > them. Got it. I guess this really means I should try to document the process, like the great documentation I'm seeing at the fonts sig! (not that i can reach the quality ;)) Roozbeh From sanjay.ankur at gmail.com Sun Feb 1 13:50:29 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sun, 01 Feb 2009 19:20:29 +0530 Subject: koji build results In-Reply-To: <1233494745.13582.3.camel@arekh.okg> References: <4981F5D5.3090807@gmx.de> <1233256031.19140.47.camel@arekh.okg> <1233328160.3333.16.camel@localhost.localdomain> <1233338658.24109.4.camel@arekh.okg> <1233358083.10281.7.camel@localhost.localdomain> <1233391416.11691.8.camel@arekh.okg> <1233416066.3264.19.camel@localhost.localdomain> <1233419762.26894.4.camel@arekh.okg> <1233422080.3264.37.camel@localhost.localdomain> <1233423610.27900.1.camel@arekh.okg> <1233480012.3720.11.camel@localhost.localdomain> <1233483581.6961.8.camel@arekh.okg> <1233493591.3720.14.camel@localhost.localdomain> <1233494745.13582.3.camel@arekh.okg> Message-ID: <1233496229.3720.18.camel@localhost.localdomain> On Sun, 2009-02-01 at 14:25 +0100, Nicolas Mailhot wrote: > Le dimanche 01 f?vrier 2009 ? 18:36 +0530, Ankur Sinha a ?crit : > > hi, > > > > I built packages on koji for the fonts.. > > > > only this one failed : > > > > http://koji.fedoraproject.org/koji/getfile?taskID=1097228name=build.log > > > > Says cannot find file. > > No, it says it can't read the file, which probably just means that the > fontforge version in F-9 is too old to build old standard. > > ?OldStandard-Bold.sfd is not in a known format (or is so badly corrupted > as to be unreadable)? > > Not a huge problem, F-9 is an old release, its users will just have to > upgrade to F-10 to get your font. It's not worth getting worried about. > > PS do not hesitate to post to the list like others, you'll get more and > better advice this way > hi, Shouldnt cf-bonveno-fonts have also come across this error while building the f-9 package? That one built perfectly. Just a query. regards, Ankur From nicolas.mailhot at laposte.net Sun Feb 1 14:03:37 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 15:03:37 +0100 Subject: koji build results In-Reply-To: <1233496229.3720.18.camel@localhost.localdomain> References: <4981F5D5.3090807@gmx.de> <1233256031.19140.47.camel@arekh.okg> <1233328160.3333.16.camel@localhost.localdomain> <1233338658.24109.4.camel@arekh.okg> <1233358083.10281.7.camel@localhost.localdomain> <1233391416.11691.8.camel@arekh.okg> <1233416066.3264.19.camel@localhost.localdomain> <1233419762.26894.4.camel@arekh.okg> <1233422080.3264.37.camel@localhost.localdomain> <1233423610.27900.1.camel@arekh.okg> <1233480012.3720.11.camel@localhost.localdomain> <1233483581.6961.8.camel@arekh.okg> <1233493591.3720.14.camel@localhost.localdomain> <1233494745.13582.3.camel@arekh.okg> <1233496229.3720.18.camel@localhost.localdomain> Message-ID: <1233497017.13582.25.camel@arekh.okg> Le dimanche 01 f?vrier 2009 ? 19:20 +0530, Ankur Sinha a ?crit : > Shouldnt cf-bonveno-fonts have also come across this error while > building the f-9 package? That one built perfectly. Just a query. Bonveno sfds probably have not been created at the same time, and do not use whatever new fontforge feature F-9 fontforge does not understand. sfd is an evolving format that changes slightly every other fontforge release. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sanjay.ankur at gmail.com Sun Feb 1 14:05:24 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sun, 01 Feb 2009 19:35:24 +0530 Subject: koji build results In-Reply-To: <1233497017.13582.25.camel@arekh.okg> References: <4981F5D5.3090807@gmx.de> <1233256031.19140.47.camel@arekh.okg> <1233328160.3333.16.camel@localhost.localdomain> <1233338658.24109.4.camel@arekh.okg> <1233358083.10281.7.camel@localhost.localdomain> <1233391416.11691.8.camel@arekh.okg> <1233416066.3264.19.camel@localhost.localdomain> <1233419762.26894.4.camel@arekh.okg> <1233422080.3264.37.camel@localhost.localdomain> <1233423610.27900.1.camel@arekh.okg> <1233480012.3720.11.camel@localhost.localdomain> <1233483581.6961.8.camel@arekh.okg> <1233493591.3720.14.camel@localhost.localdomain> <1233494745.13582.3.camel@arekh.okg> <1233496229.3720.18.camel@localhost.localdomain> <1233497017.13582.25.camel@arekh.okg> Message-ID: <1233497124.3720.19.camel@localhost.localdomain> On Sun, 2009-02-01 at 15:03 +0100, Nicolas Mailhot wrote: > Le dimanche 01 f?vrier 2009 ? 19:20 +0530, Ankur Sinha a ?crit : > > > Shouldnt cf-bonveno-fonts have also come across this error while > > building the f-9 package? That one built perfectly. Just a query. > > Bonveno sfds probably have not been created at the same time, and do not > use whatever new fontforge feature F-9 fontforge does not understand. > > sfd is an evolving format that changes slightly every other fontforge > release. > okay, Then ill just ignore the failure. regards, Ankur From nicolas.mailhot at laposte.net Sun Feb 1 21:04:20 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 22:04:20 +0100 Subject: Thank you all for the packaging! Message-ID: <1233522260.18299.9.camel@arekh.okg> Dear list, Karsten Wade just published this very nice article on his blog: http://iquaid.org/2009/02/01/font-rock/ This is a tribute to the group efforts, and all the work you've contributed to make fonts in Fedora shine. I know that for many of you it was/is your first package, and how intimidating it is to start when you have little distribution experience. We've gone a long way from the negative packaging count of Fedora 7. http://fedoraproject.org/wiki/Fonts_inclusion_history Thank you all, I'm certain Fedora 11 users will notice the difference! -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From palango at gmx.de Sun Feb 1 22:47:04 2009 From: palango at gmx.de (Paul Lange) Date: Sun, 01 Feb 2009 19:47:04 -0300 Subject: Finish Font Birth Message-ID: <1233528424.3223.16.camel@localhost.localdomain> Hey, herewith I'm announcing the birth of two new fonts - vollkorn-fonts and yanone-tagesschrift-fonts - in the fedora universe. I want to thank anyone who helped me to do this (yes, I'm a bit proud of myself :p) As usual I have some more questions: - Comps integration: I'm going to register them only in 'fonts' as 'optional' (not in any xxx-support group because they only provide basic latin glyphs). When I updated the xml-file I simply upload the changes via CVS and that it? No need to tell special people about it or file bugs? - In case that I want to push updates: Can I use the common/cvs-import script again? (This would be great because it makes things easy for me) regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From petersen at redhat.com Mon Feb 2 03:35:24 2009 From: petersen at redhat.com (Jens Petersen) Date: Sun, 1 Feb 2009 22:35:24 -0500 (EST) Subject: Finish Font Birth In-Reply-To: <1233528424.3223.16.camel@localhost.localdomain> Message-ID: <1913901144.2054381233545724226.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > herewith I'm announcing the birth of two new fonts - vollkorn-fonts > and > yanone-tagesschrift-fonts - in the fedora universe. Thank you > - Comps integration: I'm going to register them only in 'fonts' as > 'optional' (not in any xxx-support group because they only provide > basic > latin glyphs). When I updated the xml-file I simply upload the > changes via CVS and that it? Yes that is fine: it is called "cvs commit". > - In case that I want to push updates: Can I use the > common/cvs-import script again? Yes, that should work - if not please file a bug. Jens From oget.fedora at gmail.com Mon Feb 2 03:48:50 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sun, 1 Feb 2009 22:48:50 -0500 Subject: Finish Font Birth In-Reply-To: <1913901144.2054381233545724226.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1233528424.3223.16.camel@localhost.localdomain> <1913901144.2054381233545724226.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: On Sun, Feb 1, 2009 at 10:35 PM, Jens Petersen wrote: >> - In case that I want to push updates: Can I use the >> common/cvs-import script again? > > Yes, that should work - if not please file a bug. Well, I did that once and weird things happened. I had to learn cvs to clean the mess. It was good though. In the end, I learned something useful. However I would suggest using the procedure given in the guidelines: http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Paul, I think you need to spend a little more time in the wiki. Most of the questions you ask have direct answers there. Feel free to ask questions about parts that you don't understand. Orcan From nicolas.mailhot at laposte.net Mon Feb 2 09:03:05 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Feb 2009 10:03:05 +0100 (CET) Subject: Finish Font Birth In-Reply-To: <1913901144.2054381233545724226.JavaMail.root@zmail02.collab.prod.int. phx2.redhat.com> References: <1913901144.2054381233545724226.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: Le Lun 2 f?vrier 2009 04:35, Jens Petersen a ?crit : >> - In case that I want to push updates: Can I use the >> common/cvs-import script again? > > Yes, that should work - if not please file a bug. However please avoid pushing updates to stable releases unless you have to (initial import is fine, updating anything else than rawhide every time a comma changes is not) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Feb 3 22:50:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 23:50:16 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted Message-ID: <1233701416.26332.26.camel@arekh.okg> Dear all, Yesterday I took the time to find the current address of a well-known Georgian font creator, Besarion Paata Gugushvili. Our current Georgian support is rather limited: one set of glyphs in Dejavu, and nothing else (This set was created by the very same author BTW). Imagine using the same font all day long everywhere :( Some of his other fonts had long found their way in other major distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora was largely ignoring this problem-space, but there was no public licensing statement of his part on any of his web sites. Which meant we could not just lift the files from the internet, and package them to reach Georgian support parity with others. So took the time to write the author a long nice mail asking to confirm the licensing. I didn't expect much, this kind of request usually takes ages to be answered, and the answer is usually not the one we'd like (when we don't hit language barriers). Anyway this time the reply was awesome: 1. less than 9 hours later (most of them night I'm sure) 2. a *new* font pack release (not the old files everyone else ships) 3. with *new* fonts (not just updates of the fonts everyone else ships) 4. with a clear licensing statement on the author web site (not a third-party site like before) 5. and adding the FSF font exception to the GPL statement (people who tried know how hard it is to get this one usually, many font authors just don't understand the need) So, Fedora would seriously suck if we took ages to package those fonts now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy right now, and can't possibly work on it short term. Therefore, I'm doing a public call on Fedora lists, for someone to package those, and prove Besarion Paata Gugushvili was right to trust Fedora. All the relevant technical information is here: http://fedoraproject.org/wiki/BPG_fonts Let's rock! Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Wed Feb 4 00:49:35 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Feb 2009 19:49:35 -0500 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <1233701416.26332.26.camel@arekh.okg> References: <1233701416.26332.26.camel@arekh.okg> Message-ID: <4988E61F.8070909@redhat.com> On 2009-02-03 at 17:50:16 -0500, Nicolas Mailhot wrote: > Therefore, I'm doing a public call on Fedora lists, for someone to > package those, and prove Besarion Paata Gugushvili was right to trust > Fedora. Packaged. Awaiting review: https://bugzilla.redhat.com/show_bug.cgi?id=483865 ~spot From sanjay.ankur at gmail.com Wed Feb 4 10:19:16 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Wed, 04 Feb 2009 15:49:16 +0530 Subject: [Fonts-list] Help with multi spec Message-ID: <1233742756.6311.15.camel@localhost.localdomain> hi, I have some queries with the font multi spec. I have referred the specs in rawhide for mgopen, dejavu and vera fonts and have based my spec on them. I get this error on attempting to build the package:: "error: line 51: Package does not exist: %post sfd-general-fonts" >From what i understood from the rawhide specs, the Why am i getting this? Ive based the %_font_pkg line as per the other specs. Where can i find documentation on these new macros? Also, do i need to make different conf files for these three families? They do not differ in generic name. (I have currently excluded mentioning of the conf files). regards, Ankur From nicolas.mailhot at laposte.net Wed Feb 4 10:36:02 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 4 Feb 2009 11:36:02 +0100 (CET) Subject: [Fonts-list] Help with multi spec In-Reply-To: <1233742756.6311.15.camel@localhost.localdomain> References: <1233742756.6311.15.camel@localhost.localdomain> Message-ID: <8f7c9ac1983e558d791c60b082731601.squirrel@arekh.dyndns.org> Le Mer 4 f?vrier 2009 11:19, Ankur Sinha a ?crit : > > hi, > > I have some queries with the font multi spec. > > I have referred the specs in rawhide for mgopen, dejavu and vera fonts > and have based my spec on them. > > I get this error on attempting to build the package:: > > "error: line 51: Package does not exist: %post sfd-general-fonts" > >>From what i understood from the rawhide specs, the > > Why am i getting this? Ive based the %_font_pkg line as per the other > specs. In every other case we've seen this the packager had made small cut and paste mistakes. Just re-read attentively your spec file and make sure you follow strictly the template pass the right names in the %package, %description and %_font_pkg lines > Where can i find documentation on these new macros? > > Also, do i need to make different conf files for these three families? > They do not differ in generic name. (I have currently excluded > mentioning of the conf files). Fontconfig will only process the names you give it. It's software, not a human so it won't fill in the blanks by itself. You do need to write fontconfig rules for every single font family name your font files declare (note: font *family* names, not style/face names) -- Nicolas Mailhot From evets25 at gmail.com Wed Feb 4 15:50:04 2009 From: evets25 at gmail.com (Stephen Carter) Date: Wed, 04 Feb 2009 10:50:04 -0500 Subject: New font package, needs a review/sponsor Message-ID: <4989B92C.4090006@gmail.com> Greetings, As I mentioned earlier, I'm a new packager. I just submitted my first package review request, which can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=484057 The font is called Epigrafica, and hopefully it is the first of many such font packages. :D I need people to review/sponser the package, so if someone could take a look, that would be great. Also, this is for a school project as well, and I'm kinda behind schedule, so the faster we can get the review process moving along, the better. Comments and criticism are most welcome! Stephen Carter From cchance at redhat.com Thu Feb 5 00:27:01 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Thu, 05 Feb 2009 10:27:01 +1000 Subject: [Fonts-list] Help with multi spec In-Reply-To: <8f7c9ac1983e558d791c60b082731601.squirrel@arekh.dyndns.org> References: <1233742756.6311.15.camel@localhost.localdomain> <8f7c9ac1983e558d791c60b082731601.squirrel@arekh.dyndns.org> Message-ID: <498A3255.9040007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Le Mer 4 f?vrier 2009 11:19, Ankur Sinha a ?crit : >> "error: line 51: Package does not exist: %post sfd-general-fonts" %post -n sfd-general-fonts and that sfd-general-fonts should be based on %package -n sfd-general-fonts - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmKMlQACgkQmo+B7bGj5dLdWwCgknKHrscMZE4UqxEtJad6Kw9V UFoAn2u7f/7aB/vUYf4D1rVxPJVbdVQz =4cgx -----END PGP SIGNATURE----- From giomac at gmail.com Thu Feb 5 07:20:01 2009 From: giomac at gmail.com (George Machitidze) Date: Thu, 5 Feb 2009 11:20:01 +0400 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> References: <1233701416.26332.26.camel@arekh.okg> <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> Message-ID: <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> FYI wasn't subscribed to all needed lists... On Thu, Feb 5, 2009 at 11:02 AM, George Machitidze wrote: > Hi Nicolas! > Thank you for initiating this issue - I didn't expect to see this message > here :) > I will talk with him directly and package files - I'm very experienced with > rpmbuild and spec-s. > Actually, I planned to release it, but I was little busy... > btw, one of our friends just few hours ago finished first georgian psfu > console font too, now we are testing it... > 2009/2/4 Nicolas Mailhot > >> Dear all, >> >> Yesterday I took the time to find the current address of a well-known >> Georgian font creator, Besarion Paata Gugushvili. Our current Georgian >> support is rather limited: one set of glyphs in Dejavu, and nothing else >> (This set was created by the very same author BTW). Imagine using the >> same font all day long everywhere :( >> >> Some of his other fonts had long found their way in other major >> distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora >> was largely ignoring this problem-space, but there was no public >> licensing statement of his part on any of his web sites. Which meant we >> could not just lift the files from the internet, and package them to >> reach Georgian support parity with others. >> >> So took the time to write the author a long nice mail asking to confirm >> the licensing. I didn't expect much, this kind of request usually takes >> ages to be answered, and the answer is usually not the one we'd like >> (when we don't hit language barriers). >> >> Anyway this time the reply was awesome: >> 1. less than 9 hours later (most of them night I'm sure) >> 2. a *new* font pack release (not the old files everyone else ships) >> 3. with *new* fonts (not just updates of the fonts everyone else ships) >> 4. with a clear licensing statement on the author web site (not a >> third-party site like before) >> 5. and adding the FSF font exception to the GPL statement (people who >> tried know how hard it is to get this one usually, many font authors >> just don't understand the need) >> >> So, Fedora would seriously suck if we took ages to package those fonts >> now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy >> right now, and can't possibly work on it short term. >> >> Therefore, I'm doing a public call on Fedora lists, for someone to >> package those, and prove Besarion Paata Gugushvili was right to trust >> Fedora. >> >> All the relevant technical information is here: >> http://fedoraproject.org/wiki/BPG_fonts >> >> Let's rock! >> >> Best regards, >> >> -- >> Nicolas Mailhot >> >> -- >> Fedora-i18n-list mailing list >> Fedora-i18n-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-i18n-list >> > > > > -- > BR, > George Machitidze > > -- BR, George Machitidze -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Thu Feb 5 07:31:51 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Feb 2009 08:31:51 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> References: <1233701416.26332.26.camel@arekh.okg> <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> Message-ID: <1233819111.3865.19.camel@arekh.okg> Le jeudi 05 f?vrier 2009 ? 11:20 +0400, George Machitidze a ?crit : > On Thu, Feb 5, 2009 at 11:02 AM, George Machitidze > wrote: > Hi Nicolas! Hi George, > Thank you for initiating this issue - I didn't expect to see > this message here :) > I will talk with him directly and package files - I'm very > experienced with rpmbuild and spec-s. Tom has started packaging those fonts here: https://bugzilla.redhat.com/show_bug.cgi?id=483865 However I'm sure a native speaker that can propose great package summaries (upstream pages are 100% Georgian), and help bridge the communication gap with upstream (there are still a few legal nits to take care of apparently) would be very appreciated as co-maintainer. > Actually, I planned to release it, but I was little busy... > btw, one of our friends just few hours ago finished first > georgian psfu console font too, now we are testing it... I don't deal with console fonts, but I'm sure that if it was packaged it would be appreciated by Georgian Fedora users too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From palango at gmx.de Thu Feb 5 17:24:52 2009 From: palango at gmx.de (Paul Lange) Date: Thu, 05 Feb 2009 14:24:52 -0300 Subject: fontconfig questions Message-ID: <1233854692.8170.18.camel@localhost.localdomain> Hey, I'm currently packaging Aurulent Sans: http://fedoraproject.org/wiki/Hartke_Aurulent_fonts Everywhere is written, that it's a font who can be used as the primary interface fonts. However at the moment (since 2007) there're only latin glyphs with some more accents supported. Because of this I'm not sure how to handle the fontconfig files. At the moment I'm really conservative. You can view my fontconfig files here: http://palango.fedorapeople.org/aurulent/ I currently only mark them only as sans-serif/monospace because I think they are not yet ready for a primary interface font. I set the fontconfig-prefix of the sans-serif one to 61 (only latin) and of the monospace to 64 (only latin, only regular). Any comments on this? regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nicolas.mailhot at laposte.net Thu Feb 5 23:05:18 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 06 Feb 2009 00:05:18 +0100 Subject: fontconfig questions In-Reply-To: <1233854692.8170.18.camel@localhost.localdomain> References: <1233854692.8170.18.camel@localhost.localdomain> Message-ID: <1233875118.22086.9.camel@arekh.okg> Le jeudi 05 f?vrier 2009 ? 14:24 -0300, Paul Lange a ?crit : > Hey, > > I'm currently packaging Aurulent Sans: > http://fedoraproject.org/wiki/Hartke_Aurulent_fonts > > Everywhere is written, that it's a font who can be used as the primary > interface fonts. That's the author design aim, and that gives a good idea of the kind of design compromises he took, but that does not mean he succeeded :p > However at the moment (since 2007) there're only latin > glyphs with some more accents supported. Because of this I'm not sure > how to handle the fontconfig files. At the moment I'm really > conservative. Conservative is good. Whenever you feel a font is not good enough, or has too little coverage, or has not enough faces, you should put it at a high number in its priority range (for latin fonts typically 63-64) > You can view my fontconfig files here: > http://palango.fedorapeople.org/aurulent/ > > I currently only mark them only as sans-serif/monospace because I think > they are not yet ready for a primary interface font. I'm not sure that: "the width and style is reminiscent of Luxi Sans, Lucida Sans, Tahoma, and Andale Sans UI" is sufficient to mark the font as a valid substitute for those fonts. So far we've only marked this way fonts that were clearly derivatives of other fonts, or that claimed same (not reminiscent) metrics. Though at 64 it probably does not matter much, and it'll be interesting to see how users react. > I set the fontconfig-prefix of the sans-serif one to 61 (only latin) and > of the monospace to 64 (only latin, only regular). Any comments on this? You can probably be more conservative with sans-serif -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From evets25 at gmail.com Fri Feb 6 14:35:59 2009 From: evets25 at gmail.com (Stephen Carter) Date: Fri, 06 Feb 2009 09:35:59 -0500 Subject: New fonts not on wishlist? Message-ID: <498C4ACF.7020604@gmail.com> Greetings, I just had a quick question: If I happen to stumble across a new font that isn't packaged yet, and isn't on the wishlist, would it be alright if I packaged it up? Or should just focus on stuff in the wishlist and try to clear up some of the backlog? The reason I asked was because someone on IRC gave this link to a font that doesn't appear on our wishlist, and appears to be brand-new: http://haikumonkey.net/?page_id=106 Maybe it can be added to the wishlist? Stephen From palango at gmx.de Fri Feb 6 15:03:47 2009 From: palango at gmx.de (Paul Lange) Date: Fri, 06 Feb 2009 12:03:47 -0300 Subject: fontconfig questions In-Reply-To: <1233875118.22086.9.camel@arekh.okg> References: <1233854692.8170.18.camel@localhost.localdomain> <1233875118.22086.9.camel@arekh.okg> Message-ID: <1233932627.3278.2.camel@localhost.localdomain> > I'm not sure that: > "the width and style is reminiscent of Luxi Sans, Lucida Sans, Tahoma, > and Andale Sans UI" is sufficient to mark the font as a valid substitute > for those fonts. So far we've only marked this way fonts that were > clearly derivatives of other fonts, or that claimed same (not > reminiscent) metrics. OK, I removed the substitution rules. > > I set the fontconfig-prefix of the sans-serif one to 61 (only latin) and > > of the monospace to 64 (only latin, only regular). Any comments on this? > > You can probably be more conservative with sans-serif Done this to and submitted a review request: https://bugzilla.redhat.com/show_bug.cgi?id=456527 regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From roozbeh at gmail.com Sat Feb 7 08:16:14 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sat, 7 Feb 2009 00:16:14 -0800 Subject: policy on shipping/using flags In-Reply-To: References: Message-ID: On Tue, Jan 13, 2009 at 12:08 PM, Roozbeh Pournader wrote: > * Presently, the Unicode consortium is considering a proposal to > encode various symbols (called emoji) used in Japanese cellphones in > the Unicode Standard. This very large set includes flags of a few > countries, like the flag of the People's Republic of China: > > http://www.unicode.org/~scherer/emoji4unicode/snapshot/utc.html#e-4E5 > [warning: hundreds of small icons on the page] > > From what I can tell, the proposal has a very high chance of > acceptance, and those flags will become Unicode characters. When fonts > we ship start to include glyphs for such flags, what do we do? Do we > remove them from the fonts when shipping them? I am just back from the Unicode Technical Committee meeting. During the emoji discussions, as a GNOME's representatives to Unicode, I mentioned some of the controversial issues that will raise if Unicode encodes flags. The committee agreed to not encode those characters as flags, but only as place-holder characters for compatibility with Japanese telephone company standards. The characters are now only called Emoji Symbol GB, Emoji Symbol CN, Emoji Symbol RU, etc, and their glyphs are just the two letters in a dashed box, like this: http://unicode.org/~scherer/emoji4unicode/fontimg/AEmoji_E4ED.png So, no worries on this part of the flags issue anymore. Roozbeh From sundaram at fedoraproject.org Sat Feb 7 08:55:34 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Feb 2009 14:25:34 +0530 Subject: New fonts not on wishlist? In-Reply-To: <498C4ACF.7020604@gmail.com> References: <498C4ACF.7020604@gmail.com> Message-ID: <498D4C86.9090008@fedoraproject.org> Stephen Carter wrote: > Greetings, > > I just had a quick question: If I happen to stumble across a new font > that isn't packaged yet, and isn't on the wishlist, would it be alright > if I packaged it up? Or should just focus on stuff in the wishlist and > try to clear up some of the backlog? > > The reason I asked was because someone on IRC gave this link to a font > that doesn't appear on our wishlist, and appears to be brand-new: > http://haikumonkey.net/?page_id=106 > > Maybe it can be added to the wishlist? Feel free to add it to the wishlist and package it up. Though a wishlist expresses desire on the part of users or another contributor, there is no compulsion on you to follow only the wishlist. As long as there are fonts that qualify (licensing etc), then you can very well package them up. Rahul From nicolas.mailhot at laposte.net Sun Feb 8 12:04:10 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 8 Feb 2009 13:04:10 +0100 (CET) Subject: New fonts not on wishlist? In-Reply-To: <498D4C86.9090008@fedoraproject.org> References: <498C4ACF.7020604@gmail.com> <498D4C86.9090008@fedoraproject.org> Message-ID: <8b2357c0aff0869d13db74e46b12104a.squirrel@arekh.dyndns.org> Le Sam 7 f?vrier 2009 09:55, Rahul Sundaram a ?crit : > > Stephen Carter wrote: >> Greetings, >> >> I just had a quick question: If I happen to stumble across a new >> font >> that isn't packaged yet, and isn't on the wishlist, would it be >> alright >> if I packaged it up? Or should just focus on stuff in the wishlist >> and >> try to clear up some of the backlog? >> >> The reason I asked was because someone on IRC gave this link to a >> font >> that doesn't appear on our wishlist, and appears to be brand-new: >> http://haikumonkey.net/?page_id=106 >> >> Maybe it can be added to the wishlist? > > Feel free to add it to the wishlist and package it up. Though a > wishlist > expresses desire on the part of users or another contributor, there is > no compulsion on you to follow only the wishlist. As long as there are > fonts that qualify (licensing etc), then you can very well package > them up. +1 You can always package fonts even if they're not on the wishlist as long as they're not marked radioactive http://fedoraproject.org/wiki/Category:Rejected_and_retired_fonts The only downside to packaging a font without a wishlist entry is that you have to create the wishlist entry page yourself, and no one else pre-filtered the font for legal suitability in your stead Regards, -- Nicolas Mailhot From palango at gmx.de Sun Feb 8 14:34:43 2009 From: palango at gmx.de (Paul Lange) Date: Sun, 08 Feb 2009 11:34:43 -0300 Subject: fontconfig questions In-Reply-To: <1233932627.3278.2.camel@localhost.localdomain> References: <1233854692.8170.18.camel@localhost.localdomain> <1233875118.22086.9.camel@arekh.okg> <1233932627.3278.2.camel@localhost.localdomain> Message-ID: <1234103683.3316.0.camel@localhost.localdomain> Am Freitag, den 06.02.2009, 12:03 -0300 schrieb Paul Lange: > > I'm not sure that: > > "the width and style is reminiscent of Luxi Sans, Lucida Sans, Tahoma, > > and Andale Sans UI" is sufficient to mark the font as a valid substitute > > for those fonts. So far we've only marked this way fonts that were > > clearly derivatives of other fonts, or that claimed same (not > > reminiscent) metrics. > > OK, I removed the substitution rules. > > > > I set the fontconfig-prefix of the sans-serif one to 61 (only latin) and > > > of the monospace to 64 (only latin, only regular). Any comments on this? > > > > You can probably be more conservative with sans-serif > > Done this to and submitted a review request: > https://bugzilla.redhat.com/show_bug.cgi?id=456527 Sorry, wrong link. See https://bugzilla.redhat.com/show_bug.cgi?id=484379 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From cchance at redhat.com Mon Feb 9 01:09:08 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Mon, 09 Feb 2009 11:09:08 +1000 Subject: Help request about hinting dev (Liberation Fonts). Message-ID: <498F8234.3020202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am currently maintaining Liberation Fonts project. As most of the bugs that I received were in regard to hinting defects, I would like to ask about info of font hinting. As you might heard of, Liberation Fonts were shipped from commercial fonts manufacturer, Ascender. The deliverable is in .TTF format. The files were converted into .SFD format and hosted as open source project on fedorahosted.org. Unfortunately, along the project runs, there are bug reports of hinting problem on certain characters. This has raised me the following needs of info/knowledge: - - Is there anyone in fedora community who could provide helpful info on how to manage a high quality hinting? - - Which free hinting tools are available other than fontforge? - - Where could I find resources of hinting instructions? Precisely, full specs of hinting instructions, such as parameter explanation of all hinting instructions - - If a CVT table has no comments on each value, do I have to do reverse engineering and how should I begin? As Mailhot's previous emails on new font packaging guidelines, he often let us refer to Dejavu Fonts. I am wondering if I could catch up any of Dejavu devs who don't mind kindly provide valuable info of hinting? Thank you very much for reading. Best Regards, kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmPgjQACgkQmo+B7bGj5dJaAACfX5rWtcoD9yEXFp6BOtp2ifWe gjoAnAwkVW6HV9rf18qlaF6H6ue6aTVa =5mvU -----END PGP SIGNATURE----- From benlaenen at gmail.com Mon Feb 9 12:09:35 2009 From: benlaenen at gmail.com (Ben Laenen) Date: Mon, 9 Feb 2009 13:09:35 +0100 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <498F8234.3020202@redhat.com> References: <498F8234.3020202@redhat.com> Message-ID: <200902091309.35601.benlaenen@gmail.com> On Monday 09 February 2009, Caius "kaio" Chance wrote: > - Is there anyone in fedora community who could provide helpful info > on how to manage a high quality hinting? Well, I'm not from the fedora community, but I've got experience from the hinting in the DejaVu fonts. > - Which free hinting tools are available other than fontforge? Tools and documentation are listed at http://www.dejavu-fonts.org/wiki/index.php?title=Hinting About xgridfit: I'm not really a fan of it. I think it may be usable for hinting completely new fonts, but I wouldn't start using it on an existing font. My hinting work is basically only done with the help of fontforge and gwaterfall. > - Where could I find resources of hinting instructions? Precisely, > full specs of hinting instructions, such as parameter explanation of > all hinting instructions You'll have to go through that documentation mentioned on the page above. The hinting tutorial on that page which I started myself once never really got far, but it can give some idea. > - If a CVT table has no comments on each value, do I have to do > reverse engineering and how should I begin? Yes, you'll have to do some reverse engineering. It takes a considerable amount of time, since you basically have to read the hinting of a lot of glyphs. Your goal is to get a table of values you may encounter in normal glyphs (and that for each style). http://www.dejavu-fonts.org/wiki/index.php?title=Control_Value_Table lists it for DejaVu and many fonts have values for the same things in their CVT so gives an idea what to expect in Liberation. There are usually many values in the CVT that don't really matter to you if you just want to hint some glyphs. > As Mailhot's previous emails on new font packaging guidelines, he > often let us refer to Dejavu Fonts. I am wondering if I could catch > up any of Dejavu devs who don't mind kindly provide valuable info of > hinting? Here we go then :-) When I'm online, find me at #dejavu or ##fonts on IRC if you have questions. Ben From cchance at redhat.com Mon Feb 9 14:14:08 2009 From: cchance at redhat.com (Caius Chance) Date: Tue, 10 Feb 2009 00:14:08 +1000 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <200902091309.35601.benlaenen@gmail.com> References: <498F8234.3020202@redhat.com> <200902091309.35601.benlaenen@gmail.com> Message-ID: <49903A30.6050903@redhat.com> Hi Ben, Ben Laenen ????????: > Well, I'm not from the fedora community, but I've got experience from > the hinting in the DejaVu fonts. Even better! :D >> - Which free hinting tools are available other than fontforge? > > Tools and documentation are listed at > http://www.dejavu-fonts.org/wiki/index.php?title=Hinting > > About xgridfit: I'm not really a fan of it. I think it may be usable for > hinting completely new fonts, but I wouldn't start using it on an > existing font. Could I know the reason why? > My hinting work is basically only done with the help of fontforge and > gwaterfall. If you are available, it would be fantastic if you briefly tell me in 10 -15 steps? >> - Where could I find resources of hinting instructions? Precisely, >> full specs of hinting instructions, such as parameter explanation of >> all hinting instructions Thomas Sailer gave me few valuable URLs just now, too: http://developer.apple.com/textfonts/TTRefMan/RM05/Chap5.html >> - If a CVT table has no comments on each value, do I have to do >> reverse engineering and how should I begin? > > Yes, you'll have to do some reverse engineering. It takes a considerable > amount of time, since you basically have to read the hinting of a lot > of glyphs. > > Your goal is to get a table of values you may encounter in normal glyphs > (and that for each style). > http://www.dejavu-fonts.org/wiki/index.php?title=Control_Value_Table > lists it for DejaVu and many fonts have values for the same things in > their CVT so gives an idea what to expect in Liberation. Good to confirm that with you, so I could start the reverse engineering. > Here we go then :-) > When I'm online, find me at #dejavu or ##fonts on IRC if you have > questions. Thanks for your kind offer. :) Best Regards, kaio. From benlaenen at gmail.com Mon Feb 9 14:48:08 2009 From: benlaenen at gmail.com (Ben Laenen) Date: Mon, 9 Feb 2009 15:48:08 +0100 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <49903A30.6050903@redhat.com> References: <498F8234.3020202@redhat.com> <200902091309.35601.benlaenen@gmail.com> <49903A30.6050903@redhat.com> Message-ID: <200902091548.08657.benlaenen@gmail.com> On Monday 09 February 2009, Caius Chance wrote: > > Tools and documentation are listed at > > http://www.dejavu-fonts.org/wiki/index.php?title=Hinting > > > > About xgridfit: I'm not really a fan of it. I think it may be > > usable for hinting completely new fonts, but I wouldn't start using > > it on an existing font. > > Could I know the reason why? Basically because it never convinced me it actually would make things easier and wouldn't just add an extra layer of complexity and compatibility issues. > > My hinting work is basically only done with the help of fontforge > > and gwaterfall. > > If you are available, it would be fantastic if you briefly tell me in > 10 -15 steps? What do you want to know exactly? Ben From cchance at redhat.com Mon Feb 9 14:57:47 2009 From: cchance at redhat.com (Caius Chance) Date: Tue, 10 Feb 2009 00:57:47 +1000 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <200902091548.08657.benlaenen@gmail.com> References: <498F8234.3020202@redhat.com> <200902091309.35601.benlaenen@gmail.com> <49903A30.6050903@redhat.com> <200902091548.08657.benlaenen@gmail.com> Message-ID: <4990446B.1020803@redhat.com> Ben Laenen ????????: > On Monday 09 February 2009, Caius Chance wrote: >>> My hinting work is basically only done with the help of fontforge >>> and gwaterfall. >> If you are available, it would be fantastic if you briefly tell me in >> 10 -15 steps? > > What do you want to know exactly? My previous experience was trying to fix hinting problems, I went into hinting instruction window of a glyph. Then looked at the hinting instructions and see if there are any problems. I am wondering about what extra you have done to a font, rather that just modifying hinting instructions. Thanks a lot. :) kaio From benlaenen at gmail.com Mon Feb 9 15:27:04 2009 From: benlaenen at gmail.com (Ben Laenen) Date: Mon, 9 Feb 2009 16:27:04 +0100 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <4990446B.1020803@redhat.com> References: <498F8234.3020202@redhat.com> <200902091548.08657.benlaenen@gmail.com> <4990446B.1020803@redhat.com> Message-ID: <200902091627.04503.benlaenen@gmail.com> On Monday 09 February 2009, Caius Chance wrote: > Ben Laenen ????????: > > On Monday 09 February 2009, Caius Chance wrote: > >>> My hinting work is basically only done with the help of fontforge > >>> and gwaterfall. > >> > >> If you are available, it would be fantastic if you briefly tell me > >> in 10 -15 steps? > > > > What do you want to know exactly? > > My previous experience was trying to fix hinting problems, I went > into hinting instruction window of a glyph. Then looked at the > hinting instructions and see if there are any problems. > > I am wondering about what extra you have done to a font, rather that > just modifying hinting instructions. You want a list of everything I've done with a font so far? :-p In respect to hinting in DejaVu the only things you can really do is editing existing instructions and creating new ones for the new glyphs. Over the time CVT values were added, the fpgm table was altered etc. After editing it's just a matter of testing it out -- you can do that within FontForge itself (grid fit), and then check in gwaterfall if there's not a weird problem at some size. Only the first person who wants to work on the hinting needs to do some work to know what the important CVT values are, and that's basically reading the existing instructions and write down which values are used where. It's usually pretty straightforward (if it moves a point on the right side of the stem of "I" horizontally when the reference point 0 is a point on the left side of that stem, then you know it's the horizontal stem width). But that requires understanding of the instructions of course (I don't know how much you know about it, http://www.dejavu-fonts.org/wiki/index.php?title=Hinting_tutorial/Example:_Hinting_L should give you the real basics if you're completely new). For hinting that's it really. I don't know what more you're expecting? From nicolas.mailhot at laposte.net Mon Feb 9 21:42:05 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 09 Feb 2009 22:42:05 +0100 Subject: FLOSS Multimedia Support in Fedora In-Reply-To: <1234210813.2799.60.camel@pc-notebook> References: <1234133019.2835.36.camel@pc-notebook> <1234176292.2835.45.camel@pc-notebook> <1234203840.2799.21.camel@pc-notebook> <1234208865.2799.46.camel@pc-notebook> <1234209758.5541.4.camel@arekh.okg> <1234210813.2799.60.camel@pc-notebook> Message-ID: <1234215725.6331.16.camel@arekh.okg> Le lundi 09 f?vrier 2009 ? 21:20 +0100, Martin Sourada a ?crit : > Well, not exactly, but yeah, in a sense it's similar. But don't forget > we need to target more platforms than fedora or *nix. You can always bundle the fonts separately for non *nix users. > > > than requiring your users to either find it themselves and > > > install it > > > > Fedora 11 will have automatic font installation for every app that cares > > to support it. > > > Is it already in rawhide? The autoprovides generation is. Though it still needs to be tweaked before the F11 mass rebuild http://koji.fedoraproject.org/koji/rpminfo?rpmID=994205 > If so, should I file bugs if say firefox does > not display some fonts on wikipedia title page and does not fire any > auto-installation dialog? https://bugzilla.mozilla.org/show_bug.cgi?id=467729 > > > or being satisfied with a fallback font (which might not > > > satisfy the artistic concerns that led you to the choice of the original > > > font). > > > > Artistic concerns are fine and dandy but they usually sink on the legal > > and i18n icebergs. Which I think the anime crowd at least cares about. > > > Well, when you choose a font for a sub, you usually check if it covers > your characters usage. Does not help a lot the next sub group. Yes japanese ? language1 ? language2 subbing happens pretty often in the anime community > Legal issues are harder to solve, but at least in > fedora the fonts range is getting, thanks to your efforts, very > promising. Also please note that all the GPL fonts that do not explicitely declare the FSF fonts exception are safe wrt CSS-like referencing but *not* embedding. > > BTW, we already ship fonts like Tiresias which were explicitely designed > > for video titling. > > > Cool, is there a (wiki) page with font previews/coverage? Or do I still > need to skim through Fonts group, install whatever seems like it would > fit my needs and than test what I installed? Right now, we don't have a preview system in Fedora :( > It would definitely be > useful for people looking for specific design/unicode coverage. Font preview generators and how to embed previews in static wiki pages/PK are being discussed in the open font library list right now. http://lists.freedesktop.org/archives/openfontlibrary/2009-February/001763.html The need has already been identified, but someone needs to do the coding work. Then I believe PK integration would follow quickly. http://bugzilla.freedesktop.org/show_bug.cgi?id=18928 It's the obvious next step after building a reasonable font package base. > PS: maybe it would be better to forward this thread part to the -fonts > list should there be any further discussion, I am subscribed there so > you won't need to CC me. Done :) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From martin.sourada at gmail.com Mon Feb 9 22:16:26 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 09 Feb 2009 23:16:26 +0100 Subject: FLOSS Multimedia Support in Fedora In-Reply-To: <1234215725.6331.16.camel@arekh.okg> References: <1234133019.2835.36.camel@pc-notebook> <1234176292.2835.45.camel@pc-notebook> <1234203840.2799.21.camel@pc-notebook> <1234208865.2799.46.camel@pc-notebook> <1234209758.5541.4.camel@arekh.okg> <1234210813.2799.60.camel@pc-notebook> <1234215725.6331.16.camel@arekh.okg> Message-ID: <1234217786.2799.86.camel@pc-notebook> On Mon, 2009-02-09 at 22:42 +0100, Nicolas Mailhot wrote: > Le lundi 09 f?vrier 2009 ? 21:20 +0100, Martin Sourada a ?crit : > > > Well, not exactly, but yeah, in a sense it's similar. But don't forget > > we need to target more platforms than fedora or *nix. > > You can always bundle the fonts separately for non *nix users. > Well, you can but while it makes the situation easier for the end user, it still requires them to install the fonts and I'm not sure if that is reasonably working on windows machines if the user does not have admin rights. > > > > than requiring your users to either find it themselves and > > > > install it > > > > > > Fedora 11 will have automatic font installation for every app that cares > > > to support it. > > > > > Is it already in rawhide? > > The autoprovides generation is. Though it still needs to be tweaked > before the F11 mass rebuild > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=994205 > Thanks for the info. > > If so, should I file bugs if say firefox does > > not display some fonts on wikipedia title page and does not fire any > > auto-installation dialog? > > https://bugzilla.mozilla.org/show_bug.cgi?id=467729 > Great, is there a bug for webkit filled as well? I can do that if that's not the case. > Does not help a lot the next sub group. Yes japanese ? language1 ? > language2 subbing happens pretty often in the anime community > Yep, it happens a lot, but in my experience the next subbing group is usually redoing the typesetting as well so I wouldn't call it a big issue ;-) > > Legal issues are harder to solve, but at least in > > fedora the fonts range is getting, thanks to your efforts, very > > promising. > > Also please note that all the GPL fonts that do not explicitely declare > the FSF fonts exception are safe wrt CSS-like referencing but *not* > embedding. > Good point. Are there any efforts in 'fixing' those issues? > > > BTW, we already ship fonts like Tiresias which were explicitely designed > > > for video titling. > > > > > Cool, is there a (wiki) page with font previews/coverage? Or do I still > > need to skim through Fonts group, install whatever seems like it would > > fit my needs and than test what I installed? > > Right now, we don't have a preview system in Fedora :( > That's a pity :( > > It would definitely be > > useful for people looking for specific design/unicode coverage. > > Font preview generators and how to embed previews in static wiki > pages/PK are being discussed in the open font library list right now. > > http://lists.freedesktop.org/archives/openfontlibrary/2009-February/001763.html > > The need has already been identified, but someone needs to do the coding > work. Then I believe PK integration would follow quickly. > > http://bugzilla.freedesktop.org/show_bug.cgi?id=18928 > > It's the obvious next step after building a reasonable font package > base. > Sounds promising. The idea of having it displayed in packagekit sounds even better than a wiki page with previews, though having both would be best (you can afford to include more details in wiki + you can do more fine-grained sort by unicode blocks coverage / language support). BTW. would it be worth making a feature page for these (and targeting it at F11 or F12)? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Feb 9 22:31:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 09 Feb 2009 23:31:16 +0100 Subject: FLOSS Multimedia Support in Fedora In-Reply-To: <1234217786.2799.86.camel@pc-notebook> References: <1234133019.2835.36.camel@pc-notebook> <1234176292.2835.45.camel@pc-notebook> <1234203840.2799.21.camel@pc-notebook> <1234208865.2799.46.camel@pc-notebook> <1234209758.5541.4.camel@arekh.okg> <1234210813.2799.60.camel@pc-notebook> <1234215725.6331.16.camel@arekh.okg> <1234217786.2799.86.camel@pc-notebook> Message-ID: <1234218676.6331.26.camel@arekh.okg> Le lundi 09 f?vrier 2009 ? 23:16 +0100, Martin Sourada a ?crit : > On Mon, 2009-02-09 at 22:42 +0100, Nicolas Mailhot wrote: > > Le lundi 09 f?vrier 2009 ? 21:20 +0100, Martin Sourada a ?crit : > > > > > Well, not exactly, but yeah, in a sense it's similar. But don't forget > > > we need to target more platforms than fedora or *nix. > > > > You can always bundle the fonts separately for non *nix users. > > > Well, you can but while it makes the situation easier for the end user, > it still requires them to install the fonts and I'm not sure if that is > reasonably working on windows machines if the user does not have admin > rights. Windows users without admin rights exist? How do they install the video viewing app? > > > > > than requiring your users to either find it themselves and > > > > > install it > > > > > > > > Fedora 11 will have automatic font installation for every app that cares > > > > to support it. > > > > > > > Is it already in rawhide? > > > > The autoprovides generation is. Though it still needs to be tweaked > > before the F11 mass rebuild > > > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=994205 > > > Thanks for the info. Actually, Behdad just decided it needed a rewrite :p > > > If so, should I file bugs if say firefox does > > > not display some fonts on wikipedia title page and does not fire any > > > auto-installation dialog? > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=467729 > > > Great, is there a bug for webkit filled as well? I can do that if that's > not the case. https://bugs.webkit.org/show_bug.cgi?id=22621 Others are here http://fedoraproject.org/wiki/Known_fonts_and_text_bugs Feel free to fill more if I missed some. > > > Legal issues are harder to solve, but at least in > > > fedora the fonts range is getting, thanks to your efforts, very > > > promising. > > > > Also please note that all the GPL fonts that do not explicitely declare > > the FSF fonts exception are safe wrt CSS-like referencing but *not* > > embedding. > > > Good point. Are there any efforts in 'fixing' those issues? ?Fixing? is managing to reach the original authors, some of whom are not native English speakers, and explain them what the problem is and that they should really add the font exception to their licensing. It's slow work and I doubt it will ever be 100% completed. > > > It would definitely be > > > useful for people looking for specific design/unicode coverage. > > > > Font preview generators and how to embed previews in static wiki > > pages/PK are being discussed in the open font library list right now. > > > > http://lists.freedesktop.org/archives/openfontlibrary/2009-February/001763.html > > > > The need has already been identified, but someone needs to do the coding > > work. Then I believe PK integration would follow quickly. > > > > http://bugzilla.freedesktop.org/show_bug.cgi?id=18928 > > > > It's the obvious next step after building a reasonable font package > > base. > > > > Sounds promising. The idea of having it displayed in packagekit sounds > even better than a wiki page with previews, though having both would be > best (you can afford to include more details in wiki + you can do more > fine-grained sort by unicode blocks coverage / language support). > > BTW. would it be worth making a feature page for these (and targeting it > at F11 or F12)? Font autoinstall is already a F11 feature. The current font repackaging work was proposed as a feature, but FESCO basically said ?that's nice, please do it, but I don't think that should be marketed as a feature? If someone could be found work on the preview stuff I think it would definitely qualify as a feature. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fangqq at gmail.com Mon Feb 9 23:34:50 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Mon, 9 Feb 2009 18:34:50 -0500 Subject: help with source package font path Message-ID: hi I thought that I sent an email asking this as followups for Bug#478891, but just realized the email was never posted at bugzilla :( anyway, I am still experiencing the incorrect font path error when compiling wqy-zenhei-fonts with the new fontpackages templates. The error and my spec file can be found at https://bugzilla.redhat.com/show_bug.cgi?id=478891#c3 and https://bugzilla.redhat.com/show_bug.cgi?id=478891#c4 basically, the installer first unpacked the upstream source tarball, and then attempted to "cd wqy-zenhei-fonts-0.8.34", unfortunately, the upstream package does not name the folder that way, simply "wqy-zenhei/", so the installer quit. I am wondering which variable controls the source folder name and how can I fix this? thank you Qianqian -------------- next part -------------- An HTML attachment was scrubbed... URL: From cchance at redhat.com Tue Feb 10 00:07:46 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Tue, 10 Feb 2009 10:07:46 +1000 Subject: Help request about hinting dev (Liberation Fonts). In-Reply-To: <200902091627.04503.benlaenen@gmail.com> References: <498F8234.3020202@redhat.com> <200902091548.08657.benlaenen@gmail.com> <4990446B.1020803@redhat.com> <200902091627.04503.benlaenen@gmail.com> Message-ID: <4990C552.5050707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Laenen wrote: > For hinting that's it really. I don't know what more you're expecting? That's what I am expecting. Thanks very much, Ben. :) Best Regards, kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmQxVIACgkQmo+B7bGj5dID7QCeJnpGFiQZV6bfQEwfUQUXIsCD jiQAn0DeqtVWg5T2bxWHjr3LGOVNan7u =1hEE -----END PGP SIGNATURE----- From cchance at redhat.com Tue Feb 10 00:23:45 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Tue, 10 Feb 2009 10:23:45 +1000 Subject: help with source package font path In-Reply-To: References: Message-ID: <4990C911.8020703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Qianqian Fang wrote: > > basically, the installer first unpacked the upstream source tarball, and > then attempted to "cd wqy-zenhei-fonts-0.8.34", unfortunately, the > upstream package does not name the folder that way, simply > "wqy-zenhei/", so the installer quit. > > I am wondering which variable controls the source folder name and how > can I fix this? Yes, I have experienced same thing before. :) %setup -q -n %{name}-%{version}.devel You could set the directory extracted from tarball with any name. In above example, %{name}-%{version}.devel i.e. '%setup -q -n wqy-zenhei-fonts-0.8.34' should works for you, but it should be better to have %{fontname}-fonts-%{version} like naming. Best Regards, kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmQyRAACgkQmo+B7bGj5dIryQCdE82uCgvJjc+QTDP3nfUUw0NX bdgAnji03KKWc+ofU2yF3wdaEqEFR++E =Vw+W -----END PGP SIGNATURE----- From fangqq at gmail.com Tue Feb 10 05:08:07 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 10 Feb 2009 00:08:07 -0500 Subject: help with source package font path In-Reply-To: <4990C911.8020703@redhat.com> References: <4990C911.8020703@redhat.com> Message-ID: <49910BB7.1040604@gmail.com> it works! thank you Qianqian Caius "kaio" Chance wrote: > Yes, I have experienced same thing before. :) > > %setup -q -n %{name}-%{version}.devel > > You could set the directory extracted from tarball with any name. In > above example, %{name}-%{version}.devel > > i.e. '%setup -q -n wqy-zenhei-fonts-0.8.34' should works for you, but it > should be better to have %{fontname}-fonts-%{version} like naming. > > Best Regards, > kaio > > > - -- > Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com > JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkmQyRAACgkQmo+B7bGj5dIryQCdE82uCgvJjc+QTDP3nfUUw0NX > bdgAnji03KKWc+ofU2yF3wdaEqEFR++E > =Vw+W > -----END PGP SIGNATURE----- > > From fangqq at gmail.com Tue Feb 10 06:36:05 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 10 Feb 2009 01:36:05 -0500 Subject: help with source package font path In-Reply-To: <49910BB7.1040604@gmail.com> References: <4990C911.8020703@redhat.com> <49910BB7.1040604@gmail.com> Message-ID: <49912055.6020102@gmail.com> one more question: for font packages which do not have any fontconfig files, how should I formulate the %_font_pkg line? One of the examples is wqy-unibit-fonts, I kept only the font file following -f but rpm failed when compiling. Qianqian Qianqian Fang wrote: > it works! thank you > > Qianqian > > Caius "kaio" Chance wrote: >> Yes, I have experienced same thing before. :) >> >> %setup -q -n %{name}-%{version}.devel >> >> You could set the directory extracted from tarball with any name. In >> above example, %{name}-%{version}.devel >> >> i.e. '%setup -q -n wqy-zenhei-fonts-0.8.34' should works for you, but it >> should be better to have %{fontname}-fonts-%{version} like naming. >> >> Best Regards, >> kaio >> >> >> - -- >> Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com >> JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkmQyRAACgkQmo+B7bGj5dIryQCdE82uCgvJjc+QTDP3nfUUw0NX >> bdgAnji03KKWc+ofU2yF3wdaEqEFR++E >> =Vw+W >> -----END PGP SIGNATURE----- >> >> > > _______________________________________________ > Fedora-fonts-list mailing list > Fedora-fonts-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-fonts-list > From cchance at redhat.com Tue Feb 10 06:48:47 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Tue, 10 Feb 2009 16:48:47 +1000 Subject: help with source package font path In-Reply-To: <49912055.6020102@gmail.com> References: <4990C911.8020703@redhat.com> <49910BB7.1040604@gmail.com> <49912055.6020102@gmail.com> Message-ID: <4991234F.8080504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Qianqian Fang wrote: > one more question: for font packages which do not have any fontconfig > files, how should I formulate the %_font_pkg line? One of the examples is > wqy-unibit-fonts, I kept only the font file following -f but rpm failed > when > compiling. You need to create that manually. Please kindly use the templates in 'fontpackages' sources. kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmRI08ACgkQmo+B7bGj5dLmFgCfYyITTNRIpihOqZkz0hcrLBPP vgYAnR5f9zwZXUbcCiDdxoXD24KF8xbo =K0e4 -----END PGP SIGNATURE----- From fangqq at gmail.com Tue Feb 10 07:01:18 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 10 Feb 2009 02:01:18 -0500 Subject: help with source package font path In-Reply-To: <4991234F.8080504@redhat.com> References: <4990C911.8020703@redhat.com> <49910BB7.1040604@gmail.com> <49912055.6020102@gmail.com> <4991234F.8080504@redhat.com> Message-ID: <4991263E.70704@gmail.com> Caius "kaio" Chance wrote: > You need to create that manually. Please kindly use the templates in > 'fontpackages' sources. > > kaio > > ok, I took out the -f from _font_pkg and now it works with just having the font file. From nicolas.mailhot at laposte.net Tue Feb 10 07:06:54 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Feb 2009 08:06:54 +0100 Subject: help with source package font path In-Reply-To: <49912055.6020102@gmail.com> References: <4990C911.8020703@redhat.com> <49910BB7.1040604@gmail.com> <49912055.6020102@gmail.com> Message-ID: <1234249614.13439.1.camel@arekh.okg> Le mardi 10 f?vrier 2009 ? 01:36 -0500, Qianqian Fang a ?crit : > one more question: for font packages which do not have any fontconfig > files, how should I formulate the %_font_pkg line? One of the examples is > wqy-unibit-fonts, I kept only the font file following -f but rpm failed > when compiling. -f is the fontconfig file switch so you can never have -f font_files However Caius is right making the effort to produce a fontconfig file for every font subpackage is much preferred -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From palango at gmx.de Tue Feb 10 16:58:17 2009 From: palango at gmx.de (Paul Lange) Date: Tue, 10 Feb 2009 13:58:17 -0300 Subject: Help with licensing questions Message-ID: <1234285097.3289.22.camel@localhost.localdomain> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nicolas.mailhot at laposte.net Tue Feb 10 21:39:47 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Feb 2009 22:39:47 +0100 Subject: Help with licensing questions In-Reply-To: <1234285097.3289.22.camel@localhost.localdomain> References: <1234285097.3289.22.camel@localhost.localdomain> Message-ID: <1234301987.21616.52.camel@arekh.okg> 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. Hi Paul, Fonts and sources are a non-trivial problem. Here is some general context I'm going to add to the wiki: 1. Modern font formats are pretty complex and complete, and can be modified directly by editors like fontforge. For this reason many font people affirm there is no need to require separate ?sources?. There is little to no information loss when an OpenType file is generated from other intermediary format. 2. The OFL, in particular, considers that just giving authorisation to others to modify and redistribute the generated font file is sufficient, and you do not need to publish the specific format your font editor uses. (other font licenses express this opinion in more awkward terms like the GUST NOSOURCE license). 3. Likewise, when a font author edits the TTF/OTF/TTC font files directly in his favorite font editor, those files are clearly the canonical ?sources? the (L)GPL intended to be relayed, and they should be treated the same way as script files: both source and build result. 4. However it is also not uncommon to have authors that edit their fonts in some other format, and convert it to TTF/OTF/TTC at the last creation stage (with possibly some scripted transformations before). Those authors would clearly consider having to restart from the TTF/OTF/TTC files a setback (or at least a loss of convenience). In that case TTC/OTF/TTF files are clearly not the canonical ?sources? in the (L)GPL sense. 6. Since Fedora cares about freedom, and wants to give itself and downstream the means to modify the fonts it ships should the need arises, we'd like you as packager to make the effort to locate the canonical sources of a font project and generate your font files from them in the %build stage. This even if the particular free/open license of the font you package does not make it an absolute licensing requirement. 7. For example the fontforge sfd format is text-based and makes it possible to use a normal patch/vcs-based FLOSS workflow, so it is very desirable to use canonical sources in that format whenever upstream provides them. 8. Nevertheless if there is no evidence the font author works from some other ?sources?, or didn't publish them, and didn't reply or refused to do it when contacted by mail, there is little you can do. Even if the font project is licensed under the (L)GPL you do not have access to separate ?sources?. Fedora can not be sued for not passing on something the original author didn't provide. In that case package the TTF/OTF/TTC files directly. 9. Similarly, if the actual source files are made available, but are in some other font editor format free tools like fontforge can not edit, you can't really build from them. In that case package the sources in the srpm but ship the generated files upstream provided in the rpm. 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. 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 hope this clears the mud a little. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Feb 10 22:00:46 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Feb 2009 23:00:46 +0100 Subject: Font previewer requirements Message-ID: <1234303246.21616.70.camel@arekh.okg> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dave at lab6.com Wed Feb 11 00:14:03 2009 From: dave at lab6.com (Dave Crossland) Date: Wed, 11 Feb 2009 00:14:03 +0000 Subject: [OpenFontLibrary] Font previewer requirements In-Reply-To: <1234303246.21616.70.camel@arekh.okg> References: <1234303246.21616.70.camel@arekh.okg> Message-ID: <2285a9d20902101614i20f97c42j3590a661be00aa15@mail.gmail.com> 2009/2/10 Nicolas Mailhot : > > A good static previewer: Ed Trager's upcoming "Fontaine" ought to be helpful here :-) From hartke at gmail.com Thu Feb 12 03:08:18 2009 From: hartke at gmail.com (Stephen Hartke) Date: Wed, 11 Feb 2009 21:08:18 -0600 Subject: Help with licensing questions Message-ID: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> [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 * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Thu Feb 12 15:51:39 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Feb 2009 16:51:39 +0100 (CET) Subject: Help with licensing questions In-Reply-To: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> Message-ID: Le Jeu 12 f?vrier 2009 04:08, Stephen Hartke a ?crit : >> 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. [...] > 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? Basically, I don't think the format of your font should drive your licensing decisions. If the GPL is appropriate for the metatype version it's appropriate for the OTF version. Just "it looks more like software as usual" is a weak reason. Now, I do agree one of the OFL's main weakness is its refusal to admit fonts may have sources (the other being the way it considers you want your font renamed instead of making it an option), but the GPL has other problems (embedding). But the differences in their licensing model are only marginally linked to the format. > 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. It would be very nice if you could publish the files you intend to work from in buildable form so the Fedora packager can make a srpm that produces fonts from your sources. -- Nicolas Mailhot From evets25 at gmail.com Sat Feb 14 01:20:35 2009 From: evets25 at gmail.com (Stephen Carter) Date: Fri, 13 Feb 2009 20:20:35 -0500 Subject: another font packaged, awaiting reviews. Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas_spalinger at sil.org Sat Feb 14 21:51:52 2009 From: nicolas_spalinger at sil.org (Nicolas Spalinger) Date: Sat, 14 Feb 2009 22:51:52 +0100 Subject: Help with licensing questions In-Reply-To: References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> Message-ID: <49973CF8.7050807@sil.org> [...] > Now, I do agree one of the OFL's main weakness is its refusal to admit > fonts may have sources (the other being the way it considers you want > your font renamed instead of making it an option), but the GPL has > other problems (embedding). Hi Stephen and Nicolas, Very interesting thread indeed, some crucial points have been explained very clearly but I have to disagree with the little analysis snippet above... (BTW, Nicolas, IIRC we already had conversations about this wrt. the buildpath of Old Standard). The OFL doesn't refuse to admit that font sources exist - rather the contrary - it acknowledges the fact that beyond the binary font files themselves, which you can already do something with, there are a lot of different elements which can be used as extended font sources. It avoids the problematic question of defining precise source requirements for the "preferred form of modification" when there are various ways of modifying and building a font: "preferred" for who exactly? A very strict source requirement would alienate the vast majority of designers we want to see joining our community! Font Software is broadly defined in the license: "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. So the OFL model intentionally doesn't place strict requirements on releasing these extended sources needed for a full build but at the same time it *makes it possible and strongly encourages* (via the FAQ) the author choosing this model to release everything that can be useful to designers: data files, glyph databases, smart code, build scripts, documentation and rendering samples. See FAQ entry 2.6, 4.1, 4.2 and 7 http://scripts.sil.org/OFL-FAQ_web So the idea is to recommend releasing as much extended source as possible and turning that into best practises but *not making it mandatory* which would result in a participation barrier. The FAQ has more details and, as you probably know, there is a foo-open-font-sources VCS template with all kind of different elements to encourage release of as much source as possible: http://svn.debian.org/wsvn/pkg-fonts/foo-open-font-sources/?rev=0&sc=0 BTW, your feedback on this is still welcome, it's intended as a cross-distro, cross-OS recommendation. And if you really don't want any kind of anti-collision / name protection features the OFL does not require you to reserve a name: FAQ entries 2.11 and 2.12 have more on this. I agree with you that the GPL (even with the current font exception) has various problems. If it worked perfectly for fonts everybody would be using it... It needs fixing. I'd recommend also investigating how to distribute your build scripts separately under a "full-source-required" license (documentation on the requirements of the build environment would be very useful too). Alternatively you could work with the ones interested in an absolute full source requirement model for all recipients (with corresponding source redistribution offer) to create the licensing model you like and then organise community review. I do understand the packager's perspective of ideally having a self-contained autobuilding source rpm for each open font family, but the reality is that this rarely the case at this stage. We have also seen that as fontforge and related tools make progress, automatic building from sources does introduce regressions. (IMHO most packagers don't have the experience to fully compare between a font build done by the designer himself and an automated build). Thankfully there are various efforts going in this direction, but let's not get ahead of ourselves. A fully automated build would be nice to have but we're not going to drop from our distros all open fonts not yet providing such a build path, that would be rather silly. HTH, -- Nicolas Spalinger, NRSI volunteer Debian/Ubuntu font team / OpenFontLibrary http://planet.open-fonts.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From hartke at gmail.com Sun Feb 15 17:47:52 2009 From: hartke at gmail.com (Stephen Hartke) Date: Sun, 15 Feb 2009 11:47:52 -0600 Subject: Help with licensing questions In-Reply-To: References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> Message-ID: <63973460902150947x5f7cdde8s464c89ef2006c8df@mail.gmail.com> Nicolas (M), Thanks for your response to my email! More below. On Thu, Feb 12, 2009 at 9:51 AM, Nicolas Mailhot wrote: > Basically, I don't think the format of your font should drive your > licensing decisions. If the GPL is appropriate for the metatype > version it's appropriate for the OTF version. Just "it looks more like > software as usual" is a weak reason. > I think that the license of my font _should_ be driven by the format, or, more specifically, by the information that is being released and reused for making a derivative work. Releasing MetaType1 sources under the GPL and the OTF file under the OFL seems to accomplish exactly what I want: If someone makes a derivative font by modifying the sources and distributes it, then I want them to be required to distribute their modified sources, just as the GPL requires. It doesn't seem to me that the OFL would require this. If however someone modifies the OTF file directly using FontForge, then using the GPL is rather nonsensical since there is no source. In that case, the OFL seems to be the perfect license. I don't see how either license by itself accomplishes my goals. Licensing the sources under the GPL (with font embedding exception) and the OTF file under the OFL seems a reasonable compromise that accomplishes what I want. Best wishes, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartke at gmail.com Sun Feb 15 17:53:09 2009 From: hartke at gmail.com (Stephen Hartke) Date: Sun, 15 Feb 2009 11:53:09 -0600 Subject: Help with licensing questions In-Reply-To: <49973CF8.7050807@sil.org> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> <49973CF8.7050807@sil.org> Message-ID: <63973460902150953i26da8294wa53d3fe2d30f67eb@mail.gmail.com> Nicolas (S), Thanks for your contribution to the thread! More below. On Sat, Feb 14, 2009 at 3:51 PM, Nicolas Spalinger < nicolas_spalinger at sil.org> wrote: > The OFL doesn't refuse to admit that font sources exist - rather the > contrary - it acknowledges the fact that beyond the binary font files > themselves, which you can already do something with, there are a lot of > different elements which can be used as extended font sources. It avoids > the problematic question of defining precise source requirements for > the "preferred form of modification" when there are various ways of > modifying and building a font: "preferred" for who exactly? A very > strict source requirement would alienate the vast majority of designers > we want to see joining our community! > I agree that the question of sources is very tricky, and probably for the majority of fonts, it doesn't make sense. In that sense, I think the OFL is a realistic license. > So the OFL model intentionally doesn't place strict requirements on > releasing these extended sources needed for a full build but at the same > time it *makes it possible and strongly encourages* (via the FAQ) the > author choosing this model to release everything that can be useful to > designers: data files, glyph databases, smart code, build scripts, > documentation and rendering samples. However, in the case that I actually have sources (and more than just build scripts), I want those to be protected in the sense that modification of those sources must also be redistributed along with the corresponding modified font. I don't see that the OFL would require this, and so I don't see the OFL as the right license for the sources. Best wishes, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Feb 16 09:24:50 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Feb 2009 10:24:50 +0100 (CET) Subject: Help with licensing questions In-Reply-To: <49973CF8.7050807@sil.org> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> <49973CF8.7050807@sil.org> Message-ID: <997910980f7bd1b22236e9e61726b556.squirrel@arekh.dyndns.org> Le Sam 14 f?vrier 2009 22:51, Nicolas Spalinger a ?crit : > [...] Oh, my little flamebait had its intended effect :p >> Now, I do agree one of the OFL's main weakness is its refusal to >> admit >> fonts may have sources (the other being the way it considers you >> want >> your font renamed instead of making it an option), but the GPL has >> other problems (embedding). > > Hi Stephen and Nicolas, Hi all, > Very interesting thread indeed, some crucial points have been > explained > very clearly but I have to disagree with the little analysis snippet > above... (BTW, Nicolas, IIRC we already had conversations about this > wrt. the buildpath of Old Standard). > > The OFL doesn't refuse to admit that font sources exist - rather the > contrary - it acknowledges the fact that beyond the binary font files > themselves, which you can already do something with, there are a lot > of > different elements which can be used as extended font sources. It > avoids > the problematic question of defining precise source requirements This is what I mislike. ? Avoiding ? is not tackling problems, it's hoping someone else will solve them for you (and someone else usually doesn't). > for > the "preferred form of modification" when there are various ways of > modifying and building a font: "preferred" for who exactly? Clearly, ? preferred ? for the upstreams of a release. The basic objective of the GPL is to level the playing field and make sure downstreams get their hands on the same source files upstreams prefer to use. Maybe it could be rewritten in less software-oriented speak but the basic requirement is very necessary for a sane ecosystem. > A very > strict source requirement would alienate the vast majority of > designers we want to see joining our community! You're trading short-term wins for long-term problems. I'm quite sure the TEX people though lax licensing checks would be a win too. IMHO Stephen's answers show not being clear on it is confusing to OFL users. > Font Software is broadly defined in the license: > "Font Software" refers to the set of files released by the Copyright > Holder(s) under this license and clearly marked as such. This may > include source files, build scripts and documentation. Which is a lax definition and pretty unlikely to result in source releases for designers who do not understand the FLOSS yet. > So the OFL model intentionally doesn't place strict requirements on > releasing these extended sources needed for a full build but at the > same > time it *makes it possible and strongly encourages* (via the FAQ) the > author choosing this model to release everything that can be useful to > designers: data files, glyph databases, smart code, build scripts, > documentation and rendering samples. > > See FAQ entry 2.6, 4.1, 4.2 and 7 > http://scripts.sil.org/OFL-FAQ_web Not that FAQs are not good, I wrote a few of them myself, but it's hard enough to have authors properly read the license text they use without relying on external documents. > So the idea is to recommend releasing as much extended source as > possible and turning that into best practises but *not making it > mandatory* which would result in a participation barrier. > > The FAQ has more details and, as you probably know, there is a > foo-open-font-sources VCS template with all kind of different elements > to encourage release of as much source as possible: > http://svn.debian.org/wsvn/pkg-fonts/foo-open-font-sources/?rev=0&sc=0 > BTW, your feedback on this is still welcome, it's intended as a > cross-distro, cross-OS recommendation. I must admit I still find it overly complex and too oriented towards SIL tools and workflows. A simplified version for ? normal ? fontforge-based FLOSS projects would do a lot more good IMHO. I sort of hoped the Senecca font packaging project proposal would result in someone giving a fresh eye to it but I was probably overly ambitious. > And if you really don't want any kind of anti-collision / name > protection features the OFL does not require you to reserve a name: > FAQ entries 2.11 and 2.12 have more on this. It's still not very clear and confusing both upstreams and downstreams. It should be clearly stated that no name is reserved unless stated explicitely in the license file bundled with the font files. > I agree with you that the GPL (even with the current font exception) > has > various problems. If it worked perfectly for fonts everybody would be > using it... It needs fixing. Really, SIL and FSF lawyers need to be walled in a room with only hard bread and clear water till they can hash a satisfying FLOSS font license :p The OFL is marginally better for fonts but has its own problems. I'm no lawyer, and not a native English speaker, but I don't find the current licenses very satisfying. [...] > I do understand the packager's perspective of ideally having a > self-contained autobuilding source rpm for each open font family, but > the reality is that this rarely the case at this stage. It will only improve by trying to make it so. > We have also > seen that as fontforge and related tools make progress, automatic > building from sources does introduce regressions. (IMHO most packagers > don't have the experience to fully compare between a font build done > by the designer himself and an automated build). IMHO the tools to do it are missing but they'll keep missing till distros actually start regularly building fonts from sources and expose the tooling needs. The years of doing nothing and hoping the problem would solve itself didn't result in lots of advances. If you want good floss fonts, you'll have to accept the failures with the successes. If you refuse the failures you don't move at all. > Thankfully there are various efforts going in this direction, but > let's > not get ahead of ourselves. A fully automated build would be nice to > have but we're not going to drop from our distros all open fonts not > yet providing such a build path, that would be rather silly. Not a requirement yet. But yet can be quite short-lived depending on the pace of your distribution. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Feb 16 09:38:12 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Feb 2009 10:38:12 +0100 (CET) Subject: Help with licensing questions In-Reply-To: <63973460902150947x5f7cdde8s464c89ef2006c8df@mail.gmail.com> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> <63973460902150947x5f7cdde8s464c89ef2006c8df@mail.gmail.com> Message-ID: Le Dim 15 f?vrier 2009 18:47, Stephen Hartke a ?crit : > Nicolas (M), Hi Stephen, > Thanks for your response to my email! More below. Responses are free here :) > On Thu, Feb 12, 2009 at 9:51 AM, Nicolas Mailhot > wrote: > >> Basically, I don't think the format of your font should drive your >> licensing decisions. If the GPL is appropriate for the metatype >> version it's appropriate for the OTF version. Just "it looks more >> like >> software as usual" is a weak reason. >> > > I think that the license of my font _should_ be driven by the format, > or, > more specifically, by the information that is being released and > reused for > making a derivative work. > > Releasing MetaType1 sources under the GPL and the OTF file under the > OFL seems to accomplish exactly what I want: Please consider that you are the only one who can do this, and any downstream that will use your GPL sources will have no choice but to have the produced fonts under the GPL too. Which won't be embeddable if you forget the right clause. -1 for the GPL *This* is why I wrote your licensing decisions should not be driven by your (source) format. Your downstreams do not have the luxury to re-licence when they need to change the font format, they'll have to use the same license as the sources they work from, so any licensing model that is adherent to the produced format is broken by design. > > If someone makes a derivative font by modifying the sources and > distributes > it, then I want them to be required to distribute their modified > sources, > just as the GPL requires. It doesn't seem to me that the OFL would > require this. Well, I disagree with Nicolas S. the OFL is satisfying here :p > If however someone modifies the OTF file directly using FontForge, > then using the GPL is rather nonsensical since there is no source. That is arguing only binary compiled files can be (L)GPLed, when the evidence is lots of interpreted files authors are happy with this license for their perl/python/js/shell scripts. > In that case, the OFL seems to be the perfect license. Not really :( BTW, had the source and build scripts been clearly identified as necessary from the start on, they'd be mirrored today in all the distros shipping your fonts and would not have been lost :( -1 for the OFL. Sincerely, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Feb 16 09:38:53 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Feb 2009 10:38:53 +0100 (CET) Subject: Help with licensing questions In-Reply-To: <63973460902150953i26da8294wa53d3fe2d30f67eb@mail.gmail.com> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> <49973CF8.7050807@sil.org> <63973460902150953i26da8294wa53d3fe2d30f67eb@mail.gmail.com> Message-ID: Le Dim 15 f?vrier 2009 18:53, Stephen Hartke a ?crit : > I agree that the question of sources is very tricky, and probably for > the majority of fonts, it doesn't make sense. This is complete confusion. You don't see people argue scripts or interpreted python/perl/whatever files can't be (L)GPL-ed because there is not separate source files do you? IMHO one of the great OFL failures was not acknowledging font files can be their own sources when upstream edits them directly, and perpetuating the ? sources are strange dangerous stuff ? urban myth. Regards, -- Nicolas Mailhot From dave at lab6.com Tue Feb 17 01:36:11 2009 From: dave at lab6.com (Dave Crossland) Date: Tue, 17 Feb 2009 01:36:11 +0000 Subject: Help with licensing questions In-Reply-To: <63973460902150947x5f7cdde8s464c89ef2006c8df@mail.gmail.com> References: <63973460902111908n35d4e196odbd9613eab4f91ec@mail.gmail.com> <63973460902150947x5f7cdde8s464c89ef2006c8df@mail.gmail.com> Message-ID: <2285a9d20902161736x413f53bid751f2b2c1bc382d@mail.gmail.com> 2009/2/15 Stephen Hartke : > > I think that the license of my font _should_ be driven by the format, It seems that when the format "source files" of a font are "source code" then this triggers an automatic, hypnotic, response to use the GPL. However, licensing is really a political choice, not a technical one; which is to say, license choices are driven by politics. IMHO, AIUI, the OFL is intended for designers who don't want to deal with the complexity of the GPL and are new to free software; but if you are convinced that sources ought to be available and your font ought to always remain free, and you don't mind providing sources, then the OFL seems a strange choice to me. You get the ability to remix the font with other OFL fonts, but I'm not sure how useful that is in practice. > If someone makes a derivative font by modifying the sources and distributes > it, then I want them to be required to distribute their modified sources, > just as the GPL requires. It doesn't seem to me that the OFL would require > this. OFL doesn't require sources, it just recommends them. This means OFL fonts can be proprietorised; for example, they can be pushed through a program like superpolator.com (proprietary Mac OS X tool) to extend them, but the interpolation masters are not required to be distributed with the font, nor are formats required to be transparent/freely available. GPLv3 fixes these problems. > If however someone modifies the OTF file directly using FontForge, then > using the GPL is rather nonsensical since there is no source. In that case, > the OFL seems to be the perfect license. > > I don't see how either license by itself accomplishes my goals. Dual licensing is not very good for downstream users, because they fork the project when a downstream only uses one of the licenses. I think GPL+FontException (and a contact details so you can be contacted when a better "Font GPL" is prepared) is the best thing for this project. -- Regards, Dave From welovebemani at gmail.com Thu Feb 19 19:30:40 2009 From: welovebemani at gmail.com (AKanda) Date: Thu, 19 Feb 2009 20:30:40 +0100 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) Message-ID: <499DB360.6050804@gmail.com> 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 From nicolas.mailhot at laposte.net Sun Feb 22 14:26:45 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 22 Feb 2009 15:26:45 +0100 Subject: Fedora needs your help Message-ID: <1235312805.10047.41.camel@arekh.okg> 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.html ? 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_Test http://fedoraproject.org/wiki/Improving_existing_font_packages -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Feb 23 11:29:10 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Feb 2009 12:29:10 +0100 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <499DB360.6050804@gmail.com> References: <499DB360.6050804@gmail.com> Message-ID: <1235388550.5356.9.camel@arekh.okg> Le jeudi 19 f?vrier 2009 ? 20:30 +0100, AKanda a ?crit : > Hello, Hi Akanda, > The last update for VLgothics"vlgothic-fonts-20090204-2.fc10.noarch" > is perhaps not good. (Install by yum.) Sorry for the delay, I was hoping other CJK users would answer, I don't use CJK myself. Chinese, Korean and Japanese fonts are an old source of pain for font packagers, due to: 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 2. the complexity of the associated glyphs, that make some users claim bitmap fonts should be preferred to vector fonts at small sizes (of course others disagree, and latin users clearly prefer bitmap fonts, except when people are not careful they change both instead of just one). Almost every single CJK update breaks things, and we can not freeze CJK fonts as new releases and new fonts are requested by users. I can unfortunately not offer a lot of help. CJK problems can only be fixed by CJK users. We need more CJK people to install various combinations of CJK packages and check they do the right thing for every CJK locale. If you have the time please test various combinaisons of CJK fonts in F10 (or better rawhide) and report your findings in bugzilla. http://fedoraproject.org/wiki/Checking_fontconfig_rules Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From petersen at redhat.com Tue Feb 24 01:04:39 2009 From: petersen at redhat.com (Jens Petersen) Date: Mon, 23 Feb 2009 20:04:39 -0500 (EST) Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <1425376623.136621235437267581.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <507347737.136701235437479936.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "AKanda" 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_the_Desktop.html#sn-Fonts (fr) http://docs.fedoraproject.org/release-notes/f10/en_US/What_is_the_Latest_on_the_Desktop.html#sn-Fonts (en) ? It looks like you are suffering from the Han unification issue Nicolas mentioned. Jens From roozbeh at gmail.com Tue Feb 24 04:39:21 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Mon, 23 Feb 2009 20:39:21 -0800 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) Message-ID: > 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 From fangqq at gmail.com Tue Feb 24 04:40:42 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Mon, 23 Feb 2009 23:40:42 -0500 Subject: Fwd: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: <1425376623.136621235437267581.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <507347737.136701235437479936.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: sorry, forget to cc the list ---------- Forwarded message ---------- From: Qianqian Fang Date: Mon, Feb 23, 2009 at 11:40 PM Subject: Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) To: Jens Petersen On Mon, Feb 23, 2009 at 8:04 PM, Jens Petersen wrote: > ----- "AKanda" 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-fonts-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fangqq at gmail.com Tue Feb 24 05:53:20 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 24 Feb 2009 00:53:20 -0500 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: <49A38B50.8020909@gmail.com> >> 1. the way Unicode.org decided it would be a good idea to have them >> share codepoints ("Han unification"), >> Using unified code points to represent Han glyphs is nothing wrong, the only issue is the current fonts and fontconfig are not capable of distinguishing the z-variants, as Unicode consortium proposed. >> so CJK packagers compete with each other to make their pet font the default >> I think it is quite the opposite: this happens most often when people are trying to read CJK text under non-CJK locales. Pango does not assume language preference, and it falls into a mixed situation where both the context language and the fall-back font sequence in fontconfig (likely 65-nonlatin) play together to determine the font to select, and the results are messy. It would have been better if one of the Han variants is the default when this happens, for example, the one that covers the most unicode code points, at least, all the characters will have uniform font styles, rather than the mosaics from many CJK fonts. From petersen at redhat.com Tue Feb 24 07:22:42 2009 From: petersen at redhat.com (Jens Petersen) Date: Tue, 24 Feb 2009 02:22:42 -0500 (EST) Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A38B50.8020909@gmail.com> Message-ID: <2000652001.149581235460162528.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I think the particular problem here under F10 is https://bugzilla.redhat.com/show_bug.cgi?id=485562 ----- "Qianqian Fang" wrote: > I think it is quite the opposite: this happens most often when people > are trying to read CJK text under non-CJK locales. Pango does not > assume > language preference, and it falls into a mixed situation where both > the > context language and the fall-back font sequence in fontconfig > (likely > 65-nonlatin) play together to determine the font to select, and the > results are > messy. It would have been better if one of the Han variants is the > default > when this happens, for example, the one that covers the most unicode > code > points, at least, all the characters will have uniform font styles, > rather > than the mosaics from many CJK fonts. Hmm, maybe we should define PANGO_LANGUAGE for non CJK locale, but to which value. Well guess most points would be zh? ;) Jens From nicolas.mailhot at laposte.net Tue Feb 24 08:23:18 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 24 Feb 2009 09:23:18 +0100 (CET) Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: Le Mar 24 f?vrier 2009 05:39, Roozbeh Pournader a ?crit : > 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. I suspect the only reason that does not happen is we have a lot more CJK packages than Arabic packages (and no Fraktur packages that I know of). > 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. It's not really a centralizing problem. If we had a clear "official" clean way to write fontconfig cjk rules I'd happily crack down on packagers not using them. Right now we haven't really, so I refrain. Nevertheless CJK fonts easily account for 80% of our reported font bug. It would be nice if our intended priorities and fontconfig settings for CJK fonts were documented somewhere (for every concerned locale). Then I could pester Behdad so he tells us how to achieve them cleanly. Right now, I'm not even sure this is clear to anyone but the concerned packagers. And every time I open a CJK fontconfig file I see magic of the blackest sort. Sincerely, -- Nicolas Mailhot From welovebemani at gmail.com Tue Feb 24 08:24:30 2009 From: welovebemani at gmail.com (AKanda) Date: Tue, 24 Feb 2009 09:24:30 +0100 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <2000652001.149581235460162528.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <2000652001.149581235460162528.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <49A3AEBE.6030005@gmail.com> Jens Petersen a ?crit : > I think the particular problem here under F10 is > > https://bugzilla.redhat.com/show_bug.cgi?id=485562 > Hello, In OpenOffice (for exemple), I have always written in Japanese with the default font (DejaVu Sans ".) But in fact if I write with vlgothic it's good. Also, if I force the system with vlgothic is also good. The problem would be "DejaVu Sans" (think) (sorry for my english) From benlaenen at gmail.com Tue Feb 24 14:02:28 2009 From: benlaenen at gmail.com (Ben Laenen) Date: Tue, 24 Feb 2009 15:02:28 +0100 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A3AEBE.6030005@gmail.com> References: <2000652001.149581235460162528.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <49A3AEBE.6030005@gmail.com> Message-ID: <200902241502.28445.benlaenen@gmail.com> On Tuesday 24 February 2009, AKanda wrote: > Jens Petersen a ?crit : > > I think the particular problem here under F10 is > > > > https://bugzilla.redhat.com/show_bug.cgi?id=485562 > > Hello, > In OpenOffice (for exemple), I have always written in Japanese with > the default font (DejaVu Sans ".) > But in fact if I write with vlgothic it's good. > > Also, if I force the system with vlgothic is also good. > > The problem would be "DejaVu Sans" (think) That would be very awkard since DejaVu doesn't have any CJK glyphs. What's happening is that for your "Sans" font selection, it will get translated by rules in the fontconfig configuration files (basically a list of fonts telling what to use for "Sans"), and it chooses the first font in the list that's capable of showing the displayed script. So in your case it chooses DejaVu to display Latin, and when it encounters CJK glyphs, fontconfig has no idea whether it's Chinese or Japanese, and so selects the first font in the list with the necessary glyphs, and that's a Chinese font. The solution is to move your VLGothic font above the Chinese font in that list. Greetings Ben From roozbeh at gmail.com Tue Feb 24 21:31:53 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Tue, 24 Feb 2009 13:31:53 -0800 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: On Tue, Feb 24, 2009 at 12:23 AM, Nicolas Mailhot wrote: > I suspect the only reason that does not happen is we have a lot more > CJK packages than Arabic packages (and no Fraktur packages that I know > of). :-) You may be very right. > It would be nice if our intended priorities and fontconfig settings > for CJK fonts were documented somewhere (for every concerned locale). > Then I could pester Behdad so he tells us how to achieve them cleanly. > Right now, I'm not even sure this is clear to anyone but the concerned > packagers. And every time I open a CJK fontconfig file I see magic of > the blackest sort. So, would you recommend a process and some high priorities? fedora-i18n has a stake in this too, and we may be able to ask them for some help. (I would love to help in doing this, but I don't have much experience with either CJK or fontconfig rules. I will jump in whenever Unicode skills were called in. I also have a copy of the tome I mentioned before, but haven't really spent much time with it.) Roozbeh From cchance at redhat.com Wed Feb 25 04:24:38 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Wed, 25 Feb 2009 14:24:38 +1000 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: <49A4C806.30108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roozbeh Pournader wrote: >> It would be nice if our intended priorities and fontconfig settings >> for CJK fonts were documented somewhere (for every concerned locale). >> Then I could pester Behdad so he tells us how to achieve them cleanly. >> Right now, I'm not even sure this is clear to anyone but the concerned >> packagers. And every time I open a CJK fontconfig file I see magic of >> the blackest sort. I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) which priority of such Chinese fonts are at higher priority in condition of "zh" (Chinese) locale. The fedora 10 patch will be pushed to update-testing very soon. - - kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9 =C40I -----END PGP SIGNATURE----- From cchance at redhat.com Wed Feb 25 04:35:07 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Wed, 25 Feb 2009 14:35:07 +1000 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4C806.30108@redhat.com> References: <49A4C806.30108@redhat.com> Message-ID: <49A4CA7B.9080903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Caius "kaio" Chance wrote: > I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) > which priority of such Chinese fonts are at higher priority in condition > of "zh" (Chinese) locale. > > The fedora 10 patch will be pushed to update-testing very soon. http://kojipkgs.fedoraproject.org/packages/cjkunifonts/0.2.20080216.1/11.fc10/noarch/cjkunifonts-uming-0.2.20080216.1-11.fc10.noarch.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=86225 - - kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmkynsACgkQmo+B7bGj5dIHeQCeMnBDdu0tyMDRnz1HakdYJpvB AzQAn0L62dgbP1rlN2qhjB8VPHu6Z+Sc =E5jL -----END PGP SIGNATURE----- From fangqq at gmail.com Wed Feb 25 06:36:17 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Wed, 25 Feb 2009 01:36:17 -0500 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4C806.30108@redhat.com> References: <49A4C806.30108@redhat.com> Message-ID: <49A4E6E1.3000805@gmail.com> Caius "kaio" Chance wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Roozbeh Pournader wrote: > >>> It would be nice if our intended priorities and fontconfig settings >>> for CJK fonts were documented somewhere (for every concerned locale). >>> Then I could pester Behdad so he tells us how to achieve them cleanly. >>> Right now, I'm not even sure this is clear to anyone but the concerned >>> packagers. And every time I open a CJK fontconfig file I see magic of >>> the blackest sort. >>> > > I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) > which priority of such Chinese fonts are at higher priority in condition > of "zh" (Chinese) locale. > I think this basically means the Japanese fonts are now having higher priorities under non-CJK locales, is this really what we want? > The fedora 10 patch will be pushed to update-testing very soon. > > - - kaio > > - -- > Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com > JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc > nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9 > =C40I > -----END PGP SIGNATURE----- > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > > > From tagoh at redhat.com Wed Feb 25 08:22:54 2009 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 25 Feb 2009 17:22:54 +0900 (JST) Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4E6E1.3000805@gmail.com> References: <49A4C806.30108@redhat.com> <49A4E6E1.3000805@gmail.com> Message-ID: <20090225.172254.907329729220785007.tagoh@redhat.com> >>>>> On Wed, 25 Feb 2009 01:36:17 -0500, >>>>> "QF" == Qianqian Fang wrote: QF> I think this basically means the Japanese fonts are now QF> having higher QF> priorities under non-CJK locales, is this really what we QF> want? Current fontconfig policy doesn't really helps in this case. if one really wants to see a text with proper font, they need to set PANGO_LANGUAGE with the appropriate locales ordered or embed Pango attributes in text for GNOME. However right now cjkunifonts fontconfig config affected Japanese desktop too because current fontconfig policy in Fedora suggests having a recipe to override default substitution lists for specific locale and all of Japanese fonts has already followed these rules, but cjkunifonts didn't and fontconfig reads it prior to Japanese fonts'. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Sat Feb 28 06:44:43 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 27 Feb 2009 23:44:43 -0700 Subject: fontforge scripting change Message-ID: <20090227234443.137fac26@ohm.scrye.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: