i18n-bugs August 2014

i18n-bugs@lists.fedoraproject.org

1 participants
299 discussions

[Fedora-i18n-bugs] [Bug 863817] New: Liberation Sans Hebrew needs Redesign (Willing to contribute)
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=863817 Bug ID: 863817 QA Contact: extras-qa(a)fedoraproject.org Severity: medium Version: rawhide Priority: unspecified CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, psatpute(a)redhat.com Assignee: psatpute(a)redhat.com Summary: Liberation Sans Hebrew needs Redesign (Willing to contribute) Regression: --- Story Points: --- Classification: Fedora OS: All Reporter: LIJI32(a)gmail.com Type: Bug Documentation: --- Hardware: All Mount Type: --- Status: NEW Component: liberation-fonts Product: Fedora Created attachment 623019 --> https://bugzilla.redhat.com/attachment.cgi?id=623019&action=edit New Hebrew glyphs I designed The Hebrew version of Liberation Sans currently uses glyphs from Droid Sans Hebrew. These glyphs have incorrect proportions, weird letter forms and it's generally unreadable. In addition, it go along with the Latin glyphs nicely. I've previously solved the same problem with DejaVu Sans Hebrew by redesigning it and I'd be more than happy to contribute an entirely new Hebrew glyphset for Liberation Sans. I included a Work-in-Progess of new Hebrew glyphs designed to match the design of the Latin Liberation Sans in style, weight and proportions. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Fedora-i18n-bugs] [Bug 772041] New: w3m-0.5.3-2.fc15.x86_64 adds trailing white space
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: w3m-0.5.3-2.fc15.x86_64 adds trailing white space https://bugzilla.redhat.com/show_bug.cgi?id=772041 Summary: w3m-0.5.3-2.fc15.x86_64 adds trailing white space Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: w3m AssignedTo: pnemade(a)redhat.com ReportedBy: hongjiu.lu(a)intel.com QAContact: extras-qa(a)fedoraproject.org CC: pnemade(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Created attachment 550981 --> https://bugzilla.redhat.com/attachment.cgi?id=550981 A testcase # cat w3m.html | /usr/bin/w3m -T text/html -dump > w3m.txt adds trailing white space. w3m-0.5.2-20.fc15.x86_64 doesn't have this problem. -- 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.

1 7

[Fedora-i18n-bugs] [Bug 681750] New: No Language Selection/Language List in GDM
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: No Language Selection/Language List in GDM https://bugzilla.redhat.com/show_bug.cgi?id=681750 Summary: No Language Selection/Language List in GDM Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: i18n Severity: unspecified Priority: unspecified Component: gdm AssignedTo: jmccann(a)redhat.com ReportedBy: aalam(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: jmccann(a)redhat.com, rstrode(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Description of problem: there is no Language Selection in GDM. Specially in Live ISO, it can be very helpful to allow language selection. Version-Release number of selected component (if applicable): gdm-2.91.91-1.fc15.x86_64 anaconda-15.20.1-1.fc15 How reproducible: Everytime Steps to Reproduce: 1. run gdm from installed system or boot from Live ISO 2. 3. Actual results: No language selection in GDM Expected results: there can be language selection Additional info: -- 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.

1 34

[Fedora-i18n-bugs] [Bug 640546] New: [Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used https://bugzilla.redhat.com/show_bug.cgi?id=640546 Summary: [Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used Product: Fedora Version: 14 Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: gedit AssignedTo: rstrode(a)redhat.com ReportedBy: aalam(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: rstrode(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Description of problem: While pressing backspace in gedit's Find/find & Replace box and if halant (U+ 094D of Hindi), it is not working anyway. Version-Release number of selected component (if applicable): gedit-2.30.4-1.fc14.x86_64 How reproducible: Everytime Steps to Reproduce: 1. run gedit 2. type or copy paste (क्प) 3. Backspace two times Actual results: first backsapace will work, but 2nd will not Expected results: with halant (094d), it is should work Additional info: 1) Delete is working as expected 2) supposed to problem for all Indic locales, which has halant -- 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.

1 7

[Fedora-i18n-bugs] [Bug 635957] New: [qt][Cursoring][Indic] - Composed Character Deletion is wrong with DELETE Button
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [qt][Cursoring][Indic] - Composed Character Deletion is wrong with DELETE Button https://bugzilla.redhat.com/show_bug.cgi?id=635957 Summary: [qt][Cursoring][Indic] - Composed Character Deletion is wrong with DELETE Button Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: qt AssignedTo: than(a)redhat.com ReportedBy: smaitra(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: rdieter(a)math.unl.edu, than(a)redhat.com, kevin(a)tigcc.ticalc.org, aalam(a)redhat.com, itamar(a)ispbrasil.com.br, ltinkl(a)redhat.com, thomasj(a)fedoraproject.org, jreznik(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, smparrish(a)gmail.com, rnovacek(a)redhat.com Blocks: 631761,631768 Classification: Fedora Target Release: --- -- 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.

1 12

[Fedora-i18n-bugs] [Bug 635961] New: [Pango][Cursoring][mr_IN] - Composed Character Deletion is wrong with DELETE Button
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [Pango][Cursoring][mr_IN] - Composed Character Deletion is wrong with DELETE Button https://bugzilla.redhat.com/show_bug.cgi?id=635961 Summary: [Pango][Cursoring][mr_IN] - Composed Character Deletion is wrong with DELETE Button Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: pango AssignedTo: behdad(a)fedoraproject.org ReportedBy: smaitra(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: behdad(a)fedoraproject.org, aalam(a)redhat.com, smaitra(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org Blocks: 631761,635957 Classification: Fedora Target Release: --- Description of problem: In pango (tested it in gedit and firefox), the deletion with DELETE key, is not following the rule of deleting entire composed character with a single key press. It is deleting each of the character in a composed character, one by one. Version-Release number of selected component (if applicable): pango-1.28.0-1.fc13.i686 How reproducible: Always Steps to Reproduce: 1. Open gedit or firefox in mr_IN locale 2. Activate ibus with CTRL+SPACE. Select marathi - Inscript 3. Type : kdk (which means consonant KA + Halant + Consonant KA) 4. Position the cursor at the beginning point of the composed character. 5. Now, press DELETE key. (It needs 3 key strokes to delete the whole character, but it should be done with a single key stroke in fact) Actual results: Delete composed character is happening in wrong manner. Actually it is now following the convention (Rule) of BACKSPACE, when deleting a composed character comes into picture. Expected results: It should delete the whole composed character in one DELETE key stroke when cursor positions at the start of the composed character. Additional info: OS : Fedora 13 Arch : i386 -- 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.

1 14

[Fedora-i18n-bugs] [Bug 627127] New: [Indic] Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit)
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [Indic] Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit) https://bugzilla.redhat.com/show_bug.cgi?id=627127 Summary: [Indic] Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit) Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: evince AssignedTo: mkasik(a)redhat.com ReportedBy: aalam(a)redhat.com QAContact: i18n-bugs(a)lists.fedoraproject.org CC: mkasik(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Created attachment 440846 --> https://bugzilla.redhat.com/attachment.cgi?id=440846 PDF file with Hindi Text Description of problem: - Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit), Version-Release number of selected component (if applicable): gedit-2.30.2-1.fc13.x86_64 cairo-1.8.10-1.fc13.x86_64 cairo-1.8.10-1.fc13.i686 pango-1.28.0-1.fc13.x86_64 pango-1.28.0-1.fc13.i686 evince-2.30.3-1.fc13.x86_64 How reproducible: Everytime Steps to Reproduce: 1. open attached pdf file 2. try to copy and paste text to any text editor 3. open http://www.bbc.co.uk/hindi/news/2010/08/100825_nuke_bill_govt_vv.shtml and copy paste data from this to text editor Actual results: Rendering is broken (compare with firefox->gedit copy/paste) Expected results: it should be same as print or Text in PDF file. Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are on the CC list for the bug.

1 19

[Fedora-i18n-bugs] [Bug 1058730] New: Missing contextual information
by Red Hat Bugzilla 05 Feb '15

