17503 - vertical placement of text in widgets is wrong

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, enhancement, P3)

Description

[ji]

Build: 1999102808
OS: RH6.0

This is a generic problem for all the text field widgets on RH6.0.
The problem is that the text entered in the text field is not
displayed in the center of the widget. For ascii characters, they
look okay except that the characters are located in the higher part
of the widget. But for the double-byte characters, not the whole
characters are displayed. The upper part of the double-byte characters
are cut off.

Steps of reproduce:
1. Open a new mail compose window.
2. Enter a Japanese character in the subject field.

You'll see the upper part of the character is cut off.

Comment 1

[Peter Trudelle]

That's Editor, not an XPToolkit widget.

Comment 2

[ji]

Sorry.
Changed the component to XP Toolkit/Widget

Comment 3

[leger]

Bummer...putting on PDT+ radar.

Comment 4

[Katsuhiko Momoi]

For some reason, the component got changed back to XPTool Kit. Now it's back to Editor.

Comment 5

[rubydoo123]

assigning this one to Frank.

Comment 6

[Frank Tang]

I think this is a generic text field issue. Reassig this back to buster.
Erik- could you also take a look at this. Is that possible we use bigger
Japanese font w/ smaller ASCII font which have smaller matrix that cause this ?
If so, please reassign that to yourself. Thanks.

Comment 7

[Frank Tang]

ji- is there a better test cases which will show the same problem in html form?
We should provide test cases which do not require input method installed if
possible. If the html form show the same problem. Please attach the html pages
which have pre set Japanese in the URL field above. This way, editor engineer
who do not have input method install can also investigate the problem. Thanks.

Comment 8

[Erik van der Poel]

Normal English text is being displayed too high in the text field.
(owner: buster?)

The fact that Japanese characters end up being too big and truncated at the top
is a separate problem. (owner: erik; see 13578)

Comment 9

[ji]

Attachment: testing html file

Comment 10

[ji]

attached html is a bugzilla page with a mixed string of ascii and Japanese
characters in the URL text field.

I think it might be caused by both of the reasons: ascii text is being displayed
too high in the text widget and Japanese characters are being displayed too
big. If you look at the location field of the browser, you'll see the url entered
in the text field is higher than the "Search" text on the right.

Comment 11

[Katsuhiko Momoi]

Attachment: Pre-filled form with mixed ASCII & JPN strings

Comment 12

[buster]

the 10/29/99 10:39 test case doesn't show the problem.  it shows "abcABC"  I'll
added a screen grab of the results in the latest M11 build.

Comment 13

[buster]

Attachment: this is an image of the previous test case, no good.

Comment 14

[buster]

Attachment: whoops, here's the image I meant

Comment 15

[Katsuhiko Momoi]

I suspect that you don't have Japanese fonts on your system.
Here's what it shoud look like (by displaying it now on yesterday's Win32 build.)

Comment 16

[Katsuhiko Momoi]

Attachment: Image of a prefilled form.

Comment 17

[buster]

is there some fairly easy way to load japanese fonts on my NT box?  ftang,
momoi?  know anybody who can help me do this if it's hard?

Comment 18

[buster]

is there any way you could supply an image for what it ought to look like?  this
may help me determine if it's really a centering problem, or maybe an
ascent/decent problem in the style context.

Comment 19

[Katsuhiko Momoi]

The image I supplied at: 11/10/99 15:10  is what it should look like. The reported problem is on Linux and
on Windows, it looks better.

To install a Japanese font (Bitstream Cyberbit) on Windows, follow the=se steps:

1. Get Bitstream Cyberbit font:

http://rocknroll/users/momoi/publish/Fonts/BitstreamUnicode/V2.0/Cyberbit.ZIP

2. Unarchive it and put it somewhere temporarily.
3. Use Controkl Panel | Font | File | Install New Font  menu to select this font and install.
4. Once this is done, Mozilla will pick up this font and begin displaying all the languages this font
   supports without yo doing anything. (Note: If a web page is not labeled, you need to use View | Character Set
   menu to set en encoding.)

