Closed Bug 39833 Opened 25 years ago Closed 24 years ago

Text entry widgets are oversized when using t/type fonts

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: svassall, Assigned: bstell)

References

Details

Attachments

(3 files)

Screenshot of font & widget behaviour
105.41 KB, image/jpeg
Details
info requested ( xlsfonts ... )
3.45 KB, text/plain
Details
testcase
64 bytes, text/html
Details
Build : 2000051808 (Linux) If the fonts are set to be t/type equivalent fonts, rather that the adobe defaults then all the text entry widgets are oversized. To repeat, using the preferences dialog set the fixed-width fonts to be monotype -arial-iso8859-1. Then the widgets oversize. You may have to start mozilla in order to get the fonts to display correctly.
changing component to editor, reassigning
Assignee: trudelle → beppe
Component: XP Toolkit/Widgets → Editor
QA Contact: jrgm → sujay
I talked with Kin and he did some cursory debugging. It looks like buster is using some utility routines that rods wrote to calculate the size of input elements. If the font information they get back from the device context contains wrong info, it will definitely cause the wrong size. Handing this over to the font guru
Assignee: beppe → erik
Kin, Steve and Rod, would you please let me know which file to look at, to see where Steve is using Rod's routines? And the method names too. Thanks!
I don't believe Arial is available in non-proportional form. If the text entry boxes in forms call for monospaced fonts, it would be no surprise if things were sized very large; I would expect the size calculation to be based on the maximum character width, which is usually very big indeed in proportional fonts. Similar behavior is traditionally visible if you start xterm with a proportional font. Possibly the bug here is that the Preferences font dialog should be screening out unsuitable fonts for the Monospace selection.
The oversizing that I have seen does not occur in the X direction, but rather in the Y. This should not be related to any calculation of character width. Additionally as the readibility of t/type fonts under X is so much greater than with adobe fonts shouldn't users be able to set all their fonts to t/type; I believe that the same behaviour occurs if t/type courier is selected.
This does indeed seem to happen when the Monospaced font is set to either Courier New or Andale Mono for me (the only two monospaced TrueType fonts I have). (So I'm going to confirm this bug, just to keep the Unconfirmed bug count down and save later confirmers some work). Looking at font data with xlsfonts -ll, the only thing that jumps out at me is that in these fonts, the linespacing is smaller than the bounding box. I suspect that text field height is being determined from the max ascent/descent information (as I suspect it has to be) instead of from the line height. The real bug may then be the baseline offset within the text area, which (at least for single-line things) might want to be using the max ascent instead of the em height. I'm not sure how to deal with multi-line text areas. My off-the-cuff idea is to count height by using line height (Em height, I think, in the code), and then subtract one normal line and add on max ascent + descent to make sure that no font can paint outside the text entry area. Within it, lines would be spaced using the line/em height, except that the first and last lines should be using the max ascent and the max descent to offset themselves from the bounds. (This neatly turns into the previous case for a one line text box, I believe.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Stefan, would you please attach a screenshot of the oversized text field to this bug? Thanks.
Build no: 2000051808 (Linux - Xfree 4.0) The screenshot show the worst font behaviour that I managed to generate under mozilla. Not only has the URL bar lost its font settings, we have two different fonts displayed in text entry widgets. To repeat, start moz. (with default font settings). Go to bugzilla bug entry page. In the prefs change the font setting to use t/type equivalents, and arial (t/type) as the monspaced. The text widgets get oversized, and the url bar loses it's fonts (see screenshot); and some widgets change fonts, and some remain times-new-roman.
Build no. 2000051808 This problem seems to be more general than just widgets. If you set your fonts to t/type equivalents then most (not all) of the widgets and plain text increases it's line spacing; resulting in the whole page normally being streched in the Y direction. The whole issue can be neatly hightlighted (literally) by setting all your font prefs to t/type equivalents. Going to the bugzilla entry page, and using any text widget type some text in and highlight it. You will see that the highlight entends vertically over a much greater area that could ever be used by possible characters. Additionally the page will of grown! To reverse, simply reset to adobe fonts.
Stefan, thanks for the info. Please attach the output of the following: xlsfonts -ll -fn '-monotype-arial-medium-r-normal--16-*-*-*-p-*-iso8859-1' xlsfonts -ll -fn '-adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1'
In NavQuirks mode: nsGfxTextControlFrame::CalculateSizeNavQuirks get the FontMetrics and sets it into the rendering context, then calls nsFormControlHelper::CalcNavQuirkSizing to the calculation to figure out how big to be. Check the differences you get back in the FontMetric between one font and another.
I forgot to mention, when measuring the sizes of text fields and text areas compare them to Nav 4.x when in NavQuirks mode (pixel to pixel sizes). Don't think that setting "size=25" means they will show only 25 chars. Nav 4.x had a bizarre algorithm for calculating the size and the size can differe byquite a bit when a non-proportional font is used. Erik, call me for a long explanation.
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Hi Guys, Sorry it took so long to get you the info; work called! The above attachment contains the info that erik requested. If I can help any more give me a shout :-) Stef
Any further feedback on this bug?
reassign to bstell mark TM as ---
Assignee: erik → bstell
Status: ASSIGNED → NEW
Target Milestone: M17 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I don't think one is critical. mark it as future.
Target Milestone: mozilla0.9.2 → Future
This one breaks the layout on enough XFree86 4.0 setups for this bug to be important. Can you give me any more things I can do assist in solving this (that is, besides a patch) ?
the following would help me determine the cause (not necessarily the cure) 1) a very simplified html demo html 2) the output from mozilla when the environment variable NS_FONT_DEBUG is set to 5 and the demo page is run
Attached file testcase —
Here is the output after running the testcase with NS_FONT_DEBUG set to 5: ./mozilla/run-mozilla.sh ./mozilla/mozilla-bin file:/home/future/test.html MOZILLA_FIVE_HOME=/home/future/mozilla LD_LIBRARY_PATH=/home/future/mozilla:/home/future/mozilla/plugins:/usr/lib LIBRARY_PATH=/home/future/mozilla:/home/future/mozilla/components SHLIB_PATH=/home/future/mozilla LIBPATH=/home/future/mozilla ADDON_PATH=/home/future/mozilla MOZ_PROGRAM=./mozilla/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Registering plugin 0 for: "*","All types",".*" FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 FindStyleSheetGenericFont, nsFontMetricsGTK.cpp 3321 user pref font.name.sans-serif.x-western = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3493 TryNode aName = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3095 load font monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 2675 loaded -monotype-arial-medium-r-normal--16-*-*-*-p-*-iso8859-15 FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 familyName = helvetica, nsFontMetricsGTK.cpp 3223 TryFamily cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 3170 load font cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 2675 loaded -cronyx-helvetica-medium-r-normal--17-120-100-100-p-67-koi8-r FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 FindStyleSheetGenericFont, nsFontMetricsGTK.cpp 3321 user pref font.name.sans-serif.x-western = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3493 TryNode aName = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3095 load font monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 2675 FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 familyName = helvetica, nsFontMetricsGTK.cpp 3223 TryFamily cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 3170 load font cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 2675 FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 familyName = helvetica, nsFontMetricsGTK.cpp 3223 TryFamily cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 3170 load font cronyx-helvetica-koi8-r, nsFontMetricsGTK.cpp 2675 loaded -cronyx-helvetica-bold-r-normal--17-120-100-100-p-67-koi8-r FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 FindStyleSheetGenericFont, nsFontMetricsGTK.cpp 3321 user pref font.name.sans-serif.x-western = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3493 TryNode aName = monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 3095 load font monotype-arial-iso8859-15, nsFontMetricsGTK.cpp 2675 FindFont(a/0x0061), nsFontMetricsGTK.cpp 3630 FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3212 FindStyleSheetGenericFont, nsFontMetricsGTK.cpp 3321 user pref font.name.monospace.x-western = monotype-courier new-iso8859-15, nsFontMetricsGTK.cpp 3493 TryNode aName = monotype-courier new-iso8859-15, nsFontMetricsGTK.cpp 3095 load font monotype-courier new-iso8859-15, nsFontMetricsGTK.cpp 2675 loaded -monotype-courier new-medium-r-normal--13-*-*-*-m-*-iso8859-15 Document file:///home/future/test.html loaded successfully
are you still specificing -arial-iso8859-1 for monospace? What is your encoding? Any idea why these fonts are being loaded? -monotype-arial-medium-r-normal--16-*-*-*-p-*-iso8859-15 -cronyx-helvetica-medium-r-normal--17-120-100-100-p-67-koi8-r -cronyx-helvetica-bold-r-normal--17-120-100-100-p-67-koi8-r -monotype-courier new-medium-r-normal--13-*-*-*-m-*-iso8859-15 Is there a place where one can download the font?
Upon reloading the page, only monotype-arial-iso8859-15 (my Sans-Serif font => prefered font for text) and monotype-courier new-iso8859-15 (my Monospaced font => font for the input widget -- and as visible on screen, the widget does use Courier New) are loaded. It leads me to believe the koi8-r fonts are loaded by the XUL (I'm not sure why it prefers the 'cronyx' foundry over the 'adobe' one). The fonts are served by XFree86 4.0.3's FreeType module. My encoding is Western (ISO-8859-1), and my Cyrillic fonts are set to Arial and Courier New too anyway.
You can download Arial and Courier New from http://www.microsoft.com/typography/fontpack/default.htm Use 'cabextract' (http://www.kyz.uklinux.net/cabextract.php3) to extract the EXEs and ttmkfdir to generate the fonts.dir file. The KOI8-R Helvetica and Courier from the Cronyx foundation can be found with XFree86 4.0 distributions (possibly separately in a Cyrillic fonts package).
The problem seemed to have magically disappeared in 0.9.4. BUT for some reason, single-line input boxes and buttons seem to use the regular font ("Arial" on my setup) instead of the monospaced font.
*** Bug 53492 has been marked as a duplicate of this bug. ***
Yup, no longer seems reproducible in 0.9.4, even if I manually set the "input" tag font to the same font as the "textarea" tag in userContent.css. Consider WORKSFORME or FIXED.
changed status to WORKSFORME per the last comments
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified on my new Linux box.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: