197129 - Large characters that overflow their frame (e.g. trailing serif F) leave a trail

Status: RESOLVED DUPLICATE of bug 96041

(Core Graveyard :: GFX: Win32, defect, P1)

Description

[Charles Rosendahl]

Steps to reproduce:
===================
1. Launch Composer
3. Make sure you are in Times New Roman
4. Increase your font size to about 18pt (use the "+A" button)
5. Type a bunch of f's (ie: "fffffffffff")
6. Put your cursor into the middle of the word 
7. Press the delete key a few times

Expected behavior: The white space at the end is blank.

Observed beahvior: The last 'f' is leaving pieces behind.  This only happens
with Times (a serif font) and when the point is 18+.  This also only happens
with the letter 'f'. (Haven't checked any other languages besides English).

Comment 1

[Christopher Hoess (gone)]

->Views (painting problem)

Comment 2

[Simon Fraser [no longer active]]

It's not views. It's text drawing outside of the frame bounds.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

How about Gfx:Win32?  Although one might consider it a font bug.

Comment 4

[Simon Fraser [no longer active]]

No  :)

I think gecko uses the correct bounding box for the font, but fonts are allowed
to have glyphs that extend outside of the normal bounds. There are APIs to get
the max extent of the glyphs; gfx/frames need to use these to find out if text
extends outside of the frame boundaries, and layout needs some way to allow
frames to invalidate rects larger than their bounds.

Comment 5

[Simon Fraser [no longer active]]

I think Mac will have to use this OutlineMetrics call:
http://developer.apple.com/techpubs/macosx/Carbon/text/FontManager/Font_Manager/fm_ref_chap/index.html

we need to get the yMin and yMax out of there.

Comment 6

[Simon Montagu :smontagu]

The Windows equivalent is GetOutlineTextMetrics, which returns an
OUTLINETEXTMETRIC structure
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_569e.asp

That includes two bites at the cherry, otmAscent and otmDescent, and
otmMacAscent and otmMacDescent. We already use otmDescent internally to
calculate the position of underlines, btw.

Comment 7

[Kevin McCluskey (gone)]

I think these two bugs are related to this bug: bug 96041, bug 106101. Making
them dependent on this bug.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't think bug 106101 is related -- I think that's about which font's metrics
we use when multiple fonts are used to display the text.  This bug and bug 96041
are about glyphs that overflow the font's metrics horizontally -- we need a GFX
API for that information and then nsTextFrame needs to use that API when setting
nsHTMLReflowMetrics::mOverflowArea (and calling nsFrame::StoreOverflow).  I
think our current APIs use the bounding box for vertical stuff already, so
there's not an issue of vertical overflow.

I don't see any reason this bug shouldn't be marked as a duplicate of bug 96041.

Comment 9

[Simon Montagu :smontagu]

*** Bug 210398 has been marked as a duplicate of this bug. ***

Comment 10

[rbs]

re: comment #8
Such APIs already exist, BTW. These are the #ifdef MOZ_MATHML GetBoundingMetrics
that MathML uses for its precise placements (the bounding metrics is a struct
allowing us to get the "plain" and "overflow" areas to deal with all
situations). It is what each platform that wishes to support MathML is required
to implement. The latest in the series was Xft. C.f. bug 128153 comment 30 for
quick reference & illustrative screenshots showing indeed the differences
between the CSS rect metrics and the precise bounding metrics.

This is indeed a dup of bug 96041.

[I have mentioned in the past that mRect is way too restrictive as a basis for a
modern layout engine (it locks the _thinking_) and that switching to mArea might
be a better basis. Then one could argue that mArea has to be a circle, polygon,
bounding metrics, or whatever, but the point being that it will help think out
of the vanilla rect, and extra information could be stashed in a much more
natural and forward looking manner (e.g., to meet those peculiar demands of CSS3).]

Comment 11

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 12

[Martijn Wargers (dead)]

*** Bug 271043 has been marked as a duplicate of this bug. ***

Comment 13

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** This bug has been marked as a duplicate of 96041 ***