Closed
Bug 209243
Opened 22 years ago
Closed 22 years ago
Devanagari script not being rendered correctly with unicode fonts & utf-8 encoding
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 166520
People
(Reporter: shree, Assigned: prabhat.hegde)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529
Devanagari script is not being rendered correctly with unicode fonts & utf-8
encoding. For example see the BBC Page or the Hindi Wikipedia page or
http://geocities.com/alkuma/index.html.
I am able to view the pages correctly with IE6 on Win98 and with ICab browser on
the iMac with OS X. Netscape 7 on OS X also did not work.
Please let me know if you need more details.
Reproducible: Always
Steps to Reproduce:
1. View a hindi page encoded with utf-8 devanagari script.
Actual Results:
The script rendering is not correct for the small i maatraa and half letters.
Expected Results:
Displayed it correctly.
I'll be happy to enclose attachments - please let me know how.
Thanks!
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
The "virama" bug can be considered a subset of this issue. My bug report also
cited the BBC Hindi page in the text but I did not cite it in the test case
section. Sorry.
Comment 4•22 years ago
|
||
There's already a bug for devanagari rendering on Windows 98, bug 166520 .
In that sense this is a duplicate. However, this bug also mentions netscape 7
(and therefore mozilla) on mac os X not displaying devanagari with ot fonts
properly. Therefore a fix for bug 166520 - which is windows 9x specific - would
only partly fix this one.
Depends on: 166520
Comment 5•22 years ago
|
||
The bug 179804 alse raises the same problem for win9x as well as mac os x. This
is actually a duplicate of bug 179804 but I don't have permissions to mark it as
one. Please mark this as a duplicate of bug 179804 if you have permissions. For
now, marking this bug as depending on bug 179804 .
Comment 6•22 years ago
|
||
There's a separate bug for CTL support on Mac OS X (see bug 205476 and also bug
121540). So, I'm marking this as a dupe. of bug 166520. What we need to do is to
open a meta bug for Indic script support (or CTL as a whole). There's a meta bug
for Thai so that it may be better to open a meta bug (tracking bug) for Indic
scripts.
*** This bug has been marked as a duplicate of 166520 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Re: the comment made by Jungshik Shin
"What we need to do is to open a meta bug for Indic script support (or CTL as a
whole)"
I recommend that his second suggestion is taken on board. There should be a
meta bug for this CTL as a whole.
This CTL problem is basically an issue of omission which is not local to Mozilla
(nor to browsers in general). The vast majority of applications which handle
textual data, Unicode and TrueType fonts are also missing CTL support.
That being the case, I am not sure that the CTL issue even deserves to be
classed as a "bug". It does need to be tackled but hopefully in a way which
will allow the Mozilla CTL components to be utilised by other applications on
the various platforms.
My own feeling on this matter is that it CTL support is primarily the
responsibility of the platform and not the applications. The various OS vendors
should be providing the API libraries. If Mozilla.org is tackling this issue on
behalf of the platform vendors then perhaps they should provide funding for this
part of the project. All applications which run on these platforms will need to
use the same API.
In the meantime, as Jungshik Shin has suggested, the issue of CTL should be
addressed as a whole whether this is classified as a "meta bug" or as a
much-needed add-on.
If Apple, for example, are tackling this same issue then there will probably be
an accessible API. They will certainly need it for some of their multimedia
applications which have to render text such as their QuickTime SMIL player and
QuickTime text-tracks. I do not believe that Apple will be able to ignore these
issues indefinitely.
Comment 8•22 years ago
|
||
> should be providing the API libraries. If Mozilla.org is tackling this issue on
> behalf of the platform vendors then perhaps they should provide funding for this
> part of the project. All applications which run on these platforms will need to
Agree with JMN about the platform's responsibility to take care of the rendering
issue. That way each application doesn't need to duplicate the same code.
Coming to the specifics however, please note the following:
On Win* ( bug 166520 ), they already have a renderer(uniscribe.dll) for win2k
and xp - it gets enabled when you install the indic language pack. So, a user on
Win9x(that's where the majority of the indic users are currently) would not be
able to use the uniscribe layer. OTOH IE5+ has uniscribe linked to it
statically, and therefore the indic user can still happily use IE5+ on win9x but
not mozilla. There is no way a competitor would provide funding for the ctl
project, and for the user, the response would be: switch to Win2k/XP.
On linux, work is going on to provide indic rendering at the X server level, so
as time passes by the problem will cease to exist. Mozilla could still help in
accelerating the development by providing reusable source that could be moved to
the lower layers.
On mac, I believe there are some browsers that *do* display indic correctly but
mozilla doesn't. But there is a bug somewhere (with a patch?) that suggests that
the rendering is corrected if some specific apis are used.
Looking at the picture overall, it seems that the win9x Indic users(which is
where the majority of the users exist) would be the last stone hanging on
mozilla's neck because there mozilla would never have the privilege of having
apis to call, and you already have a competitor that churns out correct rendering.
Component: Layout: CTL → Layout: Text
QA Contact: arthit → layout.fonts-and-text
You need to log in
before you can comment on or make changes to this bug.
Description
•