Comment 20

[Katsuhiko Momoi]

I'm not saying that on Windows, it is perfectly centered. But at least you see all the parts of each font glyph.

Comment 21

[Simon Fraser [no longer active]]

Cc:ing rods, in case there are some CSS issues here.

Comment 22

[Erik van der Poel]

I think it's important to realize that we are talking about several different
problems here. The one that Steve should be most concerned about is the fact
that plain English text is displayed too high in text fields (eg URL bar) both
on Linux and Windows. Steve, I would urge you to concentrate on this problem
initially, rather than installing a Japanese font and using that.

There are 2 other problems on Linux with Japanese text. One problem is that
Japanese fonts on Linux are large and not scalable. So the Japanese text ends
up being larger than English text.

Another problem is that the Unix GFX currently tries to solve the Japanese
underline problem (underline intersects Japanese and is ugly) by raising the
Japanese text. This contributes to the truncation problem mentioned in this
report.

I must emphasize that we ought to look at the English centering problem first.
Let's attack this problem one piece at a time. Divide and conquer.

Comment 23

[Erik van der Poel]

So, Steve, I could help you if you tell me what code to look at. Specifically,
is there any code that attempts to center the text? Or are you simply relying
on the underlying layout engine to place the first line of text at the right
position? It may be using the ascent or max ascent of the font to place the
text, without taking the line-height (i.e. including leading) into account.

Where is the code that determines the vertical height of a single-line text
field? Is there any padding? Is the padding supposed to be both above and below
the text? Are we forgetting to add the padding to the ascent, so that the
padding disappears above the text, and it looks too high?

Comment 24

[buster]

erik:  your plan of attack sounds good.  I'll get you some detailed answers to
your questions this afternoon.  Any help would be greatly appreciated.

Comment 25

[Frank Tang]

Buster-
1. Do yo have a linux box ? Every Linux box come w/ japanese font installed.
2. Just concentrate on the fact the base line is too high.

Comment 26

[Erik van der Poel]

I just discovered some inconsistencies between the Windows and Unix versions of
Mozilla. The height and ascent related fields are not being interpreted in the
same way. More details to follow.

Comment 27

[leger]

If we get a workaround, we can move to PDT-.  Assigning to erik per bobj.  erik,
please see bobj, he has some ideas.

Comment 28

[bobj]

If we can just make the vertical padding in text fields larger as a workaround,
then this would no longer be a dogfood PDT+ bug.  If that is easier than
fixing it for M12, we should just do that, and then reassign to buster to do
the real fix.

Comment 29

[Erik van der Poel]

I have come up with a fix to make the height-related fields follow the Windows
version more closely. In addition, I have come up with a temporary fix to make
the fonts larger in CJK (East Asian) locales. In the future, we should modify
the layout engine to take large fonts into account. This may be non-trivial.

Comment 30

[Erik van der Poel]

By the way, even plain English text on Windows is still not centered correctly,
so I will re-assign this bug to buster after I have checked in the fix for the
Unix font height stuff and CJK hack.

Comment 31

[Erik van der Poel]

I have checked in the temporary fix for East Asian text on Unix. I have also
logged a new bug so that we can work on the real fix:

  http://bugzilla.mozilla.org/show_bug.cgi?id=20394

Re-assigning this bug back to buster, so that he can look at the English
centering problem (which happens even on Windows). However, I believe this
problem is not DOGFOOD and not PDT+. Please re-evaluate.

Comment 32

[buster]

erik says this is no longer PDT+.  cc'ing jar and jan so they can re-evaluate
with PDT team.  If PDT+ is indeed removed, please set to M14 as well.

Comment 33

[rubydoo123]

Steve, I'm setting this to M14 for you and removing the PDT+

