October 2017 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 1487968] New: fcitx-4.2.9.2 is available

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1487968 Bug ID: 1487968 Summary: fcitx-4.2.9.2 is available Product: Fedora Version: rawhide Component: fcitx Keywords: FutureFeature, Triaged Assignee: liangsuilong(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, i(a)cicku.me, liangsuilong(a)gmail.com, pwu(a)redhat.com, robinlee.sysu(a)gmail.com Latest upstream release: 4.2.9.2 Current version/release in rawhide: 4.2.9.1-5.fc27 URL: https://fcitx-im.org/wiki/Fcitx Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8004/ -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
8
0 / 0

[Fedora-i18n-bugs] [Bug 1486972] New: fcitx-libpinyin-0.5.2 is available

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1486972 Bug ID: 1486972 Summary: fcitx-libpinyin-0.5.2 is available Product: Fedora Version: rawhide Component: fcitx-libpinyin Keywords: FutureFeature, Triaged Assignee: liangsuilong(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, liangsuilong(a)gmail.com, pwu(a)redhat.com, robinlee.sysu(a)gmail.com Latest upstream release: 0.5.2 Current version/release in rawhide: 0.5.1-5.fc28 URL: https://fcitx-im.org/wiki/Libpinyin Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8011/ -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
12
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 --- Comment #14 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> --- (In reply to Nicolas Mailhot from comment #12) > BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays > so unless upstream did something really weird with its OTF files they > satisfy : > > # According to upstream, Ghostscript needs only Type 1 fonts to work > properly. > # It can use TTF or OTF fonts as substitutions as well in case the Type 1 > # fonts are missing, but the substitution is not (and can't be) > guaranteed to > # be absolutely flawless, unless the fonts use the CFF outlines: > # > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format > > https://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over- > truetype/ Yeah, I realize that. That's why there's that additional note in specfile, that even though most of the Ghostscript should work with OTF now, the 'pdfwrite' device is still not able to do so... :-/ And as I mentioned in my previous comment, the ImageMagick also expects the Type1 /AFM fonts, and I expect there are some other applications might require it as well. Here's the list of packages requiring the old 'urw-fonts' package: ghostscript-core grace GraphicsMagick graphviz htmldoc ipe libwmf mscgen pdf-renderer pokerth root-core synfig xpdf ImageMagick -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 --- Comment #13 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> --- (In reply to Nicolas Mailhot from comment #10) > That's a poor situation to be in, but yes the minimum would be to ship the > OpenType¹ versions as required by Fedora packaging guidelines, and maybe > hide somewhere the Type1/AFM versions for GS private use (after asking > Fesco). The first priority would be to avoid Ghostscript blocking progress > in other apps that want to use those fonts. If that can help you in any way, > you have my blessing, for the little it is worth. I'm OK to ship it all together (i.e. *.t1 living next to *.otf), in order for the fonts to have the same file path (I would like to avoid creating a symlinks in that folder). The reason why we now need the Type1 to be living in that exact folder name is that ImageMagick has just added support for 'urw-base35-fonts' and it is expecting the Type1 fonts in that specific location: https://github.com/ImageMagick/ImageMagick/commit/fbca0d09324006b66b01e (I forgot to mention that there are other packages still depending on the Type1 format - ImageMagick is the one of them, and AFAICT there are others.) > As an aside I understand the reluctance of Ghostscript upstream to switch > from "proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds > of stuff by third-party apps, the Type1 support of those apps is going away, > they *will* preferentially use OpenType files, so long term there will be > all sorts of subtle discrepancies between a Ghostscript that understands URW > as "Type1", and the rest of the world that thinks "Opentype". But that's > typically a "choose your poison" situation for the Ghostscript maintainer, > it need not impact the rest of the distro the way it does now. You're getting to the core of the problem here actually. As I mentioned before, Ghostscript upstream does not want to switch to OTF/TTF, because one of their "devices" (inside of Ghostscript called 'pdfwrite', used for conversions, etc.) would not work in quite few scenarios (I had some bug reports about it before IIRC), thus making the PS->PDF and PDF->PS conversions not working. So as the rest of the World is slowly starting to use the OTF/TTF, the Ghostscript is using Type1 fonts (converted from the OTF files actually), and they most likely will be doing it for a long time to come. That's because they are bundling the Type1 fonts with the Ghostscript vanilla sources, so they do not need to care about the rest of the World going with OTF. And that's because of the FPG that we actually ship a separate package for these fonts (because FPG forbids bundling of software, unless there is an exception from FESco). And that's why many other distros IMHO do not face these problems, because they do not care so much about bundling the software - they built it from vanilla sources (with a lots of other bundled libraries, etc.) and just ship it. When this happens, they can have both OTF fonts and Type1 fonts living next to each other. (Type1 is being shipped as part of Ghostscript's resources.) Looking at the sizes of the OTF and TTF, the OTF seems to be "compressed", therefore in order to save users' space, I would again vote for using this format. So to conclude, I will take this to a FESco, but I need to find out how to do this officially first. And I'm currently being under time pressure both from my primary job responsibilities and F27 release schedule - because the process of putting this package into F27 is already underway, and I can't stop it anymore - other packages are currently depending on it as well. In this case, I will probably take the way of "EAFP" instead of "LBYL", make the changes ASAP, and then inform FESco about this and "ask for forgiveness"... :D -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 --- Comment #12 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> --- BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays so unless upstream did something really weird with its OTF files they satisfy : # According to upstream, Ghostscript needs only Type 1 fonts to work properly. # It can use TTF or OTF fonts as substitutions as well in case the Type 1 # fonts are missing, but the substitution is not (and can't be) guaranteed to # be absolutely flawless, unless the fonts use the CFF outlines: # > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format https://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-true... -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 --- Comment #11 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> --- (In reply to Nicolas Mailhot from comment #9) > Note however that Appstream for fonts was heavily influenced by Debian, and > Debian didn't rebase its font packaging around fontconfig as Fedora did a > few years ago, so a lot of the "Need to do foo in appstream because > fontconfig is insufficient or fonts are broken" do not really apply for > Fedora. > > If the font metadata is bad for example Fedora would prefer the packager to > fix the font and patch the metadata rather than hide the brokenness under an > Appstream overlay (which won't exist for apps that use the fonts anyway). I see. :) Well, I hope the AppStream and fontconfig metadata are mostly OK for the moment - at least for the urw-base35-fonts. I've spent a lot of time to get it right. (Currently, there was a small issue with typo in AppStream metadata that has a pull-request waiting for acceptance, and small issue with Standard Symbols PS being to big when used for LGC fonts.) -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 --- Comment #10 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> --- (In reply to David Kaspar [Dee'Kej] from comment #7) > Do you have any suggestion on how to proceed from here? Should I take this > to FESco and ask for official exception/permission to ship both Type1/AFM > and OTF formats? That's a poor situation to be in, but yes the minimum would be to ship the OpenType¹ versions as required by Fedora packaging guidelines, and maybe hide somewhere the Type1/AFM versions for GS private use (after asking Fesco). The first priority would be to avoid Ghostscript blocking progress in other apps that want to use those fonts. If that can help you in any way, you have my blessing, for the little it is worth. As an aside I understand the reluctance of Ghostscript upstream to switch from "proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds of stuff by third-party apps, the Type1 support of those apps is going away, they *will* preferentially use OpenType files, so long term there will be all sorts of subtle discrepancies between a Ghostscript that understands URW as "Type1", and the rest of the world that thinks "Opentype". But that's typically a "choose your poison" situation for the Ghostscript maintainer, it need not impact the rest of the distro the way it does now. ¹ Probably OTF not TTF given the Type1 history of those fonts -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1094015] Review Request: cwtex-q-fonts - a series of modern traditional Chinese fonts

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1094015 Robert-André Mauchin <zebob.m(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zebob.m(a)gmail.com Blocks| |177841 (FE-NEEDSPONSOR) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 Nicolas Mailhot <nicolas.mailhot(a)laposte.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #9 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> --- > (In reply to Nicolas Mailhot from comment #3) > > It does not matter if they are packaged as texlive subpackages or as > > independent projects as long as the template is applied. Also, whoever > > packages them needs to ship some fontconfig files that aliases the various > > past names of the fonts to the new one for backwards compat. Again there are > > templates to do so in fontpackages-devel. > > That's another issue. Ideally, the good fonts should not only have the > fontconfig files properly created for them, but AppStream files as well. Yes, Appstream is yet another thing to have. Note however that Appstream for fonts was heavily influenced by Debian, and Debian didn't rebase its font packaging around fontconfig as Fedora did a few years ago, so a lot of the "Need to do foo in appstream because fontconfig is insufficient or fonts are broken" do not really apply for Fedora. If the font metadata is bad for example Fedora would prefer the packager to fix the font and patch the metadata rather than hide the brokenness under an Appstream overlay (which won't exist for apps that use the fonts anyway). -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 1496466] URW fonts not available in LibreOffice

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1496466 David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #8 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> --- (In reply to Nicolas Mailhot from comment #3) > Reading > http://www.gust.org.pl/projects/e-foundry/tex-gyre/index_html#Licensing > > they got URW to publish the fonts under their own pet license to avoid > dealing with Ghostscript licensing they didn't understood. So as long as > they rebased to that release with no ghostscript import they are ok > legal-wise (do check with spot if you feel like it, though I'm pretty sure > he'd have blocked them from TexLive during its TEX audits if there was still > a problem). > > That sucks if GS added fixes over URW material, but that's how free software > works when projects disagree on licensing. Actually, that note mentions Ghostscript 4.0, which is really old. We currently have 9.X for a quite long time in Fedora now. That might be worth poking in it, to see what the current status is... :) (In reply to Nicolas Mailhot from comment #1) > Someone should really package tex gyre in Fedora, now that the legal issues > have been solved (IIRC). That's basically the same fonts in an opentype > container. Sorry, I'm not going through that rabbit hole again... :D The reason I went into updating urw-base35-fonts was that those are needed by ghostscript, and I want to finally fix all the issues related to f***ed building process. However, if you want, feel free to take inspiration from urw-base35-fonts specfile: https://src.fedoraproject.org/rpms/urw-base35-fonts/blob/master/f/urw-bas... It should be more or less OK (I'm trying to keep it up-to-date), and should be well commented. (In reply to Nicolas Mailhot from comment #3) > It does not matter if they are packaged as texlive subpackages or as > independent projects as long as the template is applied. Also, whoever > packages them needs to ship some fontconfig files that aliases the various > past names of the fonts to the new one for backwards compat. Again there are > templates to do so in fontpackages-devel. That's another issue. Ideally, the good fonts should not only have the fontconfig files properly created for them, but AppStream files as well. I had to create/copy & modify those files manually for urw-base35-fonts, and it took quite some effort to convince usptream to include them in their releases. The AppStream for font files allow users to see the preview of them in Gnome Software (and other software centers in other distros that are using AppStream). -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs October 2017