October 2013 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 963648] New: upper bar (shirorekha) rendering is broken for marathi installation

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=963648 Bug ID: 963648 Summary: upper bar (shirorekha) rendering is broken for marathi installation Product: Fedora Version: 19 Component: lohit-devanagari-fonts Severity: unspecified Priority: unspecified Assignee: psatpute(a)redhat.com Reporter: apatil(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com Category: --- Created attachment 748720 --> https://bugzilla.redhat.com/attachment.cgi?id=748720&action=edit screenshot of the problem Description of problem: upper bar (shirorekha rendering) is broken for Marathi installation i have attached screenshot for the issue. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install F19 with Marathi language 2. Installation screen shows Marathi language Actual results: word "मराठी" is broken Expected results: word "मराठी" should render correctly Additional info: -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9bi7MjId7N&a=cc_unsubscribe

9 years, 4 months

1
3
0 / 0

[Fedora-i18n-bugs] [Bug 902866] New: ibus-chewing uses dconf but still installs gconf schemas

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=902866 Bug ID: 902866 Summary: ibus-chewing uses dconf but still installs gconf schemas Product: Fedora Version: 18 Component: ibus-chewing Severity: unspecified Priority: unspecified Reporter: scottt.tw(a)gmail.com Description of problem: ibus-chewing gets its preference settings from dconf on Fedora but the package still installs gconf schemas. Note that this is not just a Fedora packaging level cosmetic bug: * ibus-chewing needs to fix how the default values of its preferences are set. * The upstream Makefile should be fixed to not generate and install gconf schemas. Version-Release number of selected component (if applicable): ibus-chewing-1.4.3-1.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. gconftool-2 -R /desktop/ibus/engine/Chewing # ibus-chewing installs its default preference values through its gconf schema 2. dconf dump /desktop/ibus/engine/chewing/ # but it's really using dconf, _NOT_ gconf ibus-chewing should not attempt to install any gconf or dconf schemas if it still intends to use a ibus_config_get_value() based configuration system. See justification below. Additional info: 1. ibus-chewing uses the ibus_chewing_config_get_value() function for configuration 2. ibus_chewing_config_get_value() is implemented with ibus_config_get_value() in libibus-1.0.so 3. ibus_config_get_value() gets its information from the IBus config service on DBus, which apparently has three possible backends: dconf, gconf and memconf Thus ibus-chewing should look at how ibus-anthy and ibus-hangul handles configuration: http://pkgs.fedoraproject.org/cgit/ibus-anthy.git/tree/ibus-anthy.spec http://pkgs.fedoraproject.org/cgit/ibus-hangul.git/tree/ibus-hangul.spec and not attempt to install any gconf or dconf schemas if it still intends to use a ibus_config_get_value() based configuration system. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=2XIQbLHNzm&a=cc_unsubscribe

9 years, 4 months

1
22
0 / 0

[Fedora-i18n-bugs] [Bug 858221] New: [pa] Rendering of U+0A2F (Ya/=?UTF-8?Q?=E0=A8=AF?=) with halant (0A4D) is not correct as per rule

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858221 Bug ID: 858221 Keywords: i18n QA Contact: extras-qa(a)fedoraproject.org Severity: unspecified Version: 18 Priority: unspecified CC: i18n-bugs(a)lists.fedoraproject.org, kalevlember(a)gmail.com, mclasen(a)redhat.com Assignee: kalevlember(a)gmail.com Summary: [pa] Rendering of U+0A2F (Ya/ਯ) with halant (0A4D) is not correct as per rule Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: aalam(a)redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: harfbuzz Product: Fedora -- You are receiving this mail because: You are on the CC list for the bug.

9 years, 4 months

1
5
0 / 0

[Fedora-i18n-bugs] [Bug 1007493] New: shipped fonts.alias includes references to missing sazanami-times font

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1007493 Bug ID: 1007493 Summary: shipped fonts.alias includes references to missing sazanami-times font Product: Fedora Version: rawhide Component: sazanami-fonts Assignee: tagoh(a)redhat.com Reporter: leftmostcat(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com fonts.alias in the sazanami package is reporting the existence of a sazanami-times font face to Xorg which does not appear to exist. This is causing problems in other packages. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fuECin9gKM&a=cc_unsubscribe

9 years, 5 months

1
24
0 / 0

[Fedora-i18n-bugs] [Bug 754932] New: chewing cannot preview chinese characters in activities search box

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: chewing cannot preview chinese characters in activities search box https://bugzilla.redhat.com/show_bug.cgi?id=754932 Summary: chewing cannot preview chinese characters in activities search box Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: unspecified Component: ibus-chewing AssignedTo: dchen(a)redhat.com ReportedBy: johnxu(a)linpus.com QAContact: extras-qa(a)fedoraproject.org CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com Classification: Fedora Story Points: --- Type: --- Description of problem: input chinese to activities search box, cannot get the preview characters. Version-Release number of selected component (if applicable): ibus-1.3.9.2-3 How reproducible: Always Steps to Reproduce: 1.focus in activities search box 2.select ibus-chewing 3.enter "tk"+space Actual results: nothing display in search box Expected results: preview character "車" in search box Additional info: Does ibus-chewing can provide a candidate window like ibus-pinyin? -- 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.

9 years, 5 months

1
5
0 / 0

[Fedora-i18n-bugs] [Bug 1009350] New: generated output looks not correct

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1009350 Bug ID: 1009350 Summary: generated output looks not correct Product: Fedora Version: 19 Component: ttmkfdir Keywords: i18n Assignee: psatpute(a)redhat.com Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com Blocks: 1007493 Description of problem: This is output with sazanami fonts: sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-ascii-0 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-iso10646-1 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-1 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-15 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-9 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0 Apparently there are no jisx0201.1976-0 for that. Version-Release number of selected component (if applicable): ttmkfdir-3.0.9-39.fc19.x86_64 How reproducible: always Steps to Reproduce: 1.ttmkfdir -d /path/to/sazanami/font 2.see the generated fonts.scale 3. Actual results: no jisx0201.1976-0 Expected results: should be there Additional info: http://en.wikipedia.org/wiki/JIS_X_0201 for more details of JIS X 0201 1976 is a revision number for this spec. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=z7O9EydZoW&a=cc_unsubscribe

9 years, 6 months

1
17
0 / 0

[Fedora-i18n-bugs] [Bug 843331] New: [ta_IN] Please add glyphs for minority orthographies in Tamil

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=843331 Bug ID: 843331 QA Contact: extras-qa(a)fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com Assignee: psatpute(a)redhat.com Summary: [ta_IN] Please add glyphs for minority orthographies in Tamil Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: samjnaa(a)gmail.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: lohit-tamil-fonts Product: Fedora Created attachment 600434 --> https://bugzilla.redhat.com/attachment.cgi?id=600434&action=edit Glyphs required for minority orthographies in Tamil While the Tamil script is mainly used for writing Tamil language text, it is also attested to be used for other language text such as Sanskrit, Saurashtra, Hindi, Marathi, Telugu and Kannada in the form of transliteration. For these minority orthography usecases, some characters from script-neutral blocks are required: 1) The superscript digits ¹²³⁴ would be used for representing the varga consonants (actually ¹ is only used very rarely). The Unicode chapter on Tamil script documents this and recommends the characters (0xb9) 0xb2 0xb3 0x2074. 2) Not only the superscript digits but their corresponding subscript digits ₁₂₃₄ (0x2081-0x2084) are also attested as a stylistic variant choice. 3) The modifier letter apostrophe 02BC ʼ is also seen. 4) Further, sometimes the candrabindu is also seen for nasality. Since there is no Tamil candrabindu character, the generic candrabindu ◌̐ at 0310 can be used. 5) The visarga is commonly seen but the Tamil visarga code point 0B83 is mapped to the Tamil special letter aytam ஃ (which has three dots against the visarga's two dots), so we will have to place the two-dot visarga in the PUA. (Not ideal I know, but it is unlikely to encode a Tamil-specific two-dot visarga. It is not possible to use the Devanagari visarga codepoint 0903 since rendering engines will produce dotted circles as it is not correct to combine Devanagari codepoints with Tamil codepoints.) Attestations for these usages and required glyphs are attached. Please add them with the appropriate script-neutral codepoints shown in the patch TTF so Lohit Tamil (and Lohit Tamil Classical) is also useful for these minority orthographies. BTW it would be good font design policy to make the modifier apostrophe a composite glyph of the regular apostrophe and subscript digits as composites of superscript digits. -- You are receiving this mail because: You are on the CC list for the bug.

9 years, 6 months

1
15
0 / 0

[Fedora-i18n-bugs] [Bug 1024071] New: ibus-m17n is enabled in the password entry field of the lock screen

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1024071 Bug ID: 1024071 Summary: ibus-m17n is enabled in the password entry field of the lock screen Product: Fedora Version: 20 Component: ibus-m17n Assignee: dueno(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com Created attachment 816871 --> https://bugzilla.redhat.com/attachment.cgi?id=816871&action=edit ibus-m17n-latn-post-enabled-in-password-entry-field-of-lockscreen.png Fedora 20 Beta TC6. See screen shot. Apparently, ibus-m17n does not check for IBUS_INPUT_PURPOSE_PASSWORD yet, therefore it is enabled in the password field. ibus-anthy, ibus-libpinyin, and ibus-typing-booster do not show this problem (they already check input purpose). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=w63kBcccZE&a=cc_unsubscribe

9 years, 6 months

1
7
0 / 0

[Fedora-i18n-bugs] [Bug 915448] New: Spell check problem (UTF8 conversion?) with Hunspell

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=915448 Bug ID: 915448 Summary: Spell check problem (UTF8 conversion?) with Hunspell Product: Fedora Version: 18 Component: emacs Severity: unspecified Priority: unspecified Reporter: igor.redhat(a)gmail.com +++ This bug was initially created as a clone of Bug #725235 +++ Created attachment 514921 Sample text with accents (md5sum f91f52b0ae84fd91aa25e0d671228a23) Description of problem: When using emacs / hunspell to spell-check a UTF-8 encoded text file, emacs chokes on some accented letters, with the error message: Ispell error: UTF-8 encoding error. Missing continuation byte in 0. character position: Spell-checking testtext.txt using hunspell with default dictionary...done ispell-process-line: Wrong type argument: number-or-marker-p, nil Version-Release number of selected component (if applicable): emacs-23.2-19.fc15.i686 using hunspell-1.2.15-2.fc15.i686 hunspell-en-0.20110112-4.fc15.noarch How reproducible: Always on my netbook with Fedora 15 for i686. Steps to Reproduce: 1. Open a text file with accented characters, e.g. the attached test case. 2. Start spell-check in emacs (after making sure that aspell is not installed, so that emacs will use hunspell.) 3. Actual results: Error message as above. Expected results: Correct spell-checking session... Additional info: This does not happen with aspell. It also does not happen when spell-checking files using hunspell on the command line. For some other files, the error message was: "this UTF-8 encoding can't convert to UTF-16" Using "enter debugger on error" on the text file, the following appears in *Backtrace* (with byte code removed): Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) ispell-parse-output(#("ël!" 0 3 (charset iso-8859-1)) nil 0) ispell-process-line("^Titre: noël!\n" nil) byte-code("....310\311!\210)\312\313....") ispell-region(1 38) ispell-buffer() call-interactively(ispell-buffer nil nil) --- Additional comment from Akira TAGOH on 2012-06-29 07:00:33 EDT --- ispell.el has the code to find the spell checker program out though, it doesn't update ispell-dictionary-base-alist according to the result. it should be optimized against it. Here is what my .emacs has and I want English spell checker only: (setq ispell-dictionary-base-alist '((nil "[[:alpha:]]" "[^[:alpha:]]" "[']" nil ("-d" "en_US") nil utf-8))) (eval-after-load "ispell" (progn (setq ispell-extra-args '("-a" "-i" "utf-8") ispell-silently-savep t))) It work well here. --- Additional comment from Fedora End Of Life on 2013-01-16 09:39:38 EST --- This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from Fedora End Of Life on 2013-02-13 10:55:37 EST --- Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ubqA30ShKa&a=cc_unsubscribe

9 years, 7 months

1
17
0 / 0

[Fedora-i18n-bugs] [Bug 880494] New: French Keyboard layout not following PC105 (physically same as USA English), and Cannot allocate Eurosymbol as altchar-E or altchar-5

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=880494 Bug ID: 880494 Summary: French Keyboard layout not following PC105 (physically same as USA English), and Cannot allocate Eurosymbol as altchar-E or altchar-5 Product: Fedora Version: 18 Component: xkeyboard-config Severity: low Priority: unspecified Reporter: lsatenstein(a)yahoo.com Description of problem: There is an annaconda problem, and a keyboard layout definition problem and a physical keyboard layout problem. Version-Release number of selected component (if applicable): Fedora 18 RC1 32bit How reproducible: F18 RC1 is being installed with default as English language. But I need the Canadian French Keyboard, as I write both English and French I added the Canadian French keyboard and placed it first in the list. Anaconda continues to ignore the CF keyboard mapping. Only way to force a switch from the US default was is to delete the USA keyboard, which activates the Cdn French version and then i added back the USA English. The USA English physical layout is correct. The Canadian French Keyboard must look like the USA English (PC105 layout). Missing is what configuration we could do in the past (F16,F17), which was to allow one to assign the Euro symbol to the alt-char E, or alt-char 5 So, Anaconda needs some correction to fix what I described, and the keyboard selection physical layout needs to match the physical layout of the USA English 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.

9 years, 7 months

1
37
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs October 2013