21616 - Space after ::first-letter pseudo-element line is larger than between other lines

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, enhancement, P3)

Description

[Christine Hoffman]

Using 12/10 build on Win 95, Mac8.5 and Linux Red Hat 6.0 (Linux2.2). Behavior
is across board (although not as pronounced in Linux)

Steps to reproduce:
Open attached file in 5.0. This is an example of :first-letter pseudo-element.

Expected result: The first letter in the paragraph should have a font size of
.5in and should be blue. Space between lines should be equal.
Actual result: The first letter has a font size of .5in and is blue, but the
space between line 1 and 2 is larger than between 2 and every line after.

I am writing this up as a bug because of what I believe a user would expect. The
descender line causes the second line to be pushed down. This creates a larger
line between lines 1 and 2 than between lines 2 and 3 and so on. I think the
user would expect to see the same space between lines 1 & 2 and every line
after.

Comment 1

[Christine Hoffman]

Attachment: testcase to demonstrate problem

Comment 2

[Pierre Saslawsky]

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

Comment 3

[Pierre Saslawsky]

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

Comment 4

[Pierre Saslawsky]

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

Comment 5

[Pierre Saslawsky]

It's a layout problem: the larger space between the two lines corresponds to the
'descent' of the first character. It means that when we display an uppercase
character or a lower-case character that doesn't have a descent (not g, j, p,
q...), we should not increase the space between lines. Of course this should be
valid for any case, not just the first letter. Problem: I don't know how that can
be fixed for international character sets because on some platforms, it's not
possible to tell what is the actual descent of a particular character.

There is another problem with the 'first-letter': if we make it a floating
element, the top of the first letter is not aligned with the top of the rest of
the line. See the new testcase that I'm going to attach.

Reassigned to Troy.

Comment 6

[Pierre Saslawsky]

Attachment: a new testcase for normal/floating elements

Comment 7

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

The current behavior is correct according to the spec.  However, there has been
some discussion (in private email) about changing the spec (only as it relates
to :first-letter, not other things) -- I don't know what will come of it.

Pierre - CSS *does* describe an inline formating model, and the test case you
wrote completely disagrees with that model.  Frankly, doing what you want would
be both contrary to the spec and probably very slow (would require checking
metrics on every single character displayed).

The "user" (i.e., author) could fix this problem by giving a small line-height
to :first-letter styles known not to have descenders.

Comment 8

[Pierre Saslawsky]

Closing as invalid since the current behavior is correct.

Comment 9

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

I'm actually going to reopen this one because I just found a little sentence in
the CSS2 spec about this, in 5.12.2.  It says, "In order to achieve traditional
drop caps formatting, user agents may approximate font sizes, for example to
align baselines.  Also, the glyph outline may be taken into account when
formatting."

I'm not sure whether these apply to floating :first-letter (drop caps) only, or
also to non-floating ones (initial caps).  This would mean Pierre's 3d test case
can be fixed, somehow, and possibly Chris's original (which is Pierre's 1st).

I don't think Mozilla's currently has interfaces to get per-character font
metrics, but I think someone may be working on it for MathML.  This might be
able to benefit from that work.

Comment 10

[rbs]

The code that is doing the positioning (kid->MoveTo) and the
sizing (kid->SizeTo) for the first letter-frame is located at:
lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsFirstLetterFrame.cpp#248

If one plays around with the parameters, e.g.,
    kid->MoveTo(aPresContext, bp.left - 100, bp.top),
then different behaviors can be observed.

However, it is not clear to me what to do in all particular
cases, i.e., assuming one has the *exact bounding metrics* for the
first-letter. Then what next?

From the attachments, it seems there are many sub-cases that
have to be enumerated. Also, the size of the next sibling of the
first-letter frame (the remaining letters may not be the default
font size) is likely going to play an important role.

Do you have screenshots (examples in your CSS collections) for
the suggested renderings for normal/strange situations.

For MathML purposes, I am in the process of asking a slight extension
of the reflow metrics, so that a Reflow() operation may also return the
exact bounding metrics if desired (the proposal is similar to the way
the maxElemenSize behaves). This means that by setting a non-null pointer
in the reflow metrics, the exact bounding metrics will be available
when doing the positioning/sizing of the first-letter frame.
However the proposal is just a hook for now (with the assumption
that the primary use will be in the MathML corner). It will need
further consolidation to work in general.

