Closed Bug 209243 Opened 21 years ago Closed 21 years ago

Devanagari script not being rendered correctly with unicode fonts & utf-8 encoding

Categories

(Core :: Layout: Text and Fonts, defect)

x86
Windows 98
defect
Not set
major

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!
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.
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
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 .
Depends on: 179804
No longer depends on: 166520
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: 21 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.
> 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.

Attachment

General

Creator:
Created:
Updated:
Size: