From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a+) Gecko/20020714 BuildID: 2002071422 occurs in Mozilla build 2002071422 on Solaris 8 and Netscape 7.0_03 on Solaris 8 all chars in every display-levels should be displayed at the same time in the same view point. Reproducible: Always Steps to Reproduce: 1. in any textfield of Mozilla e.g. - browser's location bar - textfield in HTML (e.g search field of http://www.sanook.com) - Mail's msg search textfield reminder: textfield (one-line), not textarea (multiple-line). 2. type Thai text with below-level char e.g. "Ko Kai + Sara U + Mai Ek" (U+0E01 + U+0E38 + U+0E48) --> Ko Kai (U+0E01) is a base-level char --> Sara U (U+0E38) is a below-level char --> Mai Ek (U+0E48) is a top-level char Actual Results: - only top/above/base-level chars are displayed at the time of keying. - need to press <down-arrow> key, scrolls to see below-level char. (and then need to press <up-arrow> key, scrolls to see the original view) Expected Results: all chars in every display-level are displayed on screen, in the area of textfield, at the same time. fyi, in Thai writing system, there're 4 display-levels of character. from highest to lowest: top, above, base, below. several Thai characters with different display-levels can be composed together, we call this composed unit a "diplay cell".

correction: several Thai characters with different display-levels can be composed together, we call this composed unit a ** "display cell". **

katakai-san: can you own this Solaris bug?