Regarding your comments about per-char info, the interface that provides
precise glyph outlines is GetBoundingMetrics(). If you think worthwhile,
then it may perhaps be appropriate to include that piece of code in the
default build? It will provide other info like xheight as discussed in
other bugs. However, someone needs to code for Mac and other Ports, which
the current contributors to the MathML effort don't have access to...

Comment 11

[buster]

mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Comment 12

[Pierre Saslawsky]

Thanks for digging into the specs, David. I'm glad they reveal enough common
sense to allow us to fix the most common cases (#1 and #2 in the attached
testcase).

I volunteer to do any kind of Mac-specific work for GetBoundingMetrics().

Comment 13

[rbs]

Attachment: Screenshot 16K: Results of GetBoundingMetrics() on the elements

Comment 14

[rbs]

The screenshot (obtained on Win32) shows how GetBoundingMetrics can be used to
obtain precise glyph outlines. Once this information is known, what to do?
This remains to be defined. The hack that produces the bounding boxes uses
the slight extension of the reflow metrics that I mentioned earlier. i.e.,
if a pointer is non-null when firing the Reflow(), the child frame (TextFrame)
will compute the bounding metrics in addition to the other current reflow
metrics. I am behind a firewall which doesn't give access to cvs for a diff.

The other example with BIG is strongly implying that GetBoundingMetrics() and
the extension to Reflow() have to be better integrated in the Gecko system in
general.

Comment 15

[rbs]

Pierre, the API for GetBoundingMetrics() is in nsIRenderingContext.h.
The struct nsBoundingMetrics is defined at the bottom of that file as well.
The API is currently implemented on Win32, GTK, Xlib (the code is #ifdef
MOZ_MATHML within nsFontMetricsXXX.cpp and nsRenderingContextXXX.cpp).

Comment 16

[rbs]

Attachment: Patch: code used to produce the bounding boxes on the screenshot

Comment 17

[rbs]

+   nscoord gap = 0; // a left-over ... discard
====
* The patch adds another data member called boundingMetrics in
  nsHTMLReflowMetrics. It is defaulted to nsnull in the constructor so
  as to not disrupt existing code. (Hence the burden is on users of the
  extension. They must exercise great care when using the extension.)

* The change in nsFirstLetterFrame.cpp ensures that a non-null pointer
  is passed when calling Reflow(). This allows the first-letter to get
  the exact bounding metrics upon completion of reflow. As a proof-of-concept,
  the information is used later to draw boxes around the letter.

* The change in nsLineLayout.cpp ensures that nsLineLayout
  honours the non-null pointer that is passed in Reflow().
  However, nsLineLayout keeps track of the metrics (pfd->Bounds)
  in a way that doesn't allow smooth adjustments from
  "outside" (I added some comments to that effect in the code).

* The change in nsTextFrame.cpp enables to compute the
  Bounding Metrics which is returned to the caller.

Comment 18

[rbs]

Troy has given the go-ahead to checkin. I am back behind the fireall and
will be holding my changes with other changes in the mathml dir. Once
possible, I will check in the portion that is relevant to MathML
(the changes that are in nsIFrame and nsTextFrame). These changes will
be within #ifdef MOZ_MATHML.

David, I re-read your comment saying that the problem with BIG letters
is best addressed by authors. Yes, they can use a small line-height when
they see for themselves that the BIG letters under consideration do no have
descenders. That's what to do...

So, in this case, we should only concentrate on beautifying the :first-letter...

Comment 19

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

Does your checkin change anything other than :first-letter?  (I don't fully
understand the comments about nsLineLayout.)

Comment 20

[rbs]

Actually, the checkin will not be related to :first-letter (i.e., the
portion of the patch that applies to nsFirstLetterFrame and nsLineLayout
will not be checked in). Since we need the extension in MathML, I will be
checking in the portion that is useful for the MathML effort to get going.

Because the extension looks like something to be considered in a more
general context, Troy said to wait a little bit (until after the holidays)
regarding the :first-letter situation (and possibly other applications).

