From tagoh at redhat.com Wed Jan 6 06:53:02 2010 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 06 Jan 2010 15:53:02 +0900 (JST) Subject: fontconfig config priority In-Reply-To: <1261523666.10237.18.camel@arekh.okg> References: <20091217.230651.608190743439536704.tagoh@redhat.com> <1261523666.10237.18.camel@arekh.okg> Message-ID: <20100106.155302.932986285788528835.tagoh@redhat.com> >>>>> On Wed, 23 Dec 2009 00:14:26 +0100, >>>>> "NM" == Nicolas Mailhot wrote: NM> Wondeful! If you want commit access to fontpackages to have it NM> integrated with our other tools, just ask (if the licensing is OK with NM> you) Sure. that sounds nice :) NM> LGC roughtly means latin-like alphabetical scripts that are written NM> linearly with few ligatures, and those that exist optional (not indic, NM> not arabic, not cjk?) Also an unofficial requirement for those scripts NM> is to be from regions where people are familiar enough with latin NM> letters not to butcher them when they include them in fonts So I guess the language coverages of ISO-8859-{1-5,7,9,10,13-16} may works similarly right? NM> Those ranges are inherited from the fontconfig master file split that NM> occured a few years ago upstream. I'm not so sure that nowadays they are NM> the most appropriate. I see. I don't mind which ranges should be used. my point here is to have a bit more strict prioirty-sets to apply the fontconfig config files efficiently. NM> We've certainly started pushing a lot more NM> fontconfig files that upstream thought at the time, and are hitting many NM> limitations (layout that was supposed to be flexible enough to allow NM> customization, but is not really because of the files that have kept NM> long font lists). If you try to split the non-latin file, for example, NM> you quickly hit prefix starvation. Correct if it's spent randomly. I didn't mean that though. and that's also why I'm suggesting to have more clearer definition in the policy to not make more breakage. at least to avoid it in Fedora. I'm at the position where to have minimum-sets of the configuration in upstream. which doesn't mean to have a starter kit nor all-in-one. but just leave to each fonts packages to have one. generally speaking, ideally if a kind of the font installer can create/install the certain fontconfig configuration file into the system, that would be really nice. once we have more strict policy we could have that feature perhaps. NM> you quickly hit prefix starvation. However, that's just MHO. Other NM> people may not share it. But please keep an open mind and do propose NM> another file naming convention if you find a better one. I think that NM> the main requirements would be to NM> 1. clearly define the ranges a local sysadmin, a distro, and fontconfig NM> upstream fallbacks should use NM> 2. try to separate classes of fonts to minimize risks of conflicts (like NM> the current lgc/non lgc split) NM> 3. make locale appear when it is relevant NM> 4. make the font names appear in filenames so people do not need NM> grepping to locate where the rules associated with their font are Sure. that looks sane. NM> I don't think using comps brutally will work : NM> 1. currently we do not have separate comps groups for every NM> fontconfig/css generic, fontconfig and apps really want a separate font NM> stack for each generic (though this could be fixed by splitting the NM> master fonts comps group) NM> 2. sometimes our requirements are a lot more subtle than NM> mandatory/default : dejavu and liberation are both default, but their NM> ordering is not random I see. so what's the _default font_ means in the policy then? I was assuming if it's available at the system. thus, focusing attention on comps then though. Anyway, if we have obvious definition for that, I'm fine then. possibly everything goes into the higher priority will messes up you know. this is the main reason why I'm trying to make the font packages better, making the fontconfig configuration files machine-auditable to reduce the check-cost. NM> However I can only applaud trying to improve our fontconfig packaging, NM> and writing qa tests: this is sorely needed, if we want to continue NM> improving Fedora font support. NM> Best regards, NM> -- NM> Nicolas Mailhot -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From john.brown009 at gmail.com Thu Jan 7 16:28:39 2010 From: john.brown009 at gmail.com (TK009) Date: Thu, 07 Jan 2010 11:28:39 -0500 Subject: Questions about packaging CYKLOP font Message-ID: <4B460BB7.7010508@gmail.com> hail troopers and trooperettes, I want to package the CYKLOP font and need to clear up the caveats. I am not sure what is required for caveat #2: "This licensing would not require building from source, though it would be nice to get the sources published and use them to build the Fedora OTFs." What does that mean? Right now there are two font files in a .zip, are they not the source? What am I asking the creator for? This leads to my second question, how do I package this font? Do I create two packages (one for each font) using the same archive or is something else required here? links: https://fedoraproject.org/wiki/GUST_Cyklop_fonts http://nowacki.strefa.pl/cyklop-e.html http://nowacki.strefa.pl/pliki/Cyklop-otf-0_91.zip TK009 From nicolas.mailhot at laposte.net Thu Jan 7 18:54:06 2010 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jan 2010 19:54:06 +0100 Subject: Questions about packaging CYKLOP font In-Reply-To: <4B460BB7.7010508@gmail.com> References: <4B460BB7.7010508@gmail.com> Message-ID: <1262890446.3818.18.camel@arekh.okg> Le jeudi 07 janvier 2010 ? 11:28 -0500, TK009 a ?crit : > hail troopers and trooperettes, Hail brave font packager > I want to package the CYKLOP font and need to clear up the caveats. > > I am not sure what is required for caveat #2: > "This licensing would not require building from source, though it > would > be nice to get the sources published and use them to build the Fedora > OTFs." > > What does that mean? Right now there are two font files in a .zip, are > > they not the source? What am I asking the creator for? GUST people come from a TEX background. I suspect cyclop was created through a complex process starting from metafont sources followed by convertion to other formats. In an ideal world this process would be replayed by our srpm so anyone willing could tweak the initial metafont file and change the font like the authors. However, this is all speculation on my part, Cyclop creators didn't document their creation process anywhere I know. It's probably better to start packaging the files they did publish, and ask *very* *politely* how they created them and if it would be possible to replay the technical parts. They don't understand the GPL so "source" vocabulary will be meaningless to them. > This leads to my second question, how do I package this font? Do I > create two packages (one for each font) using the same archive or is > something else required here? As specified in http://fedoraproject.org/wiki/Packaging:FontsPolicy#Package_layout_for_fonts you're supposed to group fonts of the same family in the same (sub)package, and split fonts of different families in different (sub)packages The family part of a font name is anything that do not specifies width, weight or slant. Canonical values for width, weight and slant have been specified by microsoft in their WWS whitepaper http://blogs.msdn.com/text/attachment/2249036.ashx (Microsoft and Adobe are the two companies behind the OpenType spec) Unfortunately many fonts do not respect this spec, and put bits that belong to font style in the font family name, or the reverse. When that is the case you're supposed to package according to the naming the font author should have used, and ask him to fix its files. I've tried to explain this in http://nim.fedorapeople.org/Understanding%20fonts%20and%20fontconfig.tar.gz (need to finish the slides and publish them properly) Since GUST members understand technical font aspects, (if not legal aspects), I'm pretty sure their naming is sane. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: