Arthit Suriyawongkul Reporter
	Description • 22 years ago

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".

	Arthit Suriyawongkul Reporter
	Comment 1 • 22 years ago

correction:

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

	Roy Yokoyama
	Comment 2 • 22 years ago

katakai-san:  can you own this Solaris bug?

	Prabhat Hegde
	Comment 3 • 22 years ago

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.

	Masaki Katakai
	Comment 4 • 22 years ago

Prabhat/Arthit,

Can you attach screen shots? wrong image and correct image on textfield and text
area?

	Arthit Suriyawongkul
	Comment 5 • 22 years ago

base-level char missing from view point

	Arthit Suriyawongkul
	Comment 6 • 22 years ago

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)

	Arthit Suriyawongkul
	Comment 7 • 22 years ago

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

	Arthit Suriyawongkul
	Comment 8 • 22 years ago

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.

	Arthit Suriyawongkul Reporter
	Comment 9 • 22 years ago

to make it possible to cover all character in every display-level,

- enlarge the textfield
or
- small down the font size

	Roland Mainz
	Comment 10 • 22 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 11 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 12 • 17 years ago

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.

	Keng Susumpow
	Comment 13 • 17 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 14 • 17 years ago

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

	Keng Susumpow
	Comment 15 • 17 years ago

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?

	Isriya Paireepairit
	Comment 16 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 17 • 17 years ago

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).

	Keng Susumpow
	Comment 18 • 17 years ago

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

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 19 • 17 years ago

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.

	Arthit Suriyawongkul Reporter
	Comment 20 • 17 years ago

BugAThon Bangkok

severity: normal -> minor


note: Official support language like "Gujarati" do has this problem too.

	Arthit Suriyawongkul Reporter
	Comment 21 • 17 years ago

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:  กู่ฐิ์ 

	Arthit Suriyawongkul Reporter
	Comment 22 • 17 years ago

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)

	Arthit Suriyawongkul Reporter
	Comment 23 • 17 years ago

a Theme bug or a XUL widget bug ?

	Keng Susumpow
	Comment 24 • 16 years ago

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?

	Isriya Paireepairit
	Comment 25 • 16 years ago

Works for me on Ubuntu 8.10a6 fresh install

	Arthit Suriyawongkul Reporter
	Comment 28 • 15 years ago

(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.

	Arthit Suriyawongkul Reporter
	Comment 29 • 15 years ago

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, 'ป')

	Banphot Nuchleang
	Comment 30 • 15 years ago

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.

	Karl Tomlinson (:karlt)
	Comment 31 • 15 years ago

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.

	Gen Kanai [:gen]
	Comment 32 • 15 years ago

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

	Jonathan Kew [:jfkthame]
	Comment 33 • 15 years ago

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...

	Jonathan Kew [:jfkthame]
	Comment 34 • 15 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 35 • 15 years ago

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?

	Karl Tomlinson (:karlt)
	Comment 36 • 15 years ago

(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.

	Dietrich Ayala (:dietrich)
	Comment 37 • 14 years ago

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.