Open Bug 157541 (CTL-render-textfield) Opened 18 years ago Updated 4 years ago

need more height in textfield/location bar to fully display non-base-level characters

Categories

(Firefox :: Theme, defect, minor)

defect
Not set
minor

Tracking

()

People

(Reporter: arthit, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug, )

Details

(Keywords: intl)

Attachments

(14 files)

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". **
Blocks: thai
katakai-san:  can you own this Solaris bug?
Assignee: yokoyama → katakai
Keywords: intl
QA Contact: ruixu → ylong
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?
Alias: kakakakala
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.
Alias: kakakakala → CTL-render-textfield
Summary: Thai below-level characters doesn't instantly displayed in textfield → CTL's (e.g. Thai) below-level characters don't instantly displayed in textfield
Attached image possible solution
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" ...
Component: Internationalization → 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.
Keywords: uiwanted
OS: Solaris → All
Hardware: Sun → All
Summary: CTL's (e.g. Thai) below-level characters don't instantly displayed in textfield → not enough foot room in textfield/location bar to display lower-level (part of) characters
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.
Assignee: masaki.katakai → nobody
Component: Layout: CTL → Theme
Product: Core → Firefox
QA Contact: amyy → theme
This is a Firefox theme bug. Should be pretty easy to fix.
Flags: blocking-firefox3?
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.
Flags: blocking-firefox3? → blocking-firefox3-
BugAThon Bangkok

severity: normal -> minor


note: Official support language like "Gujarati" do has this problem too.
Severity: normal → minor
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:  กู่ฐิ์ 
Summary: not enough foot room in textfield/location bar to display lower-level (part of) characters → need more height in textfield/location bar to fully display non-base-level characters
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.
Depends on: 453827, 481751, 91190
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.
Depends on: 488776
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.
my favorite site is bug
http://xn--12c8da9af6jya6b6a.net/
You need to log in before you can comment on or make changes to this bug.