[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
[Bug 1078661] New: Deprecate the usage of U+0BB8 U+0BCD U+0BB0 U+0BC0 for SRII per latest unicode standard
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1078661
Bug ID: 1078661
Summary: Deprecate the usage of U+0BB8 U+0BCD U+0BB0 U+0BC0
for SRII per latest unicode standard
Product: Fedora
Version: rawhide
Component: lohit-tamil-fonts
Severity: medium
Assignee: psatpute(a)redhat.com
Reporter: srik.lak+public(a)gmail.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
Description of problem:
Complex glyph SRI was changed from U+0BB8 U+0BCD U+0BB0 U+0BC0 to U+0BB6
U+0BCD U+0BB0 U+0BC0 in Unicode 4.1. Lohit-Tamil displays the complex glyph for
both forms for backward compatibility. However this also prevents migration to
latest standard as some input tools too offer same functionality leading to
more content created with U+0BB8 U+0BCD U+0BB0 U+0BC0 as SRI which increases
the need for backward compatibility. To break this vicious cycle, I propose
U+0BB8 U+0BCD U+0BB0 U+0BC0 should not be substituted with complex glyph SRI
and should be displayed normally. Apple / iOS fonts already do this complying
with latest unicode standard. Failing to move to single consistent
representation in line with latest unicode leads to fragmentation within
unicode text, a greater cause for worry than backward compatibility.
I understand the larger problem of standardization cannot happen only by
changing this font, but its a start and Lohit being the only maintained free
Tamil font, can help in the process.
Version-Release number of selected component (if applicable):
2.5.3
How reproducible:
Always
Steps to Reproduce:
1. ஸ்ரீ (U+0BB8 U+0BCD U+0BB0 U+0BC0) should be displayed as ஸ்(U+0BB8 U+0BCD)
ரீ(U+0BB0 U+0BC0) without a space in middle and not compounded form.
Actual results:
U+0BB8 U+0BCD U+0BB0 U+0BC0 giving complex glyph SRI
Expected results:
U+0BB8 U+0BCD U+0BB0 U+0BC0 should not give complex glyph SRI, should give
U+0BB8 U+0BCD and U+0BB0 U+0BC0 seperately.
Change Required:
The line
Ligature2: "'abvs' Above Base Substitutions in Tamil lookup 0 subtable"
u0BB8_u0BCD.half u0BB0 u0BC0
in Lohit-Tamil.sfd should be removed.
Additional info:
See also bug 450699
--
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=6sTzGx2Gsz&a=cc_unsubscribe
9 years, 6 months
[Bug 499790] New: [te_IN][pango]GSUB delete key can't delete the whole char in f10,but works well in rhel5.3
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: [te_IN][pango]GSUB delete key can't delete the whole char in f10,but works well in rhel5.3
https://bugzilla.redhat.com/show_bug.cgi?id=499790
Summary: [te_IN][pango]GSUB delete key can't delete the whole
char in f10,but works well in rhel5.3
Product: Fedora
Version: 10
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: kxiong(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
GSUB press Delete key to delete the whole char,it can't delete the whole char
in f10,but works well in rhel5.3.
I think it is a regression bug.
Version-Release number of selected component (if applicable):
pango-devel-1.22.1-1.fc10.i386
pango-1.22.1-1.fc10.i386
pangomm-2.14.0-2.fc10.i386
How reproducible:
always
Steps to Reproduce:
1.In gedit input U+0C15 U+0C4D U+0C15
2.Press Delete key to delete the char
3.
Actual results:
It can't delete the whole char,it will delete part of the char
Expected results:
It will delete the whole char.
Additional info:
All of chars in [te_IN][GSUB] has the same problem.
But in rhel 5.3 they work well.
So I think it is a regression 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.
9 years, 7 months