nsLineLayout is a class which, amongst other things, handles certain operations
on behalf of other classes. To do so, nsLineLayout uses some (temporary)
variables. In the case of the :first-letter, it was needed to ensure that the
(newly-added) non-null pointer was understood by nsLineLayout. Also,
nsLineLayout has an internal state in which it keeps (amongst other things) the
max-ascent/max-descent of frames. So in the case of the :first-letter, it is
keeping track of the (coarse) font-ascent and font-descent that we would like
to replace by the other (fine) metrics that boundingMetrics provides.

Comment 21

[rbs]

Useful Pointer for Glyph Measurements on the Mac:
http://www.devworld.apple.com/techpubs/mac/Text/Text-186.html

Comment 22

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 23

[Hixie (not reading bugmail)]

There are some other comments on first-letter looking ugly in bug 23844, in
particular about the floating case.

Comment 24

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 25

[Matthew Brealey]

David Baron wrote:
"In order to achieve traditional drop caps formatting, user agents may 
approximate font sizes, for example to align baselines.  Also, the glyph outline 
may be taken into account when formatting."

I'm not sure whether these apply to floating :first-letter (drop caps) only, or
also to non-floating ones (initial caps).  This would mean Pierre's 3d test case
can be fixed, somehow, and possibly Chris's original (which is Pierre's 1st).

---
If it meant initial caps, it would say initial caps. Although 23844 is fixable 
in accordance with the spec (although with great difficulty), to fix this 'bug' 
would be to create an area of incompliance with the spec; i.e., a bug. The bug 
is INVALID.

Comment 26

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

This bug is valid, in so far as it applies to floating first-letters.

Comment 27

[Pierre Saslawsky]

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

Comment 28

[Pierre Saslawsky]

I just closed 23844 as dup of this one but I'm going to move one of its testcases 
here. It shows that the alignment can be wrong even though the first-letters are 
not floating (albeit not as wrong as the floating ones, but it may contribute to 
the problem). This problem is much more visible on Windows than on Mac. On Mac, 
the 96px letter (at the bottom of the page) is 6 pixels too low. On Windows, it 
is about 16 pixels too low. Something must be wrong in the text height 
calculation in WinGFX.

Comment 29

[Pierre Saslawsky]

Attachment: testcase for non-floating first-letters at different sizes (more visible on Windows than Mac)

Comment 30

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

As I've said before, I believe we handle the non-floating case correctly,
although I'm curious about the platform differences.  (The floating case is also
correct, but can be changed within the limits of the spec.)

Comment 31

[rickg]

moving all buster m15 bugs to m16.

Comment 32

[buster]

I'd like to look into this before FCS, but there's no chance for me to spend 
time on it before beta2.  Moving to M19.  There is a lot of good analysis in 
this bug, but we'll certainly need to agree on specific behavior before we start 
changing code.  It would be great if someone could write a good specification 
for what ought to happen.  A lot of what is needed is scattered throughtout the 
CSS 2 spec, the comments in this bug, and the test cases attached.

Comment 33

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 34

[buster]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 35

[Hixie (not reading bugmail)]

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.

Comment 36

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 37

[Shanjian Li]

Add myself to cc list.

Comment 38

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 39

[Boris Zbarsky [:bzbarsky]]

.

Comment 40

[Bill Mason]

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

Comment 41

[louis bennett]

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

Comment 42

[Boris Zbarsky [:bzbarsky]]

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

Comment 43

[rbs]

Attachment: fix based on MathML's GetBoundingMetrics

GetBoundingMetrics has been around on the major platforms for some time now.
Here is a fix that does the trick. It falls back on the old code if
GetBoundingMetrics fails (or isn't there).

Comment 44

[rbs]

Attachment: screenshoot showing how ::first-letter how looks like with the fix

Comment 45

[rbs]

Comment on attachment 166184 [details] [diff] [review]
fix based on MathML's GetBoundingMetrics

Asking r/sr to beautify ::first-letter by default at little cost (since MathML
is on by default these days).

Comment 46

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 166184 [details] [diff] [review]
fix based on MathML's GetBoundingMetrics

r+sr=bzbarsky, and could you file a bug on making GetBoundingMetrics either
have its own ifdef (implied by MOZ_MATHML) or just be always defined?

Comment 47

[rbs]

Checked in.

Filed bug 270315 to make GetBoundingMetrics mainstream.