[Bug 503145] New: New BPG Excelsior font released
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: New BPG Excelsior font released https://bugzilla.redhat.com/show_bug.cgi?id=503145 Summary: New BPG Excelsior font released Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: bpg-fonts AssignedTo: tcall...@redhat.com ReportedBy: nicolas.mail...@laposte.net QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-fonts-bugs-list@redhat.com Classification: Fedora Description of problem: Upstream has released a new free/libre font: http://besariongugushvili.spaces.live.com/blog/cns!2B325D7BF5367FE3!496.entry Could it be integrated to the existing srpm? (or a new one if you prefer) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 501854] Review Request: lcdf-typetools - The LCDF Typetools for manipulating OpenType fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=501854 Orcan 'oget' Ogetbil oget.fed...@gmail.com changed: What|Removed |Added CC||oget.fed...@gmail.com Flag||fedora-review? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 502582] CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=502582 zouxiaogang zxc...@vip.sina.com changed: What|Removed |Added CC||zxc...@vip.sina.com --- Comment #2 from zouxiaogang zxc...@vip.sina.com 2009-05-29 23:03:12 EDT --- that F9 and F10 are updated,what time? pango-1.22.3-1.fc10.i386 (now) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: Re: [Pkg-fonts-devel] Debtags localisation and font tags proposal
Hi, Before Debian and Ubuntu embark on a different solution, I'd like to point out that: 1. The Fedora solution is going to be the upstream fontconfig/pango/packagekit solution, because the related code is already merged or in the merge queue upstream 2. it is not tied to rpm, we have some minimalistic rpm glue but the rest is freedesktop of gnome code 3. because the font package metadata is generated by fontconfig at package creation time, it matches the font resolution mechanism fontconfig apps (99.99% of our modern desktop) use. It is completely useless to embark in a better different classification if apps will not consume it. 4. Apart from a few specialists, no user is going to check font package metadata manually — they'll rely on their apps to suggest the right package to install. 5. Likewise manually-inputed tags will just bitrot over time, due to the vast imbalance between the number of fonts to package and the number people willing to package them. 6. package metadata has a download and processing cost, it should only be added if it will actually be used 7. there is not reason fc-query --format '%{=pkgkit}' can not be extended in the future once the code to make use of more info is written (and we understand exactly what this code requires as input) 8. our font metadata syntax is font(something_fontconfig_understands) something_fontconfig_understands uses usual fontconfig conventions (see fc-list, fc-match and friends) Thus, my take on the discussion on http://lists.debian.org/debian-devel/2009/05/msg00829.html is simply: 1. iso15924 script names in tag? Wonderful! However, pretty useless while font-using apps do not know about iso15924. Teach apps iso15924 (which will be at fontconfig/pango level since that's where the font substitution logic is) and it'll be trivial to make fc-query --format '%{=pkgkit}' output it 2. add style/face information? Terrific! However current code does not handle font family resolution yet. (it's intended to but right now nothing consumes font(name)). So before worrying about styles, how about making basic stupid name resolution work? 3. right now fc-query only processes font files. Ideally it should be extended to process fontconfig xml ruleset files and the font metadata for a package generated from the info in the font files + the fontconfig file in the package. Trying to pass exceptions and other manually generated info to the metadata generator otherwise won't really work — you need to pass it to the fontconfig instance on the user system too, and you need your packaging system and fontconfig not to have divergent views on how to treat fonts. Thus, to sum up, fc-query limitations are fontconfig limitations, our apps use fontconfig, fixing fontconfig will fix apps and fc-query, replacing fc-query instead of enhancing fontconfig will just introduce a disjoint between apps and packages, without enhancing the user experience, since he needs apps to process the font file and packages anyway. -- 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: [Pkg-fonts-devel] Debtags localisation and font tags proposal
Just wanted to say that I fully support Nicolas's assessment. I'm not sure what the use of those tags is if the text stack doesn't understand them. The fontconfig+pkgkit+pango solution we developed is designed to be cross-distro and extensible. But, oh well, who am I preaching here... behdad fontconfig, harfbuzz, fribidi, pango, cairo maintainer On 05/29/2009 09:37 AM, Nicolas Mailhot wrote: Hi, Before Debian and Ubuntu embark on a different solution, I'd like to point out that: 1. The Fedora solution is going to be the upstream fontconfig/pango/packagekit solution, because the related code is already merged or in the merge queue upstream 2. it is not tied to rpm, we have some minimalistic rpm glue but the rest is freedesktop of gnome code 3. because the font package metadata is generated by fontconfig at package creation time, it matches the font resolution mechanism fontconfig apps (99.99% of our modern desktop) use. It is completely useless to embark in a better different classification if apps will not consume it. 4. Apart from a few specialists, no user is going to check font package metadata manually — they'll rely on their apps to suggest the right package to install. 5. Likewise manually-inputed tags will just bitrot over time, due to the vast imbalance between the number of fonts to package and the number people willing to package them. 6. package metadata has a download and processing cost, it should only be added if it will actually be used 7. there is not reason fc-query --format '%{=pkgkit}' can not be extended in the future once the code to make use of more info is written (and we understand exactly what this code requires as input) 8. our font metadata syntax is font(something_fontconfig_understands) something_fontconfig_understands uses usual fontconfig conventions (see fc-list, fc-match and friends) Thus, my take on the discussion on http://lists.debian.org/debian-devel/2009/05/msg00829.html is simply: 1. iso15924 script names in tag? Wonderful! However, pretty useless while font-using apps do not know about iso15924. Teach apps iso15924 (which will be at fontconfig/pango level since that's where the font substitution logic is) and it'll be trivial to make fc-query --format '%{=pkgkit}' output it 2. add style/face information? Terrific! However current code does not handle font family resolution yet. (it's intended to but right now nothing consumes font(name)). So before worrying about styles, how about making basic stupid name resolution work? 3. right now fc-query only processes font files. Ideally it should be extended to process fontconfig xml ruleset files and the font metadata for a package generated from the info in the font files + the fontconfig file in the package. Trying to pass exceptions and other manually generated info to the metadata generator otherwise won't really work — you need to pass it to the fontconfig instance on the user system too, and you need your packaging system and fontconfig not to have divergent views on how to treat fonts. Thus, to sum up, fc-query limitations are fontconfig limitations, our apps use fontconfig, fixing fontconfig will fix apps and fc-query, replacing fc-query instead of enhancing fontconfig will just introduce a disjoint between apps and packages, without enhancing the user experience, since he needs apps to process the font file and packages anyway. ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list