Re: fontconfig config priority
Le jeudi 17 décembre 2009 à 23:06 +0900, Akira TAGOH a écrit : Hi, Hi, I have a question and a suggestion for the fontconfig config priority in the font packaging policy. I'm writing a small script to validate the fontconfig config in packages to not mess up. Wondeful! If you want commit access to fontpackages to have it integrated with our other tools, just ask (if the licensing is OK with you) the goal is to check if the priority is set accurately and the config files are following our templates. it roughly started working. but I'm not quite sure what Latin in LGC really covers. is it similar to what Latin-[1-10] covers? or more strictly applied? LGC roughtly means latin-like alphabetical scripts that are written linearly with few ligatures, and those that exist optional (not indic, not arabic, not cjk…) Also an unofficial requirement for those scripts is to be from regions where people are familiar enough with latin letters not to butcher them when they include them in fonts A more professional description would be welcome :) The suggestion is, about improving the policy to set the priority more strictly. I have two ideas: 1) have variety of the priorities for non-LGC fonts as well like for default, main and low perhaps. even though LGC fonts has a priority for default font, but not for non-LGC fonts. it may messes up their default font if multiple fonts with the same priority such as 65 are installed. this priority things could avoids this issue. it may be something like: 65-69 ... High priority non-LGC fonts 70... Main non-LGC font list 71-64 ... Low priority non-LGC fonts Those ranges are inherited from the fontconfig master file split that occured a few years ago upstream. I'm not so sure that nowadays they are the most appropriate. We've certainly started pushing a lot more fontconfig files that upstream thought at the time, and are hitting many limitations (layout that was supposed to be flexible enough to allow customization, but is not really because of the files that have kept long font lists). If you try to split the non-latin file, for example, you quickly hit prefix starvation. However, that's just MHO. Other people may not share it. But please keep an open mind and do propose another file naming convention if you find a better one. I think that the main requirements would be to 1. clearly define the ranges a local sysadmin, a distro, and fontconfig upstream fallbacks should use 2. try to separate classes of fonts to minimize risks of conflicts (like the current lgc/non lgc split) 3. make locale appear when it is relevant 4. make the font names appear in filenames so people do not need grepping to locate where the rules associated with their font are It is possible in fontconfig to use something longer that the current 2-digit prefixes to order files 2) describes what exactly default, Main and Low priority means. during developing and testing this script, I see some packages is possibly wrongly set the priority to their fontconfig config files, for example, some font is set the priority to 57 that is supposed to be the default font, but not marked as mandatory in comps. so I'd suggest to update comps or change the priority like: - mandatory for higher priority - default for main priority - optional for low priority and update the policy with it as well. I don't think using comps brutally will work : 1. currently we do not have separate comps groups for every fontconfig/css generic, fontconfig and apps really want a separate font stack for each generic (though this could be fixed by splitting the master fonts comps group) 2. sometimes our requirements are a lot more subtle than mandatory/default : dejavu and liberation are both default, but their ordering is not random However I can only applaud trying to improve our fontconfig packaging, and writing qa tests: this is sorely needed, if we want to continue improving Fedora font support. Best regards, -- Nicolas Mailhot signature.asc Description: This is a digitally signed message part ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: dist-git proof of concept phase 1 complete
BTW, please make sure the new system has something like cvs-import (ie put the files in this srpm as new changeset in the vcs, I don't want to know how your vcs works, this is a good srpm just eat it) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le mardi 15 décembre 2009 à 16:54 +, Paul Jakma a écrit : I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. Apples and oranges. 64bit on other arches only changes memory accesses, x86_64 changes a lot more than just that, and the other changes in x86_64 trump the memory costs. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 08:06, Josephine Tannhäuser a écrit : 2009/12/6, Adrian Reber adr...@lisas.de: https://bugzilla.redhat.com/show_bug.cgi?id=544720 This is not a lib! The guidelines should be read as: « Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons » (Just IMHO, that's the guidelines spirit, the guidelines text should be amended in a non-library-oriented wording, libs are the most common case but they're not the only one) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit : As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. The worst case I've seen reported is when the RAM overhead managed to annihilate register improvements (worst case in a very specific load). So RAM overhead is pretty much a urban myth on x86_64 -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Le Lun 14 décembre 2009 00:20, Bruno Wolff III a écrit : On Sun, Dec 13, 2009 at 19:02:55 -0200, Henrique Junior henrique...@gmail.com wrote: By the way, Monty is asking for some Help saving MySQL [0]. Monty can just go and fork it. The only limitation is that he won't be able to dual license it any more. Yes, unfortunately a lot of the noise against the SUN/Oracle merger is people that just want the licensing changed because they can't imagine building a successful company on GPL software (very sad). The same kind of people splintered the open source Java community by refusing to help sun when it GPL-ed the JVM and diverting resources to new projetcs instead. That being said, Mysql *does* compete with Oracle (not technically, but commercially very much so, it kills the use one db everywhere corp market paradigm where Oracle is all too happy to count cpus for lots of small Oracle databases), and this competition relies on the Mysql brand (that finally managed to reach CTO awareness level), and Oracle getting its hand on the brand would definitely lower competition for several years (and I don't have any SAP or other shares). -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 11:28, Josephine Tannhäuser a écrit : 2009/12/14, Nicolas Mailhot nicolas.mail...@laposte.net: The guidelines should be read as: « Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons » This is more a wishful thinking than a practical thing The guidelines should be a system of rules without place for everyone to interprete in it what he/she wants to see in the guidelines. I don't have the time right now but I personally would not hesitate to propose this as a formal packaging guideline if FPC feels it is not what the current guidelines intended (but did not express cleanly). Every domain I've packaged has the same recurring maintenance problems with bundled components (be it libraries, java jars, reference files), there is nothing library specific in the problems bundling causes (forking, non tracking of upstream fixes, conflicts, etc) So, you may think this is wishful thinking, but on my experience it is a very practical and pragmatic rule. Bundling helps you get new components in fast and then makes package maintenance a burden forever (years after years). -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 12:45, Josephine Tannhäuser a écrit : of course this is a practicable rule, BUT the problem is upstream or the rule itself. kernels internal zlib is not a lib its a module, wordpress internal php-gettext is not a lib, its a php code file. The trick is to declare that a lib is not a lib and you can close the bug as not a bug... Easy cake.. This is playing with words. I'm sure that when the guideline was written lib was intended as some code in any language that can be shared. What is less clear is the other shared components which are not code (resource files, fonts, templates, etc) but there is no doubt at all in my mind on the code part. Though your interpretation is one reason we keep refining guidelines to leave no room for bad packager excuses. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Lun 14 décembre 2009 12:51, Ralf Corsepius a écrit : Of course, this is an extreme case, but they also aren't that rare in real world cases. They aren't that rare on very specific workloads (numeric computation). People in those fields often have large datasets that appreciate lots of memory (ours work with GiB-sized datasets at least) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
On Monday 14 December 2009 04:27:52 am Nicolas Mailhot wrote: Though your interpretation is one reason we keep refining guidelines to leave no room for bad packager excuses. Just to be clear what is bad here is the excuse, not the packager (didn't realise it when writing, English has this funny property you can stack words directly and create valid sentences that may be read in many different ways) It is hard to write unambiguous text. In guidelines or other documents. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Le lundi 14 décembre 2009 à 17:03 +0200, Devrim GÜNDÜZ a écrit : On Sun, 2009-12-13 at 19:27 -0500, Tom Lane wrote: (FWIW, I completely agree with Monty that Oracle is likely to do their best to kill MySQL once they have it. But they can't kill the GPL'd version as long as people are willing to work on that. Evidently Monty isn't.) http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL -109.html Oracle Makes Commitments to Customers, Developers and Users of MySQL Oracle commitments are only worth the money Oracle expects earning through them. For example the BEA commitment was we will support existing customers for 10 years, and the nuances of what exactly support means when Oracle has decided a product had no future are only starting to get clear today. This new PR only commits for three years. That's a miser, it would take at least that much time for Oracle to execute a smooth kill (transitioning existing Mysql customers) if it started today. You need to remember Oracle's bread and butter is the Enterprise market where time scales are longer (as evidenced by the 7 years+ RHEL release lifecycle) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
Le vendredi 11 décembre 2009 à 11:31 -0800, Adam Williamson a écrit : It also encourages lazy interface design - the designer can always think 'well, I'll just make this a checkbox under 'advanced' somewhere', rather than considering how to properly design a single configuration interface. I fail to see how it is worse than designers that think this is advanced stuff, I don't need to handle it and then redefine advanced users as people able to use bugzilla and contradict me At least in the fist lazy design variant the features are available somewhere. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
Le Mer 9 décembre 2009 15:00, Dominik 'Rathann' Mierzejewski a écrit : Actually, x86_64 is an AMD invention (originally called AMD64) and is called EM64T by Intel. The only Intel 64 I can think of is IA64, i.e. Itanium (called Itanic by some). When Intel realised Itanium was a failure, they dumped the ia32/ia64 classification and adopted x32/x64 (which is the same thing, except x64 != ia64, talk about hiding past mistakes) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Le Ven 4 décembre 2009 13:50, Matěj Cepl a écrit : Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): Since the patents covering the TrueType bytecode interpreter expired at the end of October, I've now built FreeType in rawhide with that part of code enabled. can we hope for the update in F12 as well, please? Given how any font rendering changes seems to degrade font rendering for some users, I'd very much prefer it went through a full release testing cycle before hitting unsuspecting users. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Le Ven 4 décembre 2009 13:50, Matěj Cepl a écrit : Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): Since the patents covering the TrueType bytecode interpreter expired at the end of October, I've now built FreeType in rawhide with that part of code enabled. can we hope for the update in F12 as well, please? Given how any font rendering changes seems to degrade font rendering for some users, I'd very much prefer it went through a full release testing cycle before hitting unsuspecting users. -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Proposed F13 feature: drop separate updates repository
Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: JBoss in Fedora
Le Jeu 26 novembre 2009 01:21, Ricardo Argüello a écrit : Is there anybody interested in helping port JPackage's JBoss to Fedora 13: https://fedoraproject.org/wiki/JBoss I understand there is an ongoing work to include JBoss AS 5.1 in JPackage.org. Where can we get this SRPMS to begin porting? The bits constituting JBoss are landing one after another in the jpackage cvs. You can go there to check them. It is no easy integration work because JBoss upstream insists on using old versions of several components, when other java apps already depend on newer ones, and because java dependency handling is in the stone age. When this is finished Jpackage-side, I'm sure many people will be interested in importing the result in Fedora. (however if it's done again in fork-and-forget mode with incompatibilities gratuituously introduced Fedora-side and the Fedora maintainer completely absent when users start complaining at the jpp packager that did most of the work Fedora benefited from, I'm sure it won't improve the relationship between the projects) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mercredi 25 novembre 2009 à 01:11 +0100, Matěj Cepl a écrit : I think you didn't get the message ... you are very welcome (well, I guess, you are) to fix packaging of those fonts (see bugs at http://is.gd/52X4m). If you say, that somebody else should do the work (I was looking at it whether I could help there, but my estimate was something like a week of full time work), then let that somebody else to decide whether it makes sense. Thanks Matěj To sum up the situation: 1. The long-deprecated core fonts ecosystem is composed of users, some code xorg side, and a large pile of font files this code accesses 2. The xorg code at at least one built-in backup font to use it are not going away 3. The large pile of core fonts, OTOH, is in bitrotting packages that didn't see real maintenance for a long time (were bitrotting way before the Fedora Core handover and were never cleaned up since). They still regularly fail and cause crashes that make a bad rep to Fedora fonts. 4. Some people like me and Matěj have been spending or were planning to spend some time trying to fix this. Not because we use this stuff, but because of some misplaced sense of duty. It is not fun stuff at all, however, and anything that helps reducing the enveloppe to fix is welcome news. 5. The real users of this stuff never contributed a bit to this maintenance, avoid answering questions when people ask something about it, refused to write packaging guidelines to help others do this work for them when (repeatedly) invited to, and react in a very hostile manner when they get a single mail asking them to make some effort to stop using this stuff (either patching it out, convincing their upstream to do this change, or finding another non-core-fonts-using alternative to package in Fedora, there are many possible solutions). They were *not* asked to help cleaning up the font packages themselves, because, after all this years of no action, it's pretty clear none of them want to. In other words, they collectively expect someone else to do the ugly, boring, and time-consuming work on the stuff they use, and BTW this someone else should shut up about it and not remind them they behave like parasites (let's call things by their real name). Given all this, I'm not motivated a lot to contribute to this work anymore (if I end up doing it it's because I promised people like Matěj help, not because I feel like helping core fonts users anymore. If Matěj and others do their part I'll help them but that's all). So I suppose the only remaining course of action is to: A. investigate if it's possible for a core fonts client to make sure it only accesses the built-in backup core font. B. if not investigate it it's possible to write a small proxy lib with a core-fonts-like api that do not let an app select any font but the built-in backup core font C. if A. or B. are true, orphan all the core font packages in Fedora, and give their current users the choice of : a. drop their core font use b. make sure they only access the built-in backup core font (possibly, writing B themselves) c. actually pick up the maintenance of the core fonts packages they use, starting with writing (and getting approved) clear guidelines how they should be packaged, then passing each of the core fonts packages they need through a thorough Fedora review (not let anyone re-import them in their current awful state, then sit up doing nothing about it) In others words, go through the orphan route that was suggested by others in this thread. (RHEL will of course make its own choices) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mercredi 25 novembre 2009 à 10:03 +0100, Nicolas Mailhot a écrit : A. investigate if it's possible for a core fonts client to make sure it only accesses the built-in backup core font. B. if not investigate it it's possible to write a small proxy lib with a core-fonts-like api that do not let an app select any font but the built-in backup core font Or even simpler, define a magic font name the core fonts system never resolves to anything else than the built-in font. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 14:17, Felix Kaechele a écrit : Am 23.11.2009 22:50, schrieb Adam Williamson: He already said that he had talked to his upstreams and they had said they would not adjust their code. In that case, he really has done everything he possibly can in his position as maintainer, and sending him further nag emails is achieving nothing constructive and serving only to annoy him. And eventually may lead to packagers stopping to contribute to the Fedora Project. I do not wish to be used as a medium for a fight between a stubborn Font Guideline Evangelist and a stubborn upstream. If it's upstream's decision not to adjust their code then that's the way it is. If the package does not cause any unexpected behavior by not following the Font Guidelines there is nothing further I as a package maintainer am required to do. To repeat myself once again, core fonts are not free, they have a maintenance cost, and none of the packagers that claimed using core fonts is not a problem so far has made the logical step of taking charge of what they say is no problem. Either it is no problem, and you are ready to take it out of my hands, or it is a problem, so stop pretending it is not and I'm unreasonable saying it is so. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 16:00, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: To repeat myself once again, core fonts are not free, they have a maintenance cost, What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. The costs could go down to nothing if there was no core font user left in Fedora How is badgering other maintainers a good thing? It is reducing the problem envelope. If you don't want to maintain something, then the normal way is to orphan it and let someone else take the job, not badger everybody else using the thing you don't want to maintain anymore. Does not work that way. If it was a clear package dependency, I could orphan the stuff, and all the people who complain at me now would be forced to take themselves in charge and do the work needed by the stuff they use. Because of the brain-damaged way core fonts were specified, the dependency is not expressed in that way and I can not stop caring about core fonts without stopping caring about other fonts (because as long as I have a fonts hat, and no one has a core fonts one, people come to me by default and don't want to hear about differences in font systems). If you insist, I can ask formally FESCO if it thinks I do more harm than good. It it thinks so, I'll do the logical thing, and go back to being just the DejaVu maintainer, which was actually fun to do, and less time-wasting besides. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:01, Chris Adams a écrit : That's not an answer. What is the real maintenance cost? I already explained yesterday : there are rotting Fedora Core packages to merge review, packaging guidelines to write to define how they are supposed to be cleaned up, a huge pile of existing fonts to re-check for licensing, a huge pile of fonts to re-check for technical soundness (ie a lot of fonts for that area are not encoded properly or declare bad names, should it continue to be hidden via manual fonts.dir or should they be converted to something cleaner, it we continue to go the manual fonts.dir way someone needs to review existing files) etc. We still had crashes this year due to problems in some fonts.dir. When i18n asked what was the exact need for bitmap-fonts no one answered. There is a need of someone that can answer other Fedora groups when such questions are asked. etc, etc -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:06, Jeremy Sanders a écrit : Nicolas Mailhot wrote: The costs could go down to nothing if there was no core font user left in Fedora Surely some are required for external legacy applications (including free software and propitiatory applications)? If no one Fedora-side wants to do the work, this is a problem for RHEL. The Fedora xorg team as far as I've seen only checks the core fonts code stays operational and the built-in core fonts work. Current Fedora core fonts apps exercise much more than that. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:09, Jussi Lehtola a écrit : uestions on the internet. Instead of ranting about legacy fonts that have been used for decades, you can direct your energy towards something useful: making sure that new fonts that are compatible with modern font handling systems are correctly packaged. As I've already stated, I'm ready to ask the usefulness question to FESCO. But I don't owe you doing one and not the other if you don't want to help me so the other does not interferes with my main interest. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mardi 24 novembre 2009 à 10:44 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le Mar 24 novembre 2009 17:01, Chris Adams a écrit : That's not an answer. What is the real maintenance cost? I already explained yesterday : there are rotting Fedora Core packages to merge review, packaging guidelines to write to define how they are supposed to be cleaned up, a huge pile of existing fonts to re-check for licensing, a huge pile of fonts to re-check for technical soundness (ie a lot of fonts for that area are not encoded properly or declare bad names, should it continue to be hidden via manual fonts.dir or should they be converted to something cleaner, it we continue to go the manual fonts.dir way someone needs to review existing files) etc. And how much of this is still going to be done no matter what, since core font support is not going to be dropped? You confuse core font support (=xorg code) and core fonts (= rotting font files that no one wants to maintain, and the associated fonts.dir indexes that break regularly) To keep core fonts support available anything but the built-in fonts (not the full historic xorg font suite, just the single fallback font built in xorg) can be dropped. Of course the packagers of the apps that use this stuff are going to howl, since it will reduce what their apps can do, but none of them have shown the slightest interest in contributing to the maintenance of the stuff they use so far (to keep things interesting a lot of said apps request fonts without checking they are actually available, and will crash if those fonts are not present. But that's not a core fonts support problem, that's a coding problem in those apps. They can be broken without technically removing core fonts support from Fedora). In fact one conclusion of this thread is that core fonts users are emphatically not interested in contributing to the stuff they use, and that it's better to remove the most rotten parts from Fedora, instead of keeping it, and continuing to wait for them to fix it. Like I said, this can be done without removing the xorg code Fedora is commited to maintain to keep X11 protocol compatibility. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Hi, With a little delay here are the font audit results for Fedora 12 and 2009-11-22 fedora-devel. I think I've taken into account all the feedback I received since last run. More feedback is of course welcome (except for the file size computation, I know it's broken, was not worth re-doing a 7h test run to fix it). Seeing some numbers go down would be nice. Individual packagers should have received their personalized notification some hours ago (some in duplicate, the first relay host I used blacklisted me as a spammer sometime in the middle of the run so I had to restart everything, sorry about that, will try to improve). Some people asked me why I didn't go the bugzilla route: look at the numbers, there's no way I can write a script smart enough to manage hundreds of bugs with different states. And doing it manually alone would be a nightmare. Special mention goes to jussilehtola for xine-ui: not only he managed to add 27 font files not packaged according to Fedora guidelines during the F-12 cycle, but 14 are copies of the same font. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Font audit results for Fedora 12 (final)
(sorry, this one is for devel) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFA] Font package differences between Fedora 11 and Fedora 12
B. Font package changes: = GraphicsMagick-perl.rpm (GraphicsMagick.src.rpm, ixs) ⇒ GraphicsMagick.src.rpm, ixs + ArtBrush, Medium, TrueType /usr/share/doc/GraphicsMagick-perl-1.3.7/demo/Generic.ttf − ArtBrush, Medium, TrueType /usr/share/doc/GraphicsMagick-perl-1.1.14/demo/Generic.ttf = ImageMagick-perl.rpm (ImageMagick.src.rpm, jwrdegoede) ⇒ ImageMagick.src.rpm, jwrdegoede + Tuffy, Regular, TrueType /usr/share/doc/ImageMagick-perl-6.5.4.7/demo/Generic.ttf − Tuffy, Regular, TrueType /usr/share/doc/ImageMagick-perl-6.5.1.2/demo/Generic.ttf + adf-accanthis-2-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std No2, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Bold.otf + Accanthis ADF Std No2, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-BoldItalic.otf + Accanthis ADF Std No2, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Italic.otf + Accanthis ADF Std No2, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Regular.otf + adf-accanthis-3-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std No3, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Bold.otf + Accanthis ADF Std No3, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-BoldItalic.otf + Accanthis ADF Std No3, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Italic.otf + Accanthis ADF Std No3, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Regular.otf + adf-accanthis-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Bold.otf + Accanthis ADF Std, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-BoldItalic.otf + Accanthis ADF Std, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Italic.otf + Accanthis ADF Std, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Regular.otf + adf-tribun-fonts.rpm (adf-tribun-fonts.src.rpm, nim, M) + Tribun ADF Std Cond, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondBold.ttf + Tribun ADF Std Cond, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondBoldItalic.ttf + Tribun ADF Std Cond, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondItalic.ttf + Tribun ADF Std Cond, Regular, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Cond.ttf + Tribun ADF Std Med, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedBold.ttf + Tribun ADF Std Med, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedBoldItalic.ttf + Tribun ADF Std Med, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedItalic.ttf + Tribun ADF Std Med, Medium, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Med.ttf + Tribun ADF Std, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Bold.ttf + Tribun ADF Std, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-BoldItalic.ttf + Tribun ADF Std, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Italic.ttf + Tribun ADF Std, Regular, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Regular.ttf + apa-new-athena-unicode-fonts.rpm (apa-new-athena-unicode-fonts.src.rpm, ankursinha, M) + New Athena Unicode, Regular, TrueType /usr/share/fonts/apa-new-athena-unicode/newathu.ttf = apanov-edrip-fonts.rpm (apanov-edrip-fonts.src.rpm, nim, M) ⇒ apanov-edrip-fonts.src.rpm, nim, M + Edrip, Bold Italic, TrueType /usr/share/fonts/apanov-edrip/Edrip-BoldItalic.ttf − Edrip, BoldItalic, TrueType /usr/share/fonts/apanov-edrip/Edrip-BoldItalic.ttf = apanov-heuristica-fonts.rpm (apanov-heuristica-fonts.src.rpm, nim, M) ⇒ apanov-heuristica-fonts.src.rpm, nim, M + Heuristica, Bold Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf − Heuristica, BoldItalic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf + bitmap-cjk-fonts.rpm (bitmap-fonts.src.rpm, pnemade, M) + Fangsong ti, Regular, PCF /usr/share/fonts/bitmap/fangsongti16.pcf + Fangsong ti, Regular, PCF /usr/share/fonts/bitmap/fangsongti24.pcf = bitmap-fonts.rpm (bitmap-fonts.src.rpm, pnemade) ⇒ bitmap-fonts.src.rpm, pnemade, M + Console, Regular, PCF /usr/share/fonts/bitmap/console8x16.pcf − Console, Regular, PCF /usr/share/fonts/bitmap-fonts/console8x16.pcf + Fixed, Regular, PCF /usr/share/fonts/bitmap/console9x15.pcf − Fixed, Regular, PCF /usr/share/fonts/bitmap-fonts/console9x15.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS08.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS10.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS12.pcf + LucidaTypewriter, Sans, PCF
[RFA] Font test result differences between Fedora 11 and Fedora 12
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 1‧‧ ‧ ‧ ‧ ‧‧ 5‧‧‧‧‧‧‧ ‧‧‧ 2‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 3‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 41‧ 1 ‧ ‧ 1‧ ‧‧‧-2 1‧11 ‧11 5‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 6‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧11 7‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 8‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 9‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 10 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧2‧‧‧ ‧2‧ 11 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 12 ‧‧ ‧ -1 ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 13 -5 ‧ -5 ‧ ‧ -5 ‧ -1 -5 ‧‧-5 ‧-5 -5 -4 -5 -5 14 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 15 ‧‧ ‧ ‧ ‧ ‧‧ ‧4‧‧‧‧44 ‧3‧ 16 -1 ‧ -1 ‧ ‧ ‧‧ ‧‧‧1-1 ‧-1 -1 ‧-1 ‧ 17 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 18 -1 ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 19 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 20 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 21 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧-1 ‧‧‧ ‧‧-4 22 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 23 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 24 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 25 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 26 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 27 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ 1‧‧ 28 ‧‧ ‧ ‧ ‧ ‧‧ ‧2‧‧‧‧‧‧ ‧2‧ 29 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 30 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 31 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 32 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧1 33 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 34 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 35 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 36 ‧‧ ‧ ‧ ‧ -4 ‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 37 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 38 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 39 ‧‧ 27 ‧ ‧ ‧7 27 27 ‧‧27 20 27 27 ‧27 ‧ 40 1‧ 1 ‧ ‧ 1‧ 1‧‧‧‧‧11 11‧ 41 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 42 -2 -1 -2 ‧ ‧ -1 ‧ ‧‧‧‧-2 -2 -2 -2 ‧-2 -2 43 ‧1 ‧ ‧ ‧ 1‧ ‧‧‧‧22‧‧ ‧2‧ 44 ‧‧ 1 ‧ ‧ ‧‧ ‧‧‧‧1‧11 ‧1‧ 45 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 46 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ -2 -2 ‧ 47 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ 22‧ 48 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ ‧‧‧ 49 ‧‧ ‧ ‧ ‧ ‧‧ -15 ‧‧‧‧‧‧‧ ‧‧‧ 50 ‧‧ ‧ ‧ -3 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 51 ‧‧ ‧ ‧ 2 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 52 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4‧ 53 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4
[RFA] Font test result differences between Fedora 12 and 2009-11-22 devel
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 1‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 2‧ ‧ ‧ ‧ ‧ ‧ ‧ -10 ‧ ‧‧‧‧‧ 35 ‧ 5 ‧ 5 1 5 ‧5 55455 4‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 5‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 6‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 75 -1 -1 ‧ 1 ‧ -1 ‧-1 -1 -1 ‧-1 -6 8‧ ‧ ‧ ‧ 4 ‧ ‧ ‧‧ ‧‧‧‧‧ 9‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 10 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 11 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧-1 ‧‧‧‧‧ 12 ‧ ‧ ‧ ‧ -1 ‧ ‧ ‧‧ ‧‧‧‧‧ 13 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧11‧ 14 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 15 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 16 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 17 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 18 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧1‧ 19 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧4 ‧‧‧4‧ 20 -1 ‧ -1 ‧ -1 ‧ ‧ ‧-1 ‧-1 ‧-1 ‧ 21 ‧ ‧ ‧ ‧ 1 1 ‧ ‧‧ ‧‧‧‧‧ 22 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 23 ‧ ‧ ‧ ‧ ‧ ‧ ‧ -2 ‧ ‧‧‧‧‧ 24 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧25 25 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧‧‧ 26 ‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 27 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 28 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 29 ‧ 2 2 ‧ 1 ‧ 2 ‧2 2212‧ 30 ‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 31 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1 Balance 9 1 5 2 12 2 6 -12 15 65818 25 P# Maintainer RPM SRPM 1 adsllc drehatlas-xaporho-fonts drehatlas-xaporho-fonts 2 akahlphp-ZendFramework php-ZendFramework-tests 3 awjb koffice koffice-core 4 chkr xskat xskat 5 dougslandzbar zbar 6 hedayat rcssmonitor rcssmonitor 7 icon python-reportlab python-reportlab 8 jnovytexlive-texmf texlive-texmf-fonts 9 lyosnorezel darkgarden-fonts darkgarden-fonts 10 nbecker libotflibotf 11 nim apanov-heuristica-fonts apanov-heuristica-fonts 12 nim dejavu-fonts dejavu-sans-fonts 13 ozamosi gdouros-aegean-fonts gdouros-aegean-fonts 14 ozamosi gdouros-aegyptus-fontsgdouros-aegyptus-fonts 15 ozamosi gdouros-akkadian-fontsgdouros-akkadian-fonts 16 ozamosi gdouros-alexander-fonts gdouros-alexander-fonts 17 ozamosi gdouros-analecta-fontsgdouros-analecta-fonts 18 ozamosi gdouros-musica-fonts gdouros-musica-fonts 19 ozamosi msimonson-anonymouspro-fonts msimonson-anonymouspro-fonts 20 phuang scim scim-doc 21 rdieter lyx lyx-cmex10-fonts 22 roma xpaintxpaint 23 s4504kr stellariumstellarium 24 stevetuxpaint tuxpaint 25 tagohsazanami-fontssazanami-gothic-fonts 26 tagohvlgothic-fontsvlgothic-fonts 27 tk009ns-bola-fonts ns-bola-fonts 28 tk009ns-tiza-chalk-fonts ns-tiza-chalk-fonts 29 wart wormuxwormux-data 30 xgl-maintxorg-x11-apps xorg-x11-apps 31 xulchris pygamepygame t1. Error: fonts in arch packages t2. Warning: bad font naming t3. Warning: fonts in packages that do not respect font naming conventions t4. Warning: core fonts use t5. Error: font faces duplicated by different packages t6. Error: exact font duplication t7. Error: packages that mix different font families t8. Warning: font linking t9. Warning: fonts that do not pass fontlint sanity checks t10. Error: fonts in packages that contain non-font data t11. Error: fonts deployed outside /usr/share/fonts t12. Suggestion: fonts with partial unicode block coverage t13. Suggestion: fonts with partial script coverage t14. Error: rpmlint signature.asc Description: Ceci est une partie de message
[RFA] Font package differences between Fedora 12 and 2009-11-22 Fedora devel
B. Font package changes: = apanov-heuristica-fonts.rpm (apanov-heuristica-fonts.src.rpm, nim, M) ⇒ apanov-heuristica-fonts.src.rpm, nim, M − Heuristica, Bold, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Bold.otf + Heuristica, Bold, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Bold.ttf − Heuristica, Bold Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf + Heuristica, Bold Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.ttf − Heuristica, Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Italic.otf + Heuristica, Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Italic.ttf − Heuristica, Regular, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Regular.otf + Heuristica, Regular, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Regular.ttf + drehatlas-xaporho-fonts.rpm (drehatlas-xaporho-fonts.src.rpm, adsllc, M) + Xaporho, Regular, CFF /usr/share/fonts/drehatlas-xaporho/Xaporho.otf + gdouros-aegean-fonts.rpm (gdouros-aegean-fonts.src.rpm, ozamosi, M) + Aegean, Regular, TrueType /usr/share/fonts/gdouros-aegean/Aegean.otf + gdouros-aegyptus-fonts.rpm (gdouros-aegyptus-fonts.src.rpm, ozamosi, M) + Aegyptus, Regular, TrueType /usr/share/fonts/gdouros-aegyptus/Aegyptus.otf + gdouros-akkadian-fonts.rpm (gdouros-akkadian-fonts.src.rpm, ozamosi, M) + Akkadian, Regular, TrueType /usr/share/fonts/gdouros-akkadian/Akkadian.otf + gdouros-alexander-fonts.rpm (gdouros-alexander-fonts.src.rpm, ozamosi, M) + Alexander, Regular, TrueType /usr/share/fonts/gdouros-alexander/Alexander.otf + gdouros-analecta-fonts.rpm (gdouros-analecta-fonts.src.rpm, ozamosi, M) + Analecta, Regular, TrueType /usr/share/fonts/gdouros-analecta/Analecta.otf + gdouros-musica-fonts.rpm (gdouros-musica-fonts.src.rpm, ozamosi, M) + Musica, Regular, TrueType /usr/share/fonts/gdouros-musica/Musica.otf + koffice-core.rpm (koffice.src.rpm, awjb) + Arev Sans, Bold, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBd.ttf + Arev Sans, Bold Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBI.ttf + Arev Sans, Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevIt.ttf + Arev Sans, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/Arev.ttf + cmex10, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/cmex10.ttf + msimonson-anonymouspro-fonts.rpm (msimonson-anonymouspro-fonts.src.rpm, ozamosi, M) + Anonymous Pro, Bold, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro B.ttf + Anonymous Pro, Bold Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro BI.ttf + Anonymous Pro, Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro I.ttf + Anonymous Pro, Regular, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro.ttf + ns-bola-fonts.rpm (ns-bola-fonts.src.rpm, tk009, M) + Bola, Regular, TrueType /usr/share/fonts/ns-bola/bola.ttf + ns-tiza-chalk-fonts.rpm (ns-tiza-chalk-fonts.src.rpm, tk009, M) + Tiza, Regular, TrueType /usr/share/fonts/ns-tiza-chalk/tiza_chalk.ttf = python-reportlab.rpm (python-reportlab.src.rpm, icon) ⇒ python-reportlab.src.rpm, icon + Bitstream Vera Sans, Bold, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBd.ttf − Bitstream Vera Sans, Bold, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBd.ttf + Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBI.ttf − Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBI.ttf + Bitstream Vera Sans, Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraIt.ttf − Bitstream Vera Sans, Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraIt.ttf + Bitstream Vera Sans, Roman, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/Vera.ttf − Bitstream Vera Sans, Roman, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/Vera.ttf + Dark Garden, Regular, Type 1 /usr/lib64/python2.6/site-packages/reportlab/fonts/DarkGardenMK.pfb − LettErrorRobot, Chrome, Type 1 /usr/lib/python2.6/site-packages/reportlab/fonts/LeERC___.PFB − Rina, Regular, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/rina.ttf — scim-doc.rpm (scim.src.rpm , phuang) − FreeSans, Medium, TrueType /usr/share/doc/scim-doc-1.4.9/html/FreeSans.ttf = tuxpaint.rpm (tuxpaint.src.rpm, steve) ⇒ tuxpaint.src.rpm, steve + DejaVu Sans, Book, TrueType /usr/share/tuxpaint/fonts/default_font.ttf − DejaVu Sans, Condensed, TrueType /usr/share/tuxpaint/fonts/default_font.ttf + SubsetForTuxPaint, , TrueType /usr/share/tuxpaint/fonts/locale/zh_TW.ttf −
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package 2) There is no way to make me stop nagging you. This is true I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. This won't make the problem go away. You may not care about it, but as long as I'll continue to find users pleas for help because of crappy core font use whenever I enter fedora fonts in Google, I'll continue to care. Stop the Internet from filling with those and I'll stop the mails. (see, I can be unreasonable too) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:44 -0500, Orcan Ogetbil a écrit : On Mon, Nov 23, 2009 at 11:54 AM, Dominik 'Rathann' Mierzejewski wrote: On Monday, 23 November 2009 at 17:51, Jerry James wrote: [...] I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. +1. Nicholas, I know you love to write scripts that send mass emails, but don't you think this is too much? FYI I hate it. Only did it because I found no other way to move things forward. Feel free to propose and implement a better way so I can stop mine. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your gnu-free-fonts package did not pass QA
Le lundi 23 novembre 2009 à 11:06 -0600, Jon Ciesla a écrit : I understand some of the others, but, Nicholas, did we not just finish converting this from freefont to gnu-free-fonts and bringing it into compliance with the guidelines in time for F-11? Well, in fact the test 5 you listed here is a direct consequence of not splitting biolinum in a sub-package as demanded by last year's guidelines. The rest is mostly stuff that needs relaying upstream (because most long font creators do not have the resources to detect those problems themselves, for example a lot of them do not run Linux at all so if their font does not play well with fontconfig they'll only find it out if their friendly Fedora packager tells them so) It is even clearly marked in the message this is stuff that needs upstream handling. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Le lundi 23 novembre 2009 à 12:54 -0600, Jon Ciesla a écrit : I question the taste of this remark. Was it really necessary to bring this up in such a public forum? I guess this just reflect frustration in seing xine-ui adding new copies of the same fonts months after months even though it is explicitely demanded not to in packaging guidelines and it was pointed multiple times whenever the script result were posted to this list this past year. You're right I should not have posted it this way. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Font audit results for Fedora 12 (final)
Le lundi 23 novembre 2009 à 13:43 -0500, Neal Becker a écrit : What does this mean? I received one for libotf. Neither libotf, nor libotf-devel seem to ship any fonts. As explained in the text of the message you're received libotf attempts to access fonts through the core fonts backend which is bad -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:48 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? The infra no, the fonts (or at least part of them) yes Then why the hate for legacy packages using a legacy interface? The interface is legacy because it didn't work well, and we do not have users sophisticated enough to undestand their font problems are caused by their wandering in the legacy minefield land some packagers recklessly expose. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:09 -0800, Toshio Kuratomi a écrit : As notting reminded me yesterday, we do not keep software out of Fedora solely because it is crap. So, although it would be nice to port code that uses core fonts to use fontconfig, it could be counter productive to list them along with other problems discovered in font packages that we can and should fix at the packaging level. You run the risk of getting the script/email that's making these updates ignored even when it's reporting genuine, fixable problems. I'll do the same offer I made a few years ago. Any of those who package bits that use core fonts step up to write packaging guidelines for core fonts, to do the merge reviews on the associated packages, and generally speaking to become the core fonts guy (or gal) in Fedora, can ask me to whitelist all the core font packages he wants or even to shut down this test completely. If no one is ready to do that, and is happy to continue to have me do this part because its fonts and by default the fonts sig does fonts, should be happy it costs him only a few annoying mails that state I don't like it one bit. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:13 -0800, Adam Williamson a écrit : On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. I don't assume they have the capability to fix code problems. I assume they're ready to do their maintainer work and nag upstream till it does. Or are ready to drop the package if it costs them more than it's worth. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Hi, With a little delay here are the font audit results for Fedora 12 and 2009-11-22 fedora-devel. I think I've taken into account all the feedback I received since last run. More feedback is of course welcome (except for the file size computation, I know it's broken, was not worth re-doing a 7h test run to fix it). Seeing some numbers go down would be nice. Individual packagers should have received their personalized notification some hours ago (some in duplicate, the first relay host I used blacklisted me as a spammer sometime in the middle of the run so I had to restart everything, sorry about that, will try to improve). Some people asked me why I didn't go the bugzilla route: look at the numbers, there's no way I can write a script smart enough to manage hundreds of bugs with different states. And doing it manually alone would be a nightmare. Special mention goes to jussilehtola for xine-ui: not only he managed to add 27 font files not packaged according to Fedora guidelines during the F-12 cycle, but 14 are copies of the same font. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [RFA] Font audit results for Fedora 12 (final)
(sorry, this one is for devel) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
[RFA] Font test result differences between Fedora 11 and Fedora 12
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 1‧‧ ‧ ‧ ‧ ‧‧ 5‧‧‧‧‧‧‧ ‧‧‧ 2‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 3‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 41‧ 1 ‧ ‧ 1‧ ‧‧‧-2 1‧11 ‧11 5‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 6‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧11 7‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 8‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 9‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 10 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧2‧‧‧ ‧2‧ 11 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 12 ‧‧ ‧ -1 ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 13 -5 ‧ -5 ‧ ‧ -5 ‧ -1 -5 ‧‧-5 ‧-5 -5 -4 -5 -5 14 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 15 ‧‧ ‧ ‧ ‧ ‧‧ ‧4‧‧‧‧44 ‧3‧ 16 -1 ‧ -1 ‧ ‧ ‧‧ ‧‧‧1-1 ‧-1 -1 ‧-1 ‧ 17 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 18 -1 ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 19 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 20 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 21 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧-1 ‧‧‧ ‧‧-4 22 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 23 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 24 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 25 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 26 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 27 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ 1‧‧ 28 ‧‧ ‧ ‧ ‧ ‧‧ ‧2‧‧‧‧‧‧ ‧2‧ 29 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 30 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 31 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 32 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧1 33 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 34 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 35 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 36 ‧‧ ‧ ‧ ‧ -4 ‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 37 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 38 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 39 ‧‧ 27 ‧ ‧ ‧7 27 27 ‧‧27 20 27 27 ‧27 ‧ 40 1‧ 1 ‧ ‧ 1‧ 1‧‧‧‧‧11 11‧ 41 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 42 -2 -1 -2 ‧ ‧ -1 ‧ ‧‧‧‧-2 -2 -2 -2 ‧-2 -2 43 ‧1 ‧ ‧ ‧ 1‧ ‧‧‧‧22‧‧ ‧2‧ 44 ‧‧ 1 ‧ ‧ ‧‧ ‧‧‧‧1‧11 ‧1‧ 45 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 46 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ -2 -2 ‧ 47 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ 22‧ 48 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ ‧‧‧ 49 ‧‧ ‧ ‧ ‧ ‧‧ -15 ‧‧‧‧‧‧‧ ‧‧‧ 50 ‧‧ ‧ ‧ -3 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 51 ‧‧ ‧ ‧ 2 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 52 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4‧ 53 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4
[RFA] Font test result differences between Fedora 12 and 2009-11-22 devel
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 1‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 2‧ ‧ ‧ ‧ ‧ ‧ ‧ -10 ‧ ‧‧‧‧‧ 35 ‧ 5 ‧ 5 1 5 ‧5 55455 4‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 5‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 6‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 75 -1 -1 ‧ 1 ‧ -1 ‧-1 -1 -1 ‧-1 -6 8‧ ‧ ‧ ‧ 4 ‧ ‧ ‧‧ ‧‧‧‧‧ 9‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 10 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 11 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧-1 ‧‧‧‧‧ 12 ‧ ‧ ‧ ‧ -1 ‧ ‧ ‧‧ ‧‧‧‧‧ 13 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧11‧ 14 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 15 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 16 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 17 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 18 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧1‧ 19 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧4 ‧‧‧4‧ 20 -1 ‧ -1 ‧ -1 ‧ ‧ ‧-1 ‧-1 ‧-1 ‧ 21 ‧ ‧ ‧ ‧ 1 1 ‧ ‧‧ ‧‧‧‧‧ 22 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 23 ‧ ‧ ‧ ‧ ‧ ‧ ‧ -2 ‧ ‧‧‧‧‧ 24 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧25 25 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧‧‧ 26 ‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 27 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 28 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 29 ‧ 2 2 ‧ 1 ‧ 2 ‧2 2212‧ 30 ‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 31 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1 Balance 9 1 5 2 12 2 6 -12 15 65818 25 P# Maintainer RPM SRPM 1 adsllc drehatlas-xaporho-fonts drehatlas-xaporho-fonts 2 akahlphp-ZendFramework php-ZendFramework-tests 3 awjb koffice koffice-core 4 chkr xskat xskat 5 dougslandzbar zbar 6 hedayat rcssmonitor rcssmonitor 7 icon python-reportlab python-reportlab 8 jnovytexlive-texmf texlive-texmf-fonts 9 lyosnorezel darkgarden-fonts darkgarden-fonts 10 nbecker libotflibotf 11 nim apanov-heuristica-fonts apanov-heuristica-fonts 12 nim dejavu-fonts dejavu-sans-fonts 13 ozamosi gdouros-aegean-fonts gdouros-aegean-fonts 14 ozamosi gdouros-aegyptus-fontsgdouros-aegyptus-fonts 15 ozamosi gdouros-akkadian-fontsgdouros-akkadian-fonts 16 ozamosi gdouros-alexander-fonts gdouros-alexander-fonts 17 ozamosi gdouros-analecta-fontsgdouros-analecta-fonts 18 ozamosi gdouros-musica-fonts gdouros-musica-fonts 19 ozamosi msimonson-anonymouspro-fonts msimonson-anonymouspro-fonts 20 phuang scim scim-doc 21 rdieter lyx lyx-cmex10-fonts 22 roma xpaintxpaint 23 s4504kr stellariumstellarium 24 stevetuxpaint tuxpaint 25 tagohsazanami-fontssazanami-gothic-fonts 26 tagohvlgothic-fontsvlgothic-fonts 27 tk009ns-bola-fonts ns-bola-fonts 28 tk009ns-tiza-chalk-fonts ns-tiza-chalk-fonts 29 wart wormuxwormux-data 30 xgl-maintxorg-x11-apps xorg-x11-apps 31 xulchris pygamepygame t1. Error: fonts in arch packages t2. Warning: bad font naming t3. Warning: fonts in packages that do not respect font naming conventions t4. Warning: core fonts use t5. Error: font faces duplicated by different packages t6. Error: exact font duplication t7. Error: packages that mix different font families t8. Warning: font linking t9. Warning: fonts that do not pass fontlint sanity checks t10. Error: fonts in packages that contain non-font data t11. Error: fonts deployed outside /usr/share/fonts t12. Suggestion: fonts with partial unicode block coverage t13. Suggestion: fonts with partial script coverage t14. Error: rpmlint signature.asc Description: Ceci est une partie de message
[RFA] Font package differences between Fedora 12 and 2009-11-22 Fedora devel
B. Font package changes: = apanov-heuristica-fonts.rpm (apanov-heuristica-fonts.src.rpm, nim, M) ⇒ apanov-heuristica-fonts.src.rpm, nim, M − Heuristica, Bold, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Bold.otf + Heuristica, Bold, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Bold.ttf − Heuristica, Bold Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf + Heuristica, Bold Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.ttf − Heuristica, Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Italic.otf + Heuristica, Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Italic.ttf − Heuristica, Regular, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Regular.otf + Heuristica, Regular, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Regular.ttf + drehatlas-xaporho-fonts.rpm (drehatlas-xaporho-fonts.src.rpm, adsllc, M) + Xaporho, Regular, CFF /usr/share/fonts/drehatlas-xaporho/Xaporho.otf + gdouros-aegean-fonts.rpm (gdouros-aegean-fonts.src.rpm, ozamosi, M) + Aegean, Regular, TrueType /usr/share/fonts/gdouros-aegean/Aegean.otf + gdouros-aegyptus-fonts.rpm (gdouros-aegyptus-fonts.src.rpm, ozamosi, M) + Aegyptus, Regular, TrueType /usr/share/fonts/gdouros-aegyptus/Aegyptus.otf + gdouros-akkadian-fonts.rpm (gdouros-akkadian-fonts.src.rpm, ozamosi, M) + Akkadian, Regular, TrueType /usr/share/fonts/gdouros-akkadian/Akkadian.otf + gdouros-alexander-fonts.rpm (gdouros-alexander-fonts.src.rpm, ozamosi, M) + Alexander, Regular, TrueType /usr/share/fonts/gdouros-alexander/Alexander.otf + gdouros-analecta-fonts.rpm (gdouros-analecta-fonts.src.rpm, ozamosi, M) + Analecta, Regular, TrueType /usr/share/fonts/gdouros-analecta/Analecta.otf + gdouros-musica-fonts.rpm (gdouros-musica-fonts.src.rpm, ozamosi, M) + Musica, Regular, TrueType /usr/share/fonts/gdouros-musica/Musica.otf + koffice-core.rpm (koffice.src.rpm, awjb) + Arev Sans, Bold, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBd.ttf + Arev Sans, Bold Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBI.ttf + Arev Sans, Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevIt.ttf + Arev Sans, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/Arev.ttf + cmex10, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/cmex10.ttf + msimonson-anonymouspro-fonts.rpm (msimonson-anonymouspro-fonts.src.rpm, ozamosi, M) + Anonymous Pro, Bold, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro B.ttf + Anonymous Pro, Bold Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro BI.ttf + Anonymous Pro, Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro I.ttf + Anonymous Pro, Regular, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro.ttf + ns-bola-fonts.rpm (ns-bola-fonts.src.rpm, tk009, M) + Bola, Regular, TrueType /usr/share/fonts/ns-bola/bola.ttf + ns-tiza-chalk-fonts.rpm (ns-tiza-chalk-fonts.src.rpm, tk009, M) + Tiza, Regular, TrueType /usr/share/fonts/ns-tiza-chalk/tiza_chalk.ttf = python-reportlab.rpm (python-reportlab.src.rpm, icon) ⇒ python-reportlab.src.rpm, icon + Bitstream Vera Sans, Bold, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBd.ttf − Bitstream Vera Sans, Bold, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBd.ttf + Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBI.ttf − Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBI.ttf + Bitstream Vera Sans, Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraIt.ttf − Bitstream Vera Sans, Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraIt.ttf + Bitstream Vera Sans, Roman, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/Vera.ttf − Bitstream Vera Sans, Roman, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/Vera.ttf + Dark Garden, Regular, Type 1 /usr/lib64/python2.6/site-packages/reportlab/fonts/DarkGardenMK.pfb − LettErrorRobot, Chrome, Type 1 /usr/lib/python2.6/site-packages/reportlab/fonts/LeERC___.PFB − Rina, Regular, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/rina.ttf — scim-doc.rpm (scim.src.rpm , phuang) − FreeSans, Medium, TrueType /usr/share/doc/scim-doc-1.4.9/html/FreeSans.ttf = tuxpaint.rpm (tuxpaint.src.rpm, steve) ⇒ tuxpaint.src.rpm, steve + DejaVu Sans, Book, TrueType /usr/share/tuxpaint/fonts/default_font.ttf − DejaVu Sans, Condensed, TrueType /usr/share/tuxpaint/fonts/default_font.ttf + SubsetForTuxPaint, , TrueType /usr/share/tuxpaint/fonts/locale/zh_TW.ttf −
Re: [RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Le lundi 23 novembre 2009 à 12:54 -0600, Jon Ciesla a écrit : I question the taste of this remark. Was it really necessary to bring this up in such a public forum? I guess this just reflect frustration in seing xine-ui adding new copies of the same fonts months after months even though it is explicitely demanded not to in packaging guidelines and it was pointed multiple times whenever the script result were posted to this list this past year. You're right I should not have posted it this way. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [RFA] Font audit results for Fedora 12 (final)
Le lundi 23 novembre 2009 à 13:43 -0500, Neal Becker a écrit : What does this mean? I received one for libotf. Neither libotf, nor libotf-devel seem to ship any fonts. As explained in the text of the message you're received libotf attempts to access fonts through the core fonts backend which is bad -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Local users get to play root?
Le mercredi 18 novembre 2009 à 19:23 -0500, Bill Nottingham a écrit : Out of the box, a desktop user has the ability to shut down the machine. Well, not really anymore. If you try to press the power button now you won't get a nice software shutdown as before but an evil do you really want to do what you've just asked me to do popup Really useful when X is wedged and you can't close the damn popup. You are safe! Anyone can install anything without password, but the power button has been disabled! -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tcpdf fonts
Le Dim 15 novembre 2009 01:14, Oron Peled a écrit : Hi, I packaged TCEXAM (tcexam.org) for review: https://bugzilla.redhat.com/show_bug.cgi?id=465159 One of the issues I (and the reviewer) have is that the included TCPDF (tcpdf.org) application is using embedded fonts for rendering the PDF. This is not good at all :( As a result, I have several questions for the members of this list: 1. From a brief look, it seems the bundled fonts are free and included in Fedora. How about the almohanad and ZarBold, anybody knows? No idea 2. Better substitutes? Defaults? Usually, using the system defaults as computed by fontconfig works best (however it is worth locating the upstream of the missing fonts and packaging them if their licensing is fedora-compatible) 3. For use by tcpdf, the fonts are converted as described in: http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcpdf_fonts a. One tools which is bundled is afm2pfm (and its inverse pfm2afm): * The upstream of these tools: - http://www.ctan.org/tex-archive/fonts/utilities/pfm2afm/ b. Another bundled tool is ttf2ufm: * Looks like a modified copy of ttf2pt1 which is packaged in Fedora. You should not ask yourself how to generate afm files from ttf fonts but how to use system ttf fonts directly. AFM/PFM/PFB/PFA are legacy formats and you can't convert reliably ttf/otf/otf fonts to them (for one, they don't have the same glyph number limits, and fonts like DejaVu Sans or Free Sans are way over PS limits). Granted, adapting the pdf engine to use modern fonts (or finding a replacement) is likely to be less trivial than butchering fonts, but the current hack will cause you no end of problems and I suspect a solution would help clean up bad code in many projects. IIRC cairo had some pdf capabilities, the poppler people or Behdad could probably tell you more. 4. While doing a search for this mail I found that moodle (packaged in Fedora) bundles TCPDF (and the fonts). So it seems we have a common problem... Yes, moodle is no good :( Should not have passed review at all. If you choose to keep a conversion step, please make sure you convert from fonts packaged in Fedora (exact version in Fedora that passed legal review), and that you re-convert each time the Fedora version changes (either by converting dynamically or by pegging in deps the exact font package version you used in build) Regards, -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Broken dependencies script at it again
Le samedi 14 novembre 2009 à 16:12 +, Paul Howarth a écrit : Please make it stop. milter-regex-1.7-6.fc12.ppc requires /bin/sh I guess this is happening because of dropping ppc/ppc64 as primary arches? I think pretty much everyone will be mailbombed this way. Seems /bin/sh was dropped from provides, but the packages have not been rebuilt not to require it -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 21:25 -0600, Chris Adams a écrit : Xaw and core fonts are not something new programs should use, but they still work. Are they really a significant maintenance issue? Core fonts are an issue for anyone working on X or Linux fonts. You may think this year's big X11 news was driver changes or render magic, but for many people it was that emacs finally released an official stable version that didn't use them (even though they kept the old path as fallback, probably because they don't trust 100% their new code) Every single legacy xorg font package fails validation, because many fonts of this era have incomplete metadata (you could cheat and put the info manually in fonts.dir and no one was the wiser, except people who ran mkfontdir and got garbage indexes as output). I doubt we'll find people willing to fix them. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 09:55 +0100, Andreas Schwab a écrit : I don't understand. Emacs uses the fallback for example to display characters from the Korean KSC charset, in my case using -daewoo-minco-medium-*-ksc5601.1987-0 fonts. What's the approved way to do that? You do it like everyone else. You pass the codepoints to fontconfig (possibly, after unicode conversion) and let it find Korean fonts available in the distro (there are many, and daewoo minco medium would appear in the list if it was packaged properly). How do you think Firefox displays Korean pages ? It does not use core fonts. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 10:55 +0100, Andreas Schwab a écrit : Nicolas Mailhot nicolas.mail...@laposte.net writes: You do it like everyone else. You pass the codepoints to fontconfig Emacs does that already AFAIK. Then it has no actual need to the fallback path. It's probably only there because emacs people were not 100% confident on the new fontconfig code they wrote. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 11:09 +0100, Patrice Dumas a écrit : On Fri, Nov 13, 2009 at 11:06:45AM +0100, Nicolas Mailhot wrote: Le vendredi 13 novembre 2009 à 10:55 +0100, Andreas Schwab a écrit : Nicolas Mailhot nicolas.mail...@laposte.net writes: You do it like everyone else. You pass the codepoints to fontconfig Emacs does that already AFAIK. Then it has no actual need to the fallback path. It's probably only there because emacs people were not 100% confident on the new fontconfig code they wrote. There is also a portability issue. Maybe emacs is also meant to work on old unices that don't use fontconfig. Well in that case you do not include the code for old unices in the version built for modern unices such as Fedora -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 17:42 +0100, Nicolas Mailhot a écrit : Here is a new filtered list, based on the suggestions I've received since my first posting. Please tell me if there is still some files that should not belong here, and why I should have written that the test used in this version is repoquery --whatrequires 'libX11.so*' … grep -i -e ^./sbin/ \ -e ^./usr/sbin/ \ -e ^./usr/kerberos/sbin \ -e ^./bin/ \ -e ^./usr/bin/ \ -e ^./usr/kerberos/bin/ \ -e ^./lib.*/ \ -e ^./usr/lib.*/ \ -e ^./opt/ \ -e ^./usr/X11R6/ \ -e ^./usr/games/ \ -e ^./usr/local/ \ | grep -vi -e ^./usr/bin/dmxwininfo \ -e ^./usr/bin/Xdmx \ -e ^./usr/bin/xfontsel \ -e ^./usr/bin/xlsfonts \ -e ^./usr/bin/Xnest \ -e ^./usr/bin/xprop \ -e ^./usr/bin/xsetroot \ -e ^./usr/bin/xwininfo \ -e ^./usr/bin/x11vnc \ -e ^./usr/bin/x2vnc \ -e ^./usr/lib.*/libXcursor.so … [ $(nm -aDu $file 2 /dev/null | grep -q '\XLoad.*Font') ] \ echo FAIL -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 18:01 +, Jonathan Underwood a écrit : 2009/11/13 Nicolas Mailhot nicolas.mail...@laposte.net: • xdvik-0:22.84.14-7.fc12 — /usr/bin/pxdvi-xaw3d — /usr/bin/xdvi-xaw3d A more crusty piece of code than xdvi you never did see. It's very much in bugfix only mode upstream, so I very much doubt upstream, such as it is, will be moving to a modern tool kit and using fontconfig. I don't think it'd be a useful expenditure of time in any case. A better expenditure of time would be to work out what (if any) functionality is missing in evince-dvi which prevents us from dropping xdvi altogether. As long as the bit using Core fonts is no longer in the repo, I'll be happy :p -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le vendredi 13 novembre 2009 à 21:08 +0200, Ville Skyttä a écrit : On Friday 13 November 2009, Nicolas Mailhot wrote: Le vendredi 13 novembre 2009 à 11:58 +, Richard W.M. Jones a écrit : Nicolas, if possible next time please give the package maintainer (ie. FAS username) next to each package in the list. Otherwise it's harder to tell which packages I should look at. Last time I asked how to do this the answer was just rewrite your script in python. Since I have other things to do, it won't happen. Check out /usr/bin/fedoradev-pkgowners in the fedora-packager package. Oh, here goes my reason not to do it. Thanks for the tip! -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 13:08 +0200, Gilboa Davara a écrit : On Thu, 2009-11-12 at 07:42 +0100, Nicolas Mailhot wrote: Le jeudi 12 novembre 2009 à 06:51 +0200, Gilboa Davara a écrit : I own both icewm and idesk. As far as I know, both icewm and idesk are linked against xft and should not default to core fonts. (Unless I completely misunderstanding something...) I've been asked to filter out xft matches next run, so if they *only* do xft they won't appear again. Thanks. However please note that even though using xft is less bad than using core fonts, xft alone is still not a complete text stack. For robust text support nothing less than fontconfig and a shaper such as the one in qt, pango or pango-cairo will work -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 14:59 +0100, Andreas Schwab a écrit : Nicolas Mailhot nicolas.mail...@laposte.net writes: Therefore, I'd like to identify remaining core font users, and remind them periodically their core font use is not good for their users or for Fedora. What's wrong with proving support for core fonts as a fallback? That's what Emacs is doing, for example. The problem here is your fallback is going to be less robust than your primary path. Also it is not needed at all. Every single major GUI app uses the new (in 2003 sense of new) font backend, so if it fails you're not going to fallback individual apps you're going to switch to the console to fix the system. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 20:34 +0100, Nicolas Mailhot a écrit : However please note that even though using xft is less bad than using core fonts, xft alone is still not a complete text stack. (I should have written, using xft directly. xft2 uses fontconfig but direct xft2 access bypasses the shaper layer. The shaper is needed for the complex glyph positioning required by some asian languages, and for the typographic features integrated in smart fonts, including latin ones) For robust text support nothing less than fontconfig and a shaper such as the one in qt, pango or pango-cairo will work -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 17:38 +, Richard W.M. Jones a écrit : On Thu, Nov 12, 2009 at 01:49:34PM +, Richard W.M. Jones wrote: Behdad's advice to me was to use Xft to replace raw X*Font calls in the example I gave: http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171view=markup This is the patch I submitted upstream: http://annexia.org/tmp/0001-Graphics-Use-modern-X-fonts-instead-of-X-core-fonts-2.patch.txt That was wonderfully reactive. Thanks! I should have posted the list earlier :p -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 22:47 +0100, Patrice Dumas a écrit : Hi, Cernlib is already legacy, so it wouldn't be so bad that the graphical stuff in cernlib doesn't work. Also it is not clear that it uses that much directly X, but rather goes through Motif. Maybe Xm* symbols should not be taken into account? Going through Motif or another widget lib does not change the problem. Apps will be affected the same whether they access Core fonts directly or through a proxy. In fact the next step is probably to identify such indirect users (the current check caught Motif apps, but gtk1 have the same problem). Deciding if the app has a future of if it's ok it fails is a judgment call I refuse to hardwire in the checker. Packagers will receive notifications and decide what they do with them alone. (however that *also* means someone who decided to keep a core client in Fedora after being notified of the risks gets to explain the breakage if some user complains it works less and less well) • wmctrl wmctrl-0:1.07-7.fc12 — /usr/bin/wmctrl This is a use of XCreateFontCursor. Is it really in the scope? Yes, this was already on the list of things not to warn about. Sorry about not posting about it. I wanted to do a full repo check before reporting again, but due to the number of packages checked it takes a long time (hours) to run and I have to rewind every time I find a bug in the script. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Identifying remaining core font users
/xscreensaver/wormhole — /usr/libexec/xscreensaver/xanalogtv — /usr/libexec/xscreensaver/xflame — /usr/libexec/xscreensaver/xjack — /usr/libexec/xscreensaver/xlyap — /usr/libexec/xscreensaver/xmatrix — /usr/libexec/xscreensaver/xrayswarm — /usr/libexec/xscreensaver/xspirograph — /usr/libexec/xscreensaver/zoom • xscreensaver xscreensaver-gl-extras-1:5.10-2.fc12 — /usr/libexec/xscreensaver/antinspect — /usr/libexec/xscreensaver/antmaze — /usr/libexec/xscreensaver/antspotlight — /usr/libexec/xscreensaver/atlantis — /usr/libexec/xscreensaver/atunnel — /usr/libexec/xscreensaver/blinkbox — /usr/libexec/xscreensaver/blocktube — /usr/libexec/xscreensaver/boing — /usr/libexec/xscreensaver/bouncingcow — /usr/libexec/xscreensaver/boxed — /usr/libexec/xscreensaver/bubble3d — /usr/libexec/xscreensaver/cage — /usr/libexec/xscreensaver/carousel — /usr/libexec/xscreensaver/circuit — /usr/libexec/xscreensaver/crackberg — /usr/libexec/xscreensaver/cube21 — /usr/libexec/xscreensaver/cubenetic — /usr/libexec/xscreensaver/cubestorm — /usr/libexec/xscreensaver/cubicgrid — /usr/libexec/xscreensaver/dangerball — /usr/libexec/xscreensaver/endgame — /usr/libexec/xscreensaver/engine — /usr/libexec/xscreensaver/flipflop — /usr/libexec/xscreensaver/flipscreen3d — /usr/libexec/xscreensaver/fliptext — /usr/libexec/xscreensaver/flurry — /usr/libexec/xscreensaver/flyingtoasters — /usr/libexec/xscreensaver/gears — /usr/libexec/xscreensaver/gflux — /usr/libexec/xscreensaver/glblur — /usr/libexec/xscreensaver/glcells — /usr/libexec/xscreensaver/gleidescope — /usr/libexec/xscreensaver/glhanoi — /usr/libexec/xscreensaver/glknots — /usr/libexec/xscreensaver/glmatrix — /usr/libexec/xscreensaver/glplanet — /usr/libexec/xscreensaver/glschool — /usr/libexec/xscreensaver/glslideshow — /usr/libexec/xscreensaver/glsnake — /usr/libexec/xscreensaver/gltext — /usr/libexec/xscreensaver/hypertorus — /usr/libexec/xscreensaver/hypnowheel — /usr/libexec/xscreensaver/jigglypuff — /usr/libexec/xscreensaver/jigsaw — /usr/libexec/xscreensaver/juggler3d — /usr/libexec/xscreensaver/klein — /usr/libexec/xscreensaver/lament — /usr/libexec/xscreensaver/lavalite — /usr/libexec/xscreensaver/lockward — /usr/libexec/xscreensaver/menger — /usr/libexec/xscreensaver/mirrorblob — /usr/libexec/xscreensaver/moebiusgears — /usr/libexec/xscreensaver/moebius — /usr/libexec/xscreensaver/molecule — /usr/libexec/xscreensaver/morph3d — /usr/libexec/xscreensaver/noof — /usr/libexec/xscreensaver/photopile — /usr/libexec/xscreensaver/pinion — /usr/libexec/xscreensaver/pipes — /usr/libexec/xscreensaver/polyhedra — /usr/libexec/xscreensaver/polytopes — /usr/libexec/xscreensaver/providence — /usr/libexec/xscreensaver/pulsar — /usr/libexec/xscreensaver/queens — /usr/libexec/xscreensaver/rubikblocks — /usr/libexec/xscreensaver/rubik — /usr/libexec/xscreensaver/sballs — /usr/libexec/xscreensaver/sierpinski3d — /usr/libexec/xscreensaver/skytentacles — /usr/libexec/xscreensaver/sonar — /usr/libexec/xscreensaver/spheremonics — /usr/libexec/xscreensaver/sproingies — /usr/libexec/xscreensaver/stairs — /usr/libexec/xscreensaver/starwars — /usr/libexec/xscreensaver/stonerview — /usr/libexec/xscreensaver/superquadrics — /usr/libexec/xscreensaver/surfaces — /usr/libexec/xscreensaver/tangram — /usr/libexec/xscreensaver/timetunnel — /usr/libexec/xscreensaver/topblock — /usr/libexec/xscreensaver/voronoi • xstar xstar-0:2.2.0-5.fc12 — /usr/bin/xstar • xteddy xteddy-0:2.0.1-5.fc12 — /usr/bin/xteddy • xterm xterm-0:248-2.fc12 — /usr/bin/xterm • xtide xtide-0:2.10-5.fc12 — /usr/bin/xtide • xulrunner xulrunner-0:1.9.1.4-1.fc12 — /usr/lib64/xulrunner-1.9.1/plugins/libnullplugin.so — /usr/lib64/xulrunner-1.9.1/plugins/libunixprintplugin.so • xwrits xwrits-0:2.24-6.fc12 — /usr/bin/xwrits • yadex yadex-0:1.7.0-13.fc12 — /usr/bin/yadex-1.7.0 ¹ http://xfree86.org/pipermail/forum/2003-March/000799.html -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le mercredi 11 novembre 2009 à 13:41 +0100, Hans de Goede a écrit : It would help tremendously to know how you generated this list of files / packages which allegedly use Core Fonts, there are quite a few packages of mine there, but in many cases I have no idea as to why they are here. Sure, sorry about this, I didn't want to make the message longer than it already was. All credit for the receipe goes to ajax, it mostly does : repoquery --whatrequires 'libX11.so* … download, unpack … find elf files … nm -aDu $file | grep -q '\X.*Font' failed the test Complete code with history in git repo-font-audit http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=tree;f=bin (I now it's fugly but it woks) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le mercredi 11 novembre 2009 à 13:50 +0100, Nicolas Mailhot a écrit : Le mercredi 11 novembre 2009 à 13:41 +0100, Hans de Goede a écrit : It would help tremendously to know how you generated this list of files / packages which allegedly use Core Fonts, there are quite a few packages of mine there, but in many cases I have no idea as to why they are here. Sure, sorry about this, I didn't want to make the message longer than it already was. All credit for the receipe goes to ajax, it mostly does : repoquery --whatrequires 'libX11.so* … download, unpack … find elf files … nm -aDu $file | grep -q '\X.*Font' failed the test Complete code with history in git repo-font-audit http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=tree;f=bin (I now it's fugly but it woks) Of course suggestions to improve this are welcome, and I need to ping indirect core font users too ie everyone that uses gtk1, etc Also we have some packages that use font files without passing through the core font system or fontconfig, I need to find a good heuristic to detect those too. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le mercredi 11 novembre 2009 à 13:22 +, Richard W.M. Jones a écrit : I guess it falls to me (with Debian folk) to do this one, since upstream are unlikely to care enough to change this old, working code. Here is the code at issue: http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171view=markup Some questions since I know very little about this: (1) Are there any recipes / guides / tutorials for changing basic X core fonts calls into whatever has replaced them? Note that using a library like gtk is not an option. (2) Will the replacement work on other Unix platforms (eg Solaris, AIX)? The right person to ask this would be Behdad, as he's the Fedora/Red Hat/upstream maintainer of most core components of our current text stack. IIRC his advice last time I asked the question was to avoid accessing fontconfig directly, but to pass through gtk2/pango, QT, or pango-cairo in cairo (those are the three main ways to do text nowadays and modern text requirements are complex enough they're all trying to converge behind the scenes instead of using different implementations of text libs. Too difficult to do alone, even for projects their size) Note that pango-cairo in particular will work on recent versions of other Unixes, and even on Windows and OSX. In fact OO.o is currently migrating this way mainly for OSX compat. If depending on this level of libraries is out of the question for you I'd advise ripping the text parts from those modules. Text is much more complex than just drawing a simple form like a triangle, it is getting more complex every year (as new font format specs and encoding standards revisions are released, and support is added to more minority languages with strange requirements). I don't think you'll find maintaining text support sustainable without depending on common text libs. QT/GTK/Mozilla/OO.o tried, and concluded convergence was the only path. But feel free to ask Behdad directly, I'm sure anything he tells you will prove valuable. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le mercredi 11 novembre 2009 à 14:32 +, Richard W.M. Jones a écrit : I emailed him. It has to be said that maybe text in the OCaml Graphics module only works right now for people using fixed in a ISO-8859-1 locale or whatever [in reality, it works for a whole lot more than that], but ripping out text support means it won't work for anyone at all. It seems the people maintaining text libs are not interested in backends that fail if you use codepoints outside a specific encoding, or when you use the wrong font (because encoding is just one part that changed, OpenType smart features such as ligatures and swashes mean that even if you restrict yourself to basic latin nowadays a modern font won't behave like a simple ASCII font used to ten years ago). Probably because they know that if they limited themselves users would ask for the missing bits anyway. Projects that find modern text libs over-complex should try to maintain their own simple alternative (or pick up the maintenance of the X11 Core fonts system). I suspect they'd quickly find themselves in agreement with current text lib maintainers. So really, it's just a matter of delegation: if you don't want to maintain your own text stack, follow the advice of the people maintaining the one you use, and the advice of X11 Core fonts maintainers (back when there were still some, in 2003) was clear: drop it and use fontconfig instead. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: Identifying remaining core font users
Le mercredi 11 novembre 2009 à 10:00 -0700, Avery, David [DENTK] a écrit : I have a bigger problem with this, I use fedora boxes to talk to older devices (solaris 2.6 and M88KV4 unix machines) that can never be upgraded to newer X clients. Since the fedora ( or any xorg) servers are talking to classic X11 clients dropping support for core fonts is a huge issue. Let me write again what I put in my original message. There is no talk of deliberately dropping support for core fonts infrastructure. Core fonts are slowly heading the way of the dodo through natural obsolescence and lack of people interested in investing in their future. Big text users jumped ship for fontconfig a long time ago (circa 2003) and they're not coming back to resume core fonts maintenance. However, core fonts will be with us, in a somewhat reduced and degraded state, for a long time. So this is not about removing Fedora core fonts infrastructure (individual fonts have and will continue to be dropped every time they fail a legal or technical check and there's no one willing to fix the problem). This is about notifying the maintainers of core font *clients* in Fedora they have a problem and should start planning migration to fontconfig if they're not already doing so (on the plus side anyone migrating today will have access to a font library and text features core fonts can not compare with). Every modern *nix system has some form of fontconfig support (because every single modern GUI app requires it). You can run fontconfig on non-*nixes. There is no good reason for a client app not to migrate to fontconfig if it wants a future. The clients are running on the host computers for flight simulators. The clients are built on 3rd party libraries that date from the early 90s. As the existing Xterms (Tek/NCD ) fail we are replacing them with newer linux based thin clients, but we still need classic X11 font support. The programming support is done on solaris and linux boxes the need to display the same layouts as the xterms I'm sure you don't need me to tell you that forcing the limitations of old clients in new clients is eating your cake now, and that you're preparing yourself a painful big bang migration when the situation gets to the point core font support is no longer at the acceptable level for you. More than six years have elapsed since core fonts stopped being the preferred font system X-side. Use the remaining years wisely before your back is to the wall (I know that's easy for me to say, but there is no magic solution). Having worked with some decades-old systems myself, I know it's really easy to get yourself trapped in a situation where you pay an harm and a leg for multiple levels of legacy emulation that barely work and have pitiful capabilities compared to recent systems, just because someone went for the short-term let's emulate and pretend nothing changed route back when keeping up with the technological changes would have been just slightly harder (but future-proof). -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Identifying remaining core font users
Le jeudi 12 novembre 2009 à 06:51 +0200, Gilboa Davara a écrit : I own both icewm and idesk. As far as I know, both icewm and idesk are linked against xft and should not default to core fonts. (Unless I completely misunderstanding something...) I've been asked to filter out xft matches next run, so if they *only* do xft they won't appear again. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: M+ fonts
Le Mar 10 novembre 2009 07:45, Igshaan Mesias a écrit : Hi, 2009/11/10 かいお (Kaio) k...@kaio.me: (CC'ed Tom 'spot' Callaway) Are all the fonts listed in http://www.geocities.jp/ep3797/modified_fonts_01.html members of mplus font? The font listed there seem to be mixes of multiple fonts. Which is only going to work if the licenses of all the font files used are compatible with each other (mixes is one big reason why sticking to standard licenses is a good idea) Also the license statements on http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/#license in full? Could you persuade the author to release under GPL or any other better license? I will try. GPL + FE or OFl please -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: M+ fonts
Le Mar 10 novembre 2009 00:49, かいお (Kaio) a écrit : (2009年11月10日 05:15), Igshaan Mesias wrote: I have packaged M+ family of fonts. https://fedoraproject.org/wiki/M%2B_fonts Hi Igshaan, I wonder if you could package it with alphanumeric name? such as mplus-fonts because I worry if usage of `+` could pass the package review. :) We have some packages with + in their names in the repo, however this is not something we want to generalise. -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: texlive-2009 breakage?
BTW Jindrich, I know you are very busy, and we never seem to be on irc at the same times, but how is progress on the texlive font packaging front? Font automation QA has progressed quite a bit since you started, you can self-check your progress with repo-font-audit now if you want: http://kojipkgs.fedoraproject.org/packages/fontpackages/1.31/2.fc13/noarch/fontpackages-tools-1.31-2.fc13.noarch.rpm -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Le Lun 2 novembre 2009 11:29, Ankur Sinha a écrit : hi, I've filed a bug[1] against wodim not burning dvds correctly. While browsing through another bug[2] on wodim, I came across this comment[3]. wodim is completely unmaintained since May 6th 2007, don't expect to see any fixes anytime soon as long as Redhat continues to distribute wodim instead of the original software. Can someone please clear this up? You can ignore Jörg Schilling. He managed to antagonize everyone else Linux-side¹, and now complains no one wants to use his cdrecord versions. IIRC after burning bridges Linux-side he launched an OpenSolaris distro named Schillix. I think it was not a big success either for pretty much the same communication reasons. ¹ Adding « informative » messages such as « Linux device naming is stupid, my tools use better conventions, why are not you installing a sane OS like Solaris instead » (paraphrased from memory) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Problems detected in the oldstandard-sfd-fonts rawhide package!
Le Sam 31 octobre 2009 10:57, TK009 a écrit : Running FC_DEBUG=256 against ns-tiza gives me a list of about 50 scripts. Is a list that size normal? Many latin scripts use ASCII + one or two additional glyphs. If tiza's author drawed basic latin (=ascii) only, I wouldn't be surprised the list was very long. It means that Tiza could almost be used, but not quite, by a lot of people. This is a shame. Please relay it to the font author -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Problems detected in the oldstandard-sfd-fonts rawhide package!
Le Sam 31 octobre 2009 11:15, Nicolas Mailhot a écrit :
Le Sam 31 octobre 2009 10:57, TK009 a écrit :
Running FC_DEBUG=256 against ns-tiza gives me a list of about 50 scripts. Is
a
list that size normal?
Many latin scripts use ASCII + one or two additional glyphs. If tiza's author
drawed basic latin (=ascii) only, I wouldn't be surprised the list was very
long.
It means that Tiza could almost be used, but not quite, by a lot of people.
This is a shame. Please relay it to the font author
Of course please only relay elements of the form
foo(2) { 1e34 1e35 }
foo(0) means the coverage for foo is complete
foo(big number) means the coverage is incomplete, but you should not bother
upstream with something that needs a large effort (big number glyphs) on their
part.
--
Nicolas Mailhot
___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Problems detected in the oldstandard-sfd-fonts rawhide package!
Le Sam 31 octobre 2009 11:15, Nicolas Mailhot a écrit :
Le Sam 31 octobre 2009 10:57, TK009 a écrit :
Running FC_DEBUG=256 against ns-tiza gives me a list of about 50 scripts. Is
a
list that size normal?
Many latin scripts use ASCII + one or two additional glyphs. If tiza's
author drawed basic latin (=ascii) only, I wouldn't be surprised the list
was very long.
It means that Tiza could almost be used, but not quite, by a lot of people.
This is a shame. Please relay it to the font author
Of course please only relay elements of the form
foo(2) { 1e34 1e35 }
foo(0) means the coverage for foo is complete
foo(big number) means the coverage is incomplete, but you should not bother
upstream with something that needs a large effort (big number glyphs) on their
part.
--
Nicolas Mailhot
--
Nicolas Mailhot
___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list
New audit messages
Hi all, I did what I could based on current feedback to improve the audit messages and make them clearer and less threatening. If you didn't feel comfortable with the previous version, please check the new text and tell me what you think about it (what you don't like, suggestions to make it better, patches, etc http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=blob;f=bin/repo-font-audit -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Font rendering slightly degraded in recent rawhide
Le Ven 30 octobre 2009 13:59, Benny Amorsen a écrit : It would be nice if fonts like Inconsolata somehow set a flag that they require hinting. This would prevent the side effects on old fonts. This could technically be done in fontconfig IIRC but it would require a lot of unglamorous manual testing and triaging. Which no one is volunteering to do. And before we go there (tackle problems that require manual testing) there is a lot of font problems that can be detected automatically, and need fixing too. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What would be considered a fault in font encodings?
to the people who get on in their inbox and they do not feel aggressed by them. This seems very simple, but it is incredibly important to get things to change. If you are interested to make floss fonts better, and have some time to donate, there is a lot of work to do. As you noted one first step could be to triage fontlint output, and make it more useful. (add explanations, review error criticity, try to output something scripts can easily be fed, etc). The number of people working on the subject right now is really to low to make quick progress. Any new contributor would make a huge difference. -- Nicolas Mailhot -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Font rendering slightly degraded in recent rawhide
Le Jeu 29 octobre 2009 14:30, Christoph Frieben a écrit : 2009/10/29 Tomasz Torcz: There was a change to font properties which changed Best shapes to turn on slight hinting. Good point, but I wonder why this change has been made. It suffices to look at two attachments to https://bugzilla.redhat.com/show_bug.cgi?id=198082 namely https://bugzilla.redhat.com/attachment.cgi?id=351609 https://bugzilla.redhat.com/attachment.cgi?id=351613 which demonstrate that medium hinting used to give better results, namely for MS fonts. It is well known that some old fonts like Microsoft core fonts have bad/buggy hinting (MS hides the problem by adding font-specific workarounds in its text stack). They should certainly never be used to evaluate if a general default is good or not. (that is also something to consider before activating the patented bytecode engine: in-fonts hints are not necessarily better than what freetype auto-computes in many cases) However, this holds at least for Luxi Mono, too , the traditional Red Hat/Fedora monospaced default font. Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the distribution. To me, even the current system font looks blurred and uneven when slight hinting is chosen instead of medium one. ~C Unfortunately it is very difficult to get two people to agree on the right hinting level. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Font rendering slightly degraded in recent rawhide
Le Jeu 29 octobre 2009 17:21, Christoph Frieben a écrit : The empirical result remains, however, and it is consistent with that of any other font that I have looked at. It is consistent for you. You'd need a massive test campaign to prove this is not subjective, not limited to a specific set of fonts, a particular hardware/screen resolution/dpi, etc. The internet is littered with opinions on font rendering that all disagree with each other. Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the distribution. It was the default monospaced font for RHL 8/9, Fedora Core 1/2/3/4/5/6, RHEL 3/4/5 and still **is** for current RHEL 5.4. I thus consider legitimate to comment on it, too, as I expect to be not the only person being attached to using it .. You may comment on it, but do not expect Fedora to care over-much about a component that was removed in Fedora 9 (4 release cycles ago, for legal reasons so it has 0 chance to get back in). For RHEL please go through RHEL channels. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Font rendering slightly degraded in recent rawhide
Le Jeu 29 octobre 2009 18:44, Christoph Frieben a écrit : 2009/10/29 Nicolas Mailhot: You may comment on it, but do not expect Fedora to care overmuch about a component that was removed in Fedora 9 (4 release cycles ago, for legal reasons so it has 0 chance to get back in). For RHEL please go through RHEL channels. I had already pointed out that this issue also affects the current default system font. Let's see what other people out there think about this issue. It's not like you are the supreme judge in this matter, and it's also not the first time that you show up as a hotspur on this mailing list .. Why stop to this mailing list? It seems my nefarious influence extends much wider! http://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages_(2008-07-24) http://www.advogato.org/person/yosch/diary.html?start=61 http://lintian.debian.org/tags/duplicate-font-file.html http://lintian.debian.org/tags/font-in-non-font-package.html Abandon hope all ye are surrounded -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Problems detected in the adf-accanthis-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your adf-accanthis-fonts package:
SRPM RPM17 19
adf-accanthis-fonts adf-accanthis-2-fonts 4 4
adf-accanthis-fonts adf-accanthis-3-fonts 4 4
adf-accanthis-fonts adf-accanthis-fonts4 4
Total 12 12
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the adf-accanthis-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
adf-accanthis-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the abyssinica-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your abyssinica-fonts package:
SRPM RPM 17 18
abyssinica-fonts abyssinica-fonts 1 1
Total 1 1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
18. Fonts with partial unicode block coverage
☛ Some font files included in the package are missing only a few glyphs to
fully cover an Unicode block. Therefore they could be made useful to more
people with only a little effort.
The Unicode consortium revises its tables regularly, and therefore a font
may need to be extended to maintain its full coverage when a new Unicode
revision is published¹.
To check a font file unicode coverage, run the ttfcoverage command. It only
works for modern SFNT fonts (.otf, .ttf).
¹ http://www.unicode.org/charts/
Please take the appropriate measures to fix the abyssinica-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
abyssinica-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the asana-math-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your asana-math-fonts package:
SRPM RPM 17 18 19
asana-math-fonts asana-math-fonts 1 1 1
Total 1 1 1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
18. Fonts with partial unicode block coverage
☛ Some font files included in the package are missing only a few glyphs to
fully cover an Unicode block. Therefore they could be made useful to more
people with only a little effort.
The Unicode consortium revises its tables regularly, and therefore a font
may need to be extended to maintain its full coverage when a new Unicode
revision is published¹.
To check a font file unicode coverage, run the ttfcoverage command. It only
works for modern SFNT fonts (.otf, .ttf).
¹ http://www.unicode.org/charts/
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the asana-math-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
asana-math-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the apanov-heuristica-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your apanov-heuristica-fonts
package:
SRPM RPM 17 19
apanov-heuristica-fonts apanov-heuristica-fonts 4 4
Total4 4
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the apanov-heuristica-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
apanov-heuristica-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the apanov-edrip-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your apanov-edrip-fonts package:
SRPMRPM 17
apanov-edrip-fonts apanov-edrip-fonts 4
Total 4
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the apanov-edrip-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
apanov-edrip-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the artwiz-aleczapka-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your artwiz-aleczapka-fonts package:
SRPMRPM 4 7 11 17 19
artwiz-aleczapka-fonts artwiz-aleczapka-fonts 48 3 48 48 48
Total 48 3 48 48 48
4. Fonts in packages that do not declare font metadata
☛ Font-specific rpm metadata is required for automatic font installation to
work. If you apply our font packaging templates, it will be generated at
package creation time.
7. Fonts that declare non-WWS compliant styles
☛ This WWS-like test checks if font styles use the “Width Weight Slant”
naming
convention¹. As noted by Adobe the CSS family model is less than ideal, but
it's a standard and applications expect it².
Since our applications do not workaround bad font naming with dynamic
renaming heuristics, achieving consistent style naming that can be used in
CSS/web oriented applications requires fixing face naming directly in the
font files. For this reason we test font style naming separately from font
family naming, and do not support complex weight abbreviations and
suffixes³.
To pass this test make sure your style names do not include any qualifier
not defined in the WWS whitepaper¹, and that “Width”, “Weight” or “Slant”
are defined only once. Any other qualifier belongs in the font family name.
If one your font files is listed here please ask its upstream to fix its
naming so it does not need further reprocessing. And in the meanwhile patch
it (if it is available in sfd form) or add a fontconfig rule to your
package to hide the problem⁴.
¹ http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
² http://blogs.adobe.com/typblography/atypi2006/CSS%20%20OT%2015.pdf
³ As defined in the end of the WWS renaming algorithm described in the
Microsoft whitepaper.
⁴ cf the “fontpackages” remapping template; unfortunately this workaround
won't fix problems for non-fontconfig applications, or when
interoperating with other systems.
11. Packages that mix different font families
☛ Reliable font auto-installation requires shipping only one font family
per font package.
(If you've remapped some font names at the fontconfig level your package
may appear here pending some fontconfig fixes upstream is aware of).
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the artwiz-aleczapka-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
artwiz-aleczapka-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the bpg-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your bpg-fonts package:
SRPM RPM 6 17
bpg-fonts bpg-algeti-fonts‧ 1
bpg-fonts bpg-chveulebrivi-fonts ‧ 1
bpg-fonts bpg-courier-fonts ‧ 1
bpg-fonts bpg-courier-s-fonts ‧ 1
bpg-fonts bpg-elite-fonts ‧ 1
bpg-fonts bpg-excelsior-fonts ‧ 1
bpg-fonts bpg-glaho-fonts ‧ 1
bpg-fonts bpg-ingiri-fonts‧ 1
bpg-fonts bpg-nino-medium-cond-fonts 1 1
bpg-fonts bpg-nino-medium-fonts 1 1
bpg-fonts bpg-sans-fonts ‧ 1
bpg-fonts bpg-sans-medium-fonts 1 1
bpg-fonts bpg-sans-modern-fonts ‧ 1
bpg-fonts bpg-sans-regular-fonts 1 1
bpg-fonts bpg-serif-fonts ‧ 1
bpg-fonts bpg-serif-modern-fonts ‧ 1
Total 4 16
6. Fonts that declare style attributes in family names
☛ To be properly processed by applications face qualifiers need to be
declared in style names. Some application stacks such as Microsoft WPF will
try to workaround bad font naming with dynamic renaming heuristics¹, but
heuristics are brittle and pose interoperability problems with applications
that do not use them.
If one your font files is listed here please ask its upstream to fix its
naming so it respects WWS conventions and does not need further
reprocessing. And in the meanwhile patch it (if it is available in sfd
format) or add a fontconfig rule to your package to hide the problem².
There may be a few false positives in this test as some common face
qualifiers can be used with a different meaning in family names.
¹ http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
http://blogs.adobe.com/typblography/atypi2006/CSS%20%20OT%2015.pdf
² cf the “fontpackages” remapping template; unfortunately this workaround
won't fix problems for non-fontconfig applications, or when interoperating
with other systems.
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the bpg-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
bpg-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the bitmap-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your bitmap-fonts package:
SRPM RPM 7 9 11 17 19
bitmap-fonts bitmap-cjk-fonts ‧ ‧ ‧ 2 2
bitmap-fonts bitmap-fonts 14 15 32 32 32
Total 14 15 32 34 34
7. Fonts that declare non-WWS compliant styles
☛ This WWS-like test checks if font styles use the “Width Weight Slant”
naming
convention¹. As noted by Adobe the CSS family model is less than ideal, but
it's a standard and applications expect it².
Since our applications do not workaround bad font naming with dynamic
renaming heuristics, achieving consistent style naming that can be used in
CSS/web oriented applications requires fixing face naming directly in the
font files. For this reason we test font style naming separately from font
family naming, and do not support complex weight abbreviations and
suffixes³.
To pass this test make sure your style names do not include any qualifier
not defined in the WWS whitepaper¹, and that “Width”, “Weight” or “Slant”
are defined only once. Any other qualifier belongs in the font family name.
If one your font files is listed here please ask its upstream to fix its
naming so it does not need further reprocessing. And in the meanwhile patch
it (if it is available in sfd form) or add a fontconfig rule to your
package to hide the problem⁴.
¹ http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
² http://blogs.adobe.com/typblography/atypi2006/CSS%20%20OT%2015.pdf
³ As defined in the end of the WWS renaming algorithm described in the
Microsoft whitepaper.
⁴ cf the “fontpackages” remapping template; unfortunately this workaround
won't fix problems for non-fontconfig applications, or when
interoperating with other systems.
9. Font faces duplicated by different packages
☛ Face duplication wastes resources infrastructure and user side.
Very often an upstream that copied some fonts will forget to keep them up
to date, and the duplication will result in the distribution of old buggy
data. Even when some duplicated font faces are a genuine fork with
different features from the original, applications won't be able to select
them reliably because of naming collision.
We should always ship only one version of a font face in the repository,
and use fontconfig or symlinks to share it accross packages.
11. Packages that mix different font families
☛ Reliable font auto-installation requires shipping only one font family
per font package.
(If you've remapped some font names at the fontconfig level your package
may appear here pending some fontconfig fixes upstream is aware of).
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the bitmap-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
bitmap-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the beteckna-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your beteckna-fonts package:
SRPMRPM17 19
beteckna-fonts beteckna-fonts 1 1
beteckna-fonts beteckna-lower-case-fonts 4 4
beteckna-fonts beteckna-small-caps-fonts 1 1
Total 6 6
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the beteckna-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
beteckna-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the chisholm-to-be-continued-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your chisholm-to-be-continued-fonts
package:
SRPMRPM 17
chisholm-to-be-continued-fonts chisholm-to-be-continued-fonts 1
Total 1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the chisholm-to-be-continued-fonts
package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
chisholm-to-be-continued-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the baekmuk-ttf-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your baekmuk-ttf-fonts package:
SRPM RPM 17 18 19
baekmuk-ttf-fonts baekmuk-ttf-batang-fonts 1 1 1
baekmuk-ttf-fonts baekmuk-ttf-dotum-fonts 1 1 1
baekmuk-ttf-fonts baekmuk-ttf-gulim-fonts 1 1 1
baekmuk-ttf-fonts baekmuk-ttf-hline-fonts 1 1 1
Total 4 4 4
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
18. Fonts with partial unicode block coverage
☛ Some font files included in the package are missing only a few glyphs to
fully cover an Unicode block. Therefore they could be made useful to more
people with only a little effort.
The Unicode consortium revises its tables regularly, and therefore a font
may need to be extended to maintain its full coverage when a new Unicode
revision is published¹.
To check a font file unicode coverage, run the ttfcoverage command. It only
works for modern SFNT fonts (.otf, .ttf).
¹ http://www.unicode.org/charts/
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the baekmuk-ttf-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
baekmuk-ttf-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the cf-bonveno-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your cf-bonveno-fonts package:
SRPM RPM 17
cf-bonveno-fonts cf-bonveno-fonts 1
Total 1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the cf-bonveno-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
cf-bonveno-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the bitstream-vera-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your bitstream-vera-fonts package:
SRPM RPM 8 9 17 19
bitstream-vera-fonts bitstream-vera-sans-fonts 4 4 4 4
bitstream-vera-fonts bitstream-vera-sans-mono-fonts 4 4 4 4
bitstream-vera-fonts bitstream-vera-serif-fonts 2 2 2 2
Total 10 10 10 10
8. Exact font duplication
☛ Several packages duplicate font files with the same checksum. This
needlessly wastes resources.
9. Font faces duplicated by different packages
☛ Face duplication wastes resources infrastructure and user side.
Very often an upstream that copied some fonts will forget to keep them up
to date, and the duplication will result in the distribution of old buggy
data. Even when some duplicated font faces are a genuine fork with
different features from the original, applications won't be able to select
them reliably because of naming collision.
We should always ship only one version of a font face in the repository,
and use fontconfig or symlinks to share it accross packages.
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the bitstream-vera-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
bitstream-vera-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the brettfont-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your brettfont-fonts package:
SRPM RPM 17
brettfont-fonts brettfont-fonts 1
Total1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the brettfont-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
brettfont-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the conakry-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your conakry-fonts package:
SRPM RPM17 18
conakry-fonts conakry-fonts 1 1
Total 1 1
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
18. Fonts with partial unicode block coverage
☛ Some font files included in the package are missing only a few glyphs to
fully cover an Unicode block. Therefore they could be made useful to more
people with only a little effort.
The Unicode consortium revises its tables regularly, and therefore a font
may need to be extended to maintain its full coverage when a new Unicode
revision is published¹.
To check a font file unicode coverage, run the ttfcoverage command. It only
works for modern SFNT fonts (.otf, .ttf).
¹ http://www.unicode.org/charts/
Please take the appropriate measures to fix the conakry-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
conakry-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the dejavu-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your dejavu-fonts package:
SRPM RPM 9 17 18 19
dejavu-fonts dejavu-lgc-sans-fonts ‧ 1 9 9
dejavu-fonts dejavu-lgc-sans-mono-fonts ‧ 4 ‧ ‧
dejavu-fonts dejavu-lgc-serif-fonts ‧ 8 ‧ 8
dejavu-fonts dejavu-sans-fonts 3 5 9 9
dejavu-fonts dejavu-sans-mono-fonts ‧ 4 2 2
dejavu-fonts dejavu-serif-fonts ‧ 8 ‧ 8
Total 3 30 20 36
9. Font faces duplicated by different packages
☛ Face duplication wastes resources infrastructure and user side.
Very often an upstream that copied some fonts will forget to keep them up
to date, and the duplication will result in the distribution of old buggy
data. Even when some duplicated font faces are a genuine fork with
different features from the original, applications won't be able to select
them reliably because of naming collision.
We should always ship only one version of a font face in the repository,
and use fontconfig or symlinks to share it accross packages.
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
18. Fonts with partial unicode block coverage
☛ Some font files included in the package are missing only a few glyphs to
fully cover an Unicode block. Therefore they could be made useful to more
people with only a little effort.
The Unicode consortium revises its tables regularly, and therefore a font
may need to be extended to maintain its full coverage when a new Unicode
revision is published¹.
To check a font file unicode coverage, run the ttfcoverage command. It only
works for modern SFNT fonts (.otf, .ttf).
¹ http://www.unicode.org/charts/
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the dejavu-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
dejavu-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the cjkuni-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your cjkuni-fonts package:
SRPM RPM 3 12 14 17 19
cjkuni-fonts cjkuni-fonts-compat ‧ 2 ‧ ‧ ‧
cjkuni-fonts cjkuni-ukai-fonts1 ‧ ‧ 1 1
cjkuni-fonts cjkuni-uming-fonts 1 ‧ 1 1 1
Total2 2 1 2 2
3. Fonts in packages that contain non-font data
☛ Please do not mix font files with non-font data in packages. Fonts are
usually useful outside of the package that deploys them and should be
installable without pulling in other material.
12. Font linking
☛ Symlinking is a way for non-font packages to avoid duplicating font files,
but it is also a symptom of missing or incomplete fontconfig support.
Fontconfig has been our default font system for a long time, and accessing
fonts by other means will cause behaviour inconsistencies and many other
problems (since fontconfig is much more than a file locating library)
Please ask the package upstream to add fontconfig support to their code
(possibly, via a higher-level library such as pango-cairo).
14. Fonts rpmlint errors on
☛ Check rpmlint output to fix those packages (using the -i flag if you
don't understand it).
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
19. Fonts that do not pass fontlint sanity checks
☛ Fontforge's fontlint¹ test suite found problems in some files included in
the package. Those problems may not be obvious and only manifest as strange
behaviour in specific applications (making them hard to debug). For that
reason it is recommanded to report those problems upstream and get them
fixed, even if the font file seems to work fine most of the time.
You can ask help about specific fontlint errors on:
https://lists.sourceforge.net/lists/listinfo/fontforge-users
¹ http://fontforge.sourceforge.net/fontlint.html
Please take the appropriate measures to fix the cjkuni-fonts package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
cjkuni-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the chisholm-letterslaughing-fonts rawhide package!
Dear packager,
At 20091029T192211Z, while scanning the rawhide repository located at:
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
I have identified the following problems in your chisholm-letterslaughing-fonts
package:
SRPMRPM 7 17
chisholm-letterslaughing-fonts chisholm-letterslaughing-fonts 3 3
Total 3 3
7. Fonts that declare non-WWS compliant styles
☛ This WWS-like test checks if font styles use the “Width Weight Slant”
naming
convention¹. As noted by Adobe the CSS family model is less than ideal, but
it's a standard and applications expect it².
Since our applications do not workaround bad font naming with dynamic
renaming heuristics, achieving consistent style naming that can be used in
CSS/web oriented applications requires fixing face naming directly in the
font files. For this reason we test font style naming separately from font
family naming, and do not support complex weight abbreviations and
suffixes³.
To pass this test make sure your style names do not include any qualifier
not defined in the WWS whitepaper¹, and that “Width”, “Weight” or “Slant”
are defined only once. Any other qualifier belongs in the font family name.
If one your font files is listed here please ask its upstream to fix its
naming so it does not need further reprocessing. And in the meanwhile patch
it (if it is available in sfd form) or add a fontconfig rule to your
package to hide the problem⁴.
¹ http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
² http://blogs.adobe.com/typblography/atypi2006/CSS%20%20OT%2015.pdf
³ As defined in the end of the WWS renaming algorithm described in the
Microsoft whitepaper.
⁴ cf the “fontpackages” remapping template; unfortunately this workaround
won't fix problems for non-fontconfig applications, or when
interoperating with other systems.
17. Fonts with partial script coverage
☛ Some font files included in the package are missing only a few glyphs to
be
accepted by fontconfig as covering one or several scripts. Therefore they
could be made useful to more people with only a little effort.
To check a font file script coverage, run fc-query with FC_DEBUG=256 and
look for lines like: script-id¹(number) { list-of-unicode-codepoints }
For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
file for Maori if codepoints 1e34 and 1e35 are added.
If you feel fontconfig is requiring a glyph which is not strictly necessary
for a particular script, report the problem upstream².
¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
Please take the appropriate measures to fix the chisholm-letterslaughing-fonts
package.
I will warn you again if I find problems next time I am ran.
Your friendly QA robot,
--
repo-font-audit
http://fedoraproject.org/wiki/fontpackages
chisholm-letterslaughing-fonts.tar.xz
Description: application/xz-compressed-tar
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Problems detected in the gfs-ambrosia-fonts rawhide package!
Dear packager, At 20091029T192211Z, while scanning the rawhide repository located at: http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/ I have identified the following problems in your gfs-ambrosia-fonts package: SRPMRPM 19 gfs-ambrosia-fonts gfs-ambrosia-fonts 1 Total 1 19. Fonts that do not pass fontlint sanity checks ☛ Fontforge's fontlint¹ test suite found problems in some files included in the package. Those problems may not be obvious and only manifest as strange behaviour in specific applications (making them hard to debug). For that reason it is recommanded to report those problems upstream and get them fixed, even if the font file seems to work fine most of the time. You can ask help about specific fontlint errors on: https://lists.sourceforge.net/lists/listinfo/fontforge-users ¹ http://fontforge.sourceforge.net/fontlint.html Please take the appropriate measures to fix the gfs-ambrosia-fonts package. I will warn you again if I find problems next time I am ran. Your friendly QA robot, -- repo-font-audit http://fedoraproject.org/wiki/fontpackages gfs-ambrosia-fonts.tar.xz Description: application/xz-compressed-tar ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
