i18n-bugs November 2018

i18n-bugs@lists.fedoraproject.org

2 participants
61 discussions

[Fedora-i18n-bugs] [Bug 1145730] date format not set for en_IN
by bugzilla＠redhat.com 20 Nov '18

20 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1145730 --- Comment #9 from Mike FABIAN <mfabian(a)redhat.com> --- Fixed upstream. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1649184] New: Meera font substituted for Malayalam serif instead of Rachana
by bugzilla＠redhat.com 16 Nov '18

16 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1649184 Bug ID: 1649184 Summary: Meera font substituted for Malayalam serif instead of Rachana Product: Fedora Version: 29 Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: rajeeshknambiar(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Description of problem: From Akira's font status page [1] it is observed that for language Malayalam, serif-font is defaulted to Meera, while more appropriate font is Rachana (both from smc-fonts package). Based on the discussion [2], it is agreed to substitute Rachana as the preferred serif font in fontconfig file 65-nonlatin.conf [1] https://tagoh.fedorapeople.org/fonts/status/ [2] https://lists.fedoraproject.org/archives/list/fonts@lists.fedoraproject.org… Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Meera is default serif font for Malayalam language. Expected results: Rachana should be default serif font for Malayalam language. Additional info: Change 'Meera' to 'Rachana' under 'serif' family in 65-nonlatin.conf -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Fedora-i18n-bugs] [Bug 1649858] New: using <ctrl><shift>u to enter unicode no longer works.
by bugzilla＠redhat.com 15 Nov '18

15 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1649858 Bug ID: 1649858 Summary: using <ctrl><shift>u to enter unicode no longer works. Product: Fedora Version: 28 Component: ibus Severity: high Assignee: tfujiwar(a)redhat.com Reporter: phorgan1(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Description of problem: For years I've been able to type <ctrl><shift>u to enter unicode input mode and type the hex value of a unicode character. Now it does nothing. How reproducible: While in an application that lets you enter text press <ctrl><shift>u226c followed by a space Actual results: Nothing Expected results: Output of two notes Additional info: Please don't say use <ctrl><shift>e for the emoji chooser. It can not substitute for the missing behavior. It's a chooser not an inline input method. For some reason the emoji chooser HAS unicode but it's horrible! It's also weird. Why is unicode in an emoji chooser? Who would want to use that? It takes you off to a different window which disappears randomly behind the input screen while you're trying to use it. Whoever created it seems to have no experience with usability. I'm a software engineer with decades of experience and we had to take classes in usability in college. Don't they teach that anymore? I have to select unicode from a list and then search for the unicode character I already know the code point for. It's pretty ghastly. Then when I find it and select it the creepy window doesn't even go away!!! Whoever created it seems really proud of it and just wants it to stay around. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Fedora-i18n-bugs] [Bug 1607997] New: Newer versions available
by bugzilla＠redhat.com 14 Nov '18

14 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1607997 Bug ID: 1607997 Summary: Newer versions available Product: Fedora Version: rawhide Component: google-croscore-fonts Assignee: pnemade(a)redhat.com Reporter: rastus.vernon(a)protonmail.ch QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com Fedora has Arimo 1.23, Cousine 1.20 and Tinos 1.23. Arimo 1.32, Cousine 1.22 and Tinos 1.32 are available from https://github.com/googlei18n/noto-fonts/tree/master/hinted. Arimo has 708 new glyphs and Tinos has 706. It would be nice to have the newer versions in Fedora. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Fedora-i18n-bugs] [Bug 1648825] New: Split and update smc-fonts to match upstream release
by bugzilla＠redhat.com 13 Nov '18

13 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1648825 Bug ID: 1648825 Summary: Split and update smc-fonts to match upstream release Product: Fedora Version: rawhide Component: smc-fonts Severity: medium Assignee: petersen(a)redhat.com Reporter: rajeeshknambiar(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com, petersen(a)redhat.com, psatpute(a)redhat.com, rajeeshknambiar(a)gmail.com Description of problem: We haven't updated smc-fonts in 4 years in Fedora. A lot of updates and fixes were made and a new font was added by upstream in the meantime. With that, a lot of discussions on how to manage the releases of fonts also took place, because by then each font was being updated differently and was getting a different version number. Upstream moved to Gitlab instead of Savannah and each font with its own version number is hosted in individual repository now, see https://gitlab.com/smc/fonts. Fedora can no longer depend on the existing packaging mechanism of single tarball and single makefile, as some fonts use different build tools (e.g. Manjari uses UFO+Fontmake) as well. I've discussed with pravins and he suggests to split the fonts and open a bug for that. Version-Release number of selected component (if applicable): 6.1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Fedora-i18n-bugs] [Bug 1648612] New: bad hinting instructions from bug in ttfautohint
by bugzilla＠redhat.com 10 Nov '18

10 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1648612 Bug ID: 1648612 Summary: bad hinting instructions from bug in ttfautohint Product: Fedora Version: 29 Component: lohit-telugu-fonts Assignee: petersen(a)redhat.com Reporter: htl10(a)users.sourceforge.net QA Contact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, i(a)cicku.me, petersen(a)redhat.com, psatpute(a)redhat.com, yselkowi(a)redhat.com Font Validator identifies this to be another font affected by the ttfautohint bug. The affected glyph ID is 796. Yes it is quite sh*t - "ftview 200 /usr/share/fonts/lohit-telugu/Lohit-Telugu.ttf" , go to glyph id 796, and zoom in and out between 201 ppem and 200 ppem Version affected: lohit-telugu-fonts-2.5.5-4.fc29.noarch +++ This bug was initially created as a clone of Bug #1646687 +++ Description of problem: This was discussed in freetype-devel for much of early October under the thread "rendering issues with xpdf (and other viewers)". upstream patch (this was applied after 1.8.2) - you will need to push this to all the fonts affected - in particular, lohit-devanagari-fonts-2.95.4-5.fc29.noarch commit f18b7c859c92111446ca991743dd709e347d0301 (HEAD -> master, origin/master, origin/HEAD) Author: Werner Lemberg <wl(a)gnu.org> Date: Sat Oct 6 09:04:35 2018 +0200 tafpgm.c: Fix stem width offset handling in storage area. Problem reported by Hin-Tak Leung <htl10(a)users.sourceforge.net>. Version-Release number of selected component (if applicable): ttfautohint-1.8.1-4.fc29.x86_64 How reproducible: Always Steps to Reproduce: 1. "ftview 53 /usr/share/fonts/lohit-devanagari/Lohit-Devanagari.ttf" 2. navigate to glyph idx 472 with F9/F10/F11/F12 3. use up/down arrow key to see that the circular ring of 12 dots disappears and becomes 3 dots, etc. Actual results: 3 dots and fewer than 12 dots for many sizes below about 60. Expected results: 12 dots for idx 472 at all sizes. Additional info: This was discussed on freetype-devel for much of early October under 'rendering issues with xpdf (and other viewers)' --- Additional comment from Fedora Update System on 2018-11-07 01:19:20 EST --- ttfautohint-1.8.2-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-96f75e9054 --- Additional comment from Fedora Update System on 2018-11-08 00:20:07 EST --- ttfautohint-1.8.2-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-96f75e9054 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Fedora-i18n-bugs] [Bug 1641989] New: No pre-edit shown when using ibus-libpinyin
by bugzilla＠redhat.com 09 Nov '18

09 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1641989 Bug ID: 1641989 Summary: No pre-edit shown when using ibus-libpinyin Product: Fedora Version: 29 Component: ibus-libpinyin Assignee: pwu(a)redhat.com Reporter: jadahl(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com Description of problem: When typing chinese using ibus-libpinyin, no preedit text is shown, but I can still commit text. The same issue exist everywhere, gtk2, gtk3, xterm, Firefox, LibreOffice, ... I have tried other input methods (e.g. hangul) and preedit works for those. Version-Release number of selected component (if applicable): ibus-1.5.19-4.fc29.x86_64 ibus-libpinyin-1.10.91-1.fc29.x86_64 mutter-3.30.1-4.fc29.x86_64 (also tried with 3.30.1-2) gnome-shell-3.30.1-2.fc29.x86_64 (also tried with 3.30.1-1) How reproducible: Steps to Reproduce: 1. Select libpinyin 2. Enter some pinyin Actual results: No preedit text is shown, just the popup with character selection. Expected results: Preedit text should be shown. Additional info: I have both https://bugzilla.redhat.com/show_bug.cgi?id=1632981 and https://bugzilla.redhat.com/show_bug.cgi?id=1637418 fixes applied, but also verified that the issue was reproduceable without those fixes. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Fedora-i18n-bugs] molding solutions
by sabina 08 Nov '18

08 Nov '18

*|MC_PREVIEW_TEXT|* LK Mould Limited Are you frustrated when hearing the solution to all molding problems? LK has many years of experience in solving injection molding problem.We make, repair and maintain molds to keep them operating at the highest level you expect. Our problem-solving process includes: -Mold Structure Optimization -Mold Flow Analysis -Mold Material Suggestion -Cycle Times Improvement -Mold Repair Costs Calculation -Detects Correction -Reduce Costs Strategy Development -Full Inspection Report Provision If it is related to plastic injection molding and mold making we can help Inquiry Now LK Mould Limited No.21 Xinanlang Road, JingXia Henan Industrial District, Changan Town, Dongguan City, Guangdong Province, China www.lk-tooling.com If you don't want to receive our communications anymore, you can unsubscribe. We care your privacy Copyright © *|2018|* *|LK Mould Limited|*, All rights reserved. @media only screen and (max-width: 480px){ table#canspamBar td{font-size:14px !important;} table#canspamBar td a{display:block !important; margin-top:10px !important;} }

1 0

[Fedora-i18n-bugs] [Bug 1645237] New: libfontconfig.so.1: undefined symbol: FT_Done_MM_Var
by bugzilla＠redhat.com 08 Nov '18

08 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1645237 Bug ID: 1645237 Summary: libfontconfig.so.1: undefined symbol: FT_Done_MM_Var Product: Fedora Version: 29 Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: gerwald_jogl(a)brown.edu QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, john.j5live(a)gmail.com, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Description of problem: release of FC29 breaks the major scientific package ccp4. All graphical components (for example the program coot) crash. Version-Release number of selected component (if applicable): fontconfig.x86_64 2.13.1-1.fc29 How reproducible: perfect, fails every time. Steps to Reproduce: 1. start computer 2. start program 3. crash on startup Actual results: error message: /disk1/jogl/xsoft/ccp4-7.0/ccp4-7.0/libexec/coot-bin: symbol lookup error: /lib64/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var Expected results: functional program Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Fedora-i18n-bugs] [Bug 1635455] New: uim-canna removal - intentional?
by bugzilla＠redhat.com 07 Nov '18

07 Nov '18

https://bugzilla.redhat.com/show_bug.cgi?id=1635455 Bug ID: 1635455 Summary: uim-canna removal - intentional? Product: Fedora Version: rawhide Component: uim Assignee: tagoh(a)redhat.com Reporter: awilliam(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs November 2018