Comment 34

[leger]

Putting on PDT- radar.

Comment 35

[rubydoo123]

taking off dependency of 12658

Comment 36

[rubydoo123]

updating summary fields, removing PDT- and [dogfood]

Comment 37

[buster]

There's an assumption here that the text within a single line text control
should be centered regardless of the height of the text control.  This is
certainly the case if you do not specify the height, since a single line text
control is by default one line tall.  But there isn't anything in the CSS spec
that says that text within a text control is centered.  In fact, FWIW, in IE5 as
well as the current mozilla implementation, the text is flush upper left, just
as if the text control were a single line tall.

Single-line text controls are laid out as follows:
---------------------       <---- text control border-top
|                   |       <---- text control padding-top
|  ..............   |
|  .ABC         .   |       <---- text control content, by default
|  .            .   |       <---- below this first line is all the excess height
|  ..............   |
|                   |       <---- text control padding-bottom
|-------------------|       <---- text control border-bottom

This is how mozilla and IE5 both work.  Nav 4.x did not allow setting the height
of a text control, so there is no backwards compatibility issue.

I propose we leave this exactly as is.  Page authors who want the effect of
centered text in tall text controls can use padding-top to push down the text
content relative to the top edge.

As an enhancement, we could offer a new "moz-center" alignment attribute to get
centered vertical alignment.  But CSS-2 offers no clear way to
vertically center a block within another block, as would be needed to fulfill
this request.

If I understand Erik's comments correctly, the other problems reported in this
bug are either fixed or already described in other bugs.  So I'm marking this
REMIND, setting severity to "enhancement", and milestone to M20.  Erik, if I
misunderstood and there's still some problem that needs to be addressed, please
open a new bug or reopen this bug if you think that's more appropriate.

Changing component to HTML Form Controls.  This really has nothing to do with
the editor itself, it's a layout issue (I know, the line there is fuzzy.)

Comment 38

[Erik van der Poel]

Thanks for the info. I'll leave this bug marked RESOLVED REMIND for now, but I
still have a question (if I may). I didn't realize that the height of the text
control is set "externally". I thought that the height of a single-line text
control would be directly related to the size of the font inside it. That is
how I would like it to be, because then you could achieve "true" centering. Is
it too difficult to make the text control height depend directly on the font
size? Or undesirable for other reasons?

Comment 39

[buster]

Is the absence of a height style property, the text is centered according to
calculations that use the font metrics.  An explicit height property overrides
this default calculation.

Comment 40

[Erik van der Poel]

Do the single-line text fields in the product have an explicit height property?

Comment 41

[buster]

what do you mean by "in the product?"  I'm sure some XUL-based UI's set explicit
heights, and some don't.  cc-ing paul h. who would know better than I.

Comment 42

[Erik van der Poel]

I mean our own XUL/CSS. In Mozilla. If you don't set the height explicitly,
does the text control automatically assume that you want a single line?

Comment 43

[buster]

height and "number of lines" are totally independent.  "height" is a box layout
attribute. number of lines is as per HTML 4.0 spec:  <input> is by definition
single line, and <textarea> is multiple lines (as many lines as the content
requires.)  The height of a <textarea> can be explicitly set to the line height
of course, but that does not make it a single line text control, just a short
multi-line text control.

Comment 44

[hangas]

I am not aware of any place where we have height= in the xul or css for 
html:input type="text".  We do set min-height for html:input type="text" in the 
global.css file.  This min-height may be wrong and if so could be removed.  We 
would probably just have to confirm with german.

Comment 45

[bsharma]

Updating QA contact.

Comment 46

[Christopher Hoess (gone)]

REMIND is deprecated per bug 35839.

Comment 47

[Christopher Hoess (gone)]

seems effectively fixed.

Comment 48

[bsharma]

Updating QA contact

Comment 49

[Madhur Bhatia]

chaging QA contact to the default QA owner. Thx!