As far as i can tell, this is not a Solaris specific bug (though i can't think of a script supported in Mozilla that has below base characters). This bug is not due to a problem in thai rendering support, but because y origin from which the character is drawn leaves no room for below base characters to show up. As arthit mentions, text (vs single-line text) does not exhibit this problem for obvious reasons. Can someone advise on how to fix this? Can we increase the size of the textfield widget for thai and indic (which have same issue) builds? Changing drawing origin does not seem to be the right solution to me.

Prabhat/Arthit, Can you attach screen shots? wrong image and correct image on textfield and text area?

base-level char missing from view point

base-level char displayed correctly. (Thai Character Sara UU (U+0E39) " Ù " ) note: both Netscape and Mozilla show the same result. (the screenshot took from Netscape)

the expected result is like the screenshot from Windows (attachment 94448 [details])

sorry, typo in comment #5 and #6 please change "base-level" to "below-level" the text should be read as "below-level char ..." ---- also the screenshots took at the url/address bar, but the issue is actually occurs with all textfields.

to make it possible to cover all character in every display-level, - enlarge the textfield or - small down the font size

Over to new bugzilla component "Complex Text Layout" ...

Firefox 3 beta 3 (Ubuntu) on th.WP's "Japan" page, look at address bar, the lower-part of characters are not shown. http://th.wikipedia.org/wiki/%E0%B8%8D%E0%B8%B5%E0%B9%88%E0%B8%9B%E0%B8%B8%E0%B9%88%E0%B8%99

Not Solaris-only, same appearance on GNU/Linux. (Firefox 3 beta 3, Ubuntu 8.04 Alpha 4, GNOME). This is not really a rendering bug, as no matter how text is rendered, if there's no space enough to shown it, it cannot be fully shown (in this case the lower-part has been cropped). As Firefox 3 starts to support url that contains non-ascii (Internationalized Resource Identifier) = show readable non-western text, instead of %xx%xx%xx%xx%xx encoded text -- this bug is more visible and needs attention.

Refer to Arthit's Comment #11, on Mac OS X with Firefox 3b4pre build 2008030111 the lower-part of characters are not *fully* shown. Increasing of location bar size about 5 pixels might help.

This is a Firefox theme bug. Should be pretty easy to fix.

Here is the comparison of the word "Japan" in thai in Minefield nightly trunk build'stextbox and Safari's textbox and word on TextEdit on Mac OS X. Apparently textbox in Minefield, the lower-part charecters are not *fully* shown the as well. Is it a widget bug?

I have no problem on this issue. Mac OS X 2008030204 with default configuration. I try both large and small icon size.

fyi, the vertical (y-axis) position of the text in textfield may slight different between a textfield under edit mode (i.e. with caret inside) and a textfield under display mode (i.e. after you hit enter).

No problem on Windows XP. Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030305 Minefield/3.0b4pre

Not going to block on this until we can get a solid description of what the problem is. The previous four or five comments alternately show it as a problem and not a problem on OSX and Windows. Is this a problem? Is it in the location bar or text box widgets? Please make sure you're testing with a nightly build on a clean profile. Feel free to renominate if someone can clearly show what the problem is.

BugAThon Bangkok severity: normal -> minor note: Official support language like "Gujarati" do has this problem too.

from BugAThon Thailand: we tested on Linux and Mac OS X with nightly build of 28 March 2008, and found this problem. you need to look close at some cases to notice this problem, some fonts will make it more visible, some others make it less visible - but the problem is still there. for location bar case, the problem will be more visible if the location bar is in editing mode (focused, with caret inside). try copy and paste this into the location bar: กู่ฐิ์

location bar in editing mode: left: without Thai character - text shown in textfield as normal right: with Thai character (ก) - text went lowered in textfield (see the red line)

a Theme bug or a XUL widget bug ?

Seems this problem is occur with Georgian, an official support, too. This is a theme and XUL widget problem?, because I see the same problem in location bar and text box widget. If it is XUL widget problem, too, should I create a separated bug?

Works for me on Ubuntu 8.10a6 fresh install

(In reply to comment #19) > Not going to block on this until we can get a solid description of what the > problem is. The previous four or five comments alternately show it as a problem > and not a problem on OSX and Windows. > > Is this a problem? > Is it in the location bar or text box widgets? Still a problem in Firefox 3.5.2 on Mac OS X 10.5.8. In location bar and search box. Occurs both in display mode and editing mode.

a video clip demonstrate the moving baseline of text in location bar http://www.youtube.com/watch?v=O06lHC1fSis in the location bar, look at the text "http://th.wikipedia.org/wiki/" - it will move up and down, when got appended/unappended with a Thai character (in this case, 'ป')

I already tried above. There was nothing odd in Vista. So this is not the bug for all platform at least. This may be caused by multiple UI fonts with different height displaying in one row; another font will be normally chosen by system when the current font can not display.

The baseline should not move in Firefox 3.5.3, though the location bar will only have enough room for Thai characters when the line-height of the UI font for the system language is high enough.

So is this dependent on the Thai Macintosh system font? I'm unclear as to what a solution might be.

As Karl says in comment 31, the issue of the shifting baseline during typing does not seem to occur in 3.5.3 - at least, I wasn't able to trigger this behavior. However, it is still possible that tall or deep characters will be clipped, and not fully displayed, if they extend beyond the normal bounds of the line-height used. This can happen with a number of languages and scripts, not only Thai. For example, copy العربي ("Arabic" in Arabic) into the location bar, and the two dots under the final ي character are clipped off, making it indistinguishable from ى. The clipping is even more obvious with Devanagari: try ह हु हू in the location bar (the consonant HA by itself, and combined with two different vowels). The vowel diacritics are almost entirely clipped away, leaving the user to guess what's supposed to be there. This is a basic problem with fixed-height, single-line controls when using scripts that have significant diacritic usage, especially if multiple diacritics can be stacked. It's difficult to design a control that has enough height to accommodate the tallest/deepest combinations that may occur, and yet looks good for "typical" text where these may be quite rare. See also bug 402239, which describes the same fundamental issue from the other point of view: <select> controls with Devanagari are rendered "too high", because they are sized to accommodate the potential low diacritics in the font. But if we constrain the size of the controls so that they look better, they may end up clipping certain character combinations. It might help a bit if we allowed the text in these controls to paint beyond the ascent/descent of the line, instead of clipping it, so that the glyphs would be drawn over the borders (or at least the 1-pixel padding that seems to be present). However, allowing this kind of "overflow painting" could lead us into tricky issues of ensuring that we erase/redraw properly, so as to avoid leaving artifacts on screen as the text changes. Another possible solution would be to allow localizers to adjust the metrics of the location bar, search box, and similar controls. But that might get chaotic...

Comparing Firefox 3.5.3 and Safari 4.0.3 on OS X 10.5.8, it seems that Safari does allow the glyphs to paint beyond the nominal ascent/descent of the line. The screenshot shows the same text in the location bar of Firefox (left) and Safari (right); note how in Safari, the dots underneath ي in Arabic, and the vowels on Devanagari हु हू, are painted beyond the area of the selection highlight, whereas in Firefox they are clipped.

If you poke at the frame tree directly you should be able to see where the vertical space in the URL bar comes from. Some of it seems to come from padding and margins in the various elements that make up the URL bar. Possibly we can tweak them so that the text input's scroll-port takes up all the available vertical space?

(In reply to comment #32) > So is this dependent on the Thai Macintosh system font? I'm unclear as to what > a solution might be. The available height and baseline of the text input is currently the line-height and baseline of the UI font, which depends on the system locale, not the firefox localization. The extents of Thai characters would depend on the the UI font if it supports Thai characters, or the pref fonts for the Thai language if not. (In reply to comment #35) > If you poke at the frame tree directly you should be able to see where the > vertical space in the URL bar comes from. Some of it seems to come from padding > and margins in the various elements that make up the URL bar. Possibly we can > tweak them so that the text input's scroll-port takes up all the available > vertical space? Bug 488776. I also pondered a text layout mode (kind of like size-adjust) where, instead of the em-heights of all fonts matching, the line-heights match the specified line-height. Because baselines differ between fonts they would no longer align. Would the line-heights of the fonts used be reasonably expected to usually include most characters provided by those fonts? Though bug 488776 would probably provide some improvement much more easily.

Working with Phisit, he says it's fixed in Fx4 on Mac, and another community member confirmed it's fixed on Windows XP (haven't checked Vista or Win7 yet). This bug still exists on Linux in both the search and location bars.