05 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1058730 Bug ID: 1058730 Summary: Missing contextual information Product: Fedora Version: rawhide Component: iok Assignee: pnemade(a)redhat.com Reporter: ngoswami(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com Source String Contextualization Group (SSCG) is a Fedora SIG group initiated to provide meaningful descriptions of the source strings for translators to ensure the correctness and quality of the translations. As part of this project we have identified few translatable strings which needs contextual information for the ease of translations. More information on SSCG can be found at [1]. This bug is to either fix the source string or to provide context to it. [1] - https://fedoraproject.org/wiki/SSCG -- 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=mbOZMRyWBe&a=cc_unsubscribe

1 2

[Fedora-i18n-bugs] [Bug 1024198] New: No way to change the desktop language in MATE Live
by Red Hat Bugzilla 01 Feb '15

01 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1024198 Bug ID: 1024198 Summary: No way to change the desktop language in MATE Live Product: Fedora Version: 20 Component: LiveCD Keywords: i18n Assignee: mclasen(a)redhat.com Reporter: tagoh(a)redhat.com CC: i18n-bugs(a)lists.fedoraproject.org Description of problem: MATE spin doesn't contain system-config-language nor the ability to change the language at the display manager unless I'm missing something there. so the user can't change the language on MATE Live. Version-Release number of selected component (if applicable): Fedora-Live-MATE-Compiz-x86_64-20-Beta-TC6.iso How reproducible: always Steps to Reproduce: 1.boot iso 2. 3. Actual results: No system-config-language nor language selector at the display manager Expected results: should support any way to change the language Additional info: Apparently no a kind of "LiveCD - MATE" component in bugzilla. so just filed this here. -- 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=7ZZznpufQh&a=cc_unsubscribe

1 1

[Fedora-i18n-bugs] [Bug 923346] New: Symbols incorrectly displayed
by Red Hat Bugzilla 31 Jan '15

31 Jan '15

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=923346 Bug ID: 923346 Summary: Symbols incorrectly displayed Product: Fedora Version: 18 Component: google-croscore-fonts Severity: high Priority: unspecified Assignee: pnemade(a)redhat.com Reporter: jv+fedora(a)fcelda.cz QA Contact: extras-qa(a)fedoraproject.org CC: andreas.bierfert(a)lowlatency.de, fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, jreznik(a)redhat.com, kevin(a)tigcc.ticalc.org, ltinkl(a)redhat.com, mike(a)cchtml.com, mkasik(a)redhat.com, pnemade(a)redhat.com, rdieter(a)math.unl.edu, richard(a)rsk.demon.co.uk, rnovacek(a)redhat.com, stefan(a)lsd.co.za, than(a)redhat.com, tibbs(a)math.uh.edu Depends On: 901858 I'm seeing the same problem as described in bug #901858 with google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch package. Removing the package solves the problem and math symbols are displayed correctly. google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch okular-4.10.1-1.fc18.x86_64 +++ This bug was initially created as a clone of Bug #901858 +++ Created attachment 683157 microchip pdf showing the fault Description of problem: When reading technical pdfs, the wrong symbols are displayed for some math characters. e.g. pi is displayed as not equal, ohms as a vertical bar, and micro (mu) is displayed as infinity. Version-Release number of selected component (if applicable): okular-4.9.5.-1.fc18 How reproducible: Displaying a technical pdf such as http://ww1.microchip.com/downloads/en/AppNotes/00954A.pdf shows the wrong symbols. E.G. In figure 1 - the value for C2 is displayed as 470 (inf) F instead of 470 (mu) F Steps to Reproduce: 1. Display technical pdf 2. 3. Actual results: pi is displayed as not equals ohms as a vertical bar micro(mu) as infinity Expected results: The correct symbols should be displayed Additional info: Evince also has this problem, but emacs displays everything correctly. This happens across a range of pdfs and I think is a serious bug than needs fixing as soon as possible,. It reflects badly on fedora if we cannot display technical specifications properly. --- Additional comment from Kevin Kofler on 2013-01-19 12:47:09 EST --- > Evince also has this problem Reassigning to poppler, which is the common library used by both. What I see is that this PDF does not embed its fonts, which means you get whatever fonts are installed on the system. In this case, Symbol is mapped to wine-symbol-fonts. So I'm not sure whether poppler or the font is doing the wrong thing there. And by the way, the PDF is bad because it uses a font outside of the PostScript standard (Symbol) and doesn't embed it. A portable PDF MUST embed all the non-PostScript fonts it uses. --- Additional comment from Richard Kennedy on 2013-02-28 07:57:45 EST --- Just a quick update. The new embedded pdf reader in Firefox 19 displays these files correctly too. Well, the pdf may not be correct but it was created by adobe software & there are lots of them out in the wild, so we should do something to fix it. Can I change the default font mapping for popper to something else ? If so how do I go about that? --- Additional comment from Kevin Kofler on 2013-02-28 19:00:01 EST --- As I said, it's a bug in either poppler or wine-symbol-fonts (or both). Unfortunately, the poppler maintainer hasn't answered so far. --- Additional comment from Marek Kašík on 2013-03-01 07:05:38 EST --- Hi, this is a bug in wine-symbol-fonts package. The symbol.ttf font has wrong mapping. For additional info see upstream bug http://bugs.winehq.org/show_bug.cgi?id=24099. I'm reassigning this to wine. Regards Marek --- Additional comment from Jason Tibbitts on 2013-03-01 14:45:34 EST --- Wow, it's great news that this the cause is known, because I've been struggling with this for some time. Unfortunately upstream bug report has been there for quite some time with no progress, so I'm not sure what chance we have of getting this fixed. What would break by removing this font? Can it be removed from the dependency list of the wine-fonts metapackage? --- Additional comment from Kevin Kofler on 2013-03-01 17:53:16 EST --- Would that really fix the issue? I don't think the symbols can be properly displayed if the font is entirely missing. I suspect there's no way around fixing the font. --- Additional comment from Richard Kennedy on 2013-03-02 11:50:34 EST --- I've just fixed the font following the steps in the wine bug 24099 and it works. I only run one wine app, ltspice, and it still works after the fix, so it's all looking good. Both firefox & emacs can display these characters properly so they must be using some other font, but I don't know how to find out which one. But if we could find out can we swap the mapping to that? --- Additional comment from Richard Kennedy on 2013-03-02 13:29:50 EST --- Having thought about this some more, I think that is more likely that the bug really is that poppler isn't handling unicode characters properly. I cut & pasted the failing mu character from evince into emacs, and it says it's unicode 0x3BC. So it seems that poppler tries to use the symbol font and 0x3BC is something different in there because it's broken too. emacs and firefox somehow resolve the unicode character correctly and don't end up in the symbol font, but I haven't found out which font they do use. I didn't realise all of this stuff was so involved and complex. At least fixing up the font is a temporary fix. --- Additional comment from Kevin Kofler on 2013-03-02 17:58:39 EST --- Maybe poppler shouldn't be looking up "Symbol" in fontconfig at all, but handle the Symbol font specially? The Window$ Symbol TTF font which WINE's font tries to emulate is a hack which predates Unicode and maps Greek letters and other symbol characters to plain 8-bit characters (0-255). Somebody should probably test what happens when you use the original M$ Symbol.ttf. If it has the same issue, it's not WINE's fault. --- Additional comment from Richard Kennedy on 2013-03-04 12:44:39 EST --- Just a couple of notes :- * The poppler version here is 0.20.2 which was released on Tue July 10, 2012, and the latest is 0.22.1 which contains quite a number of bug fixes. * I've reset my machine to the default state and if I run pdftohtml on this file the correct characters are generated in the html. (pdftohtml is a poppler tool). * Libre Office also can display these files correctly. Is there any way to get poppler to use the opensymobol font to resolve these symbols? AFAICT opensymbol contains all of the correct unicode so might make a good replacement and it's already installed. --- Additional comment from Marek Kašík on 2013-03-05 07:26:52 EST --- Created attachment 705385 blacklist wine font Symbol (In reply to comment #10) > Just a couple of notes :- > > * The poppler version here is 0.20.2 which was released on Tue July 10, > 2012, and > the latest is 0.22.1 which contains quite a number of bug fixes. The poppler-0.22.1 doesn't fix this. > * I've reset my machine to the default state and if I run pdftohtml on this > file > the correct characters are generated in the html. (pdftohtml is a poppler > tool). It generates correct html because the codes for those characters are correct in the pdf. > * Libre Office also can display these files correctly. Do you mean the html or the pdf? Libre Office displays me the same characters as poppler when importing the pdf. > Is there any way to get poppler to use the opensymobol font to resolve these > symbols? AFAICT opensymbol contains all of the correct unicode so might make > a good replacement and it's already installed. Place the attached file to ~/.config/fontconfig/fonts.conf. This will blacklist the font for all applications which use fontconfig (useful when the wine-symbol-fonts is a dependency of a package which you don't want to remove). I've tried to view a file with the character for the micro sign (UTF-8 code 0xC2B5) in notepad which is part of wine-common. After switching the font to "Symbol", it showed me the incorrect symbol. I guess that there is really something wrong with the font. Regards Marek --- Additional comment from Kevin Kofler on 2013-03-05 10:00:50 EST --- The problem is that the Symbol font was designed in a way that the 'm' character is displayed as 'µ', and 'µ' is not mapped to anything. In fact, Symbol was the way to get those special characters in old software which didn't support Unicode. I don't know whether it's possible to fix this issue without breaking that old software when people try to run it under WINE. I hope it's possible, but I'm not sure. The WINE upstream bug report has a proposed fix, but I don't know whether that fix doesn't break the non-Unicode apps. --- Additional comment from Andreas Bierfert on 2013-03-05 14:55:02 EST --- Well as a workaround we could confine wine symbol to wine for now (like with tahoma). This would reduce the problem to wine applications. Before resorting to this I will investigate a bit... -- 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=mExkG0NduF&a=cc_unsubscribe

1 17

← Newer
1
...
12
13
14
15
16
17
18
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs August 2014