Open Bug 415506 Opened 12 years ago Updated 3 months ago

Floated ::first-letter is typographically misplaced

Categories

(Core :: Layout: Block and Inline, defect, P3)

defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(10 files, 2 obsolete files)

Attached file testcase
The 'F' is several pixels higher than the rest of the text.  I think it should be in line with the rest of the text.
For what it's worth, a few pixels higher is correct.  What I see with old Seamonkey builds is what looks like a regression from the move to either GTK2 or cairo; now on Linux the bottom of the 'F' is about lined up with the top if the 'o'.  Jesse, are you seeing a smaller offset than that?
Ok, what happens on my screen is as follows (which I THINK is the correct behavior):

It strips all the whitespace from the top and the bottom of the F, then aligns it with the top of the oo, whitespace included.

This causes the F to look higher than the other letters.  Try highlighting the letters, you see that the top of the graphical part of the F lines up perfectly with the top of where the highlight on the oo is.  I'm not 100% sure what the correct behavior should be but that's somewhat close to what I expect.
Ah, right.  Selection, good point.  I guess that's the usual "too much ascender space in the Linux default fonts on the off chance that someone will use a diacritical mark" thing...
What I'm seeing on Mac is a small offset.  The bottom of the 'F' nearly lines up with the middle of the 'o'.
Gecko (Mac) is doing †his correctly, I think. Although †he results are slightly different from WebKit and Opera. Gecko uses a different technique:

# 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.

http://www.w3.org/TR/CSS21/selector.html#first-letter

Adding a border around the first-letter shows that WebKit generates a much larger/taller box for the first-letter, pushing the character down. Using line-height to reduce the size of the box in WebKit shows the same behaviour (see test-case2).
Attached file test-case2
Duplicate of this bug: 416617
This is showing up on articles on http://www.lemonde.fr/
OS: Mac OS X → All
Hardware: x86 → All
We should really align the top of the first letter with the cap-height of the  font or something like that.
David,

The traditional typographical declaration says cap-height to cap-height for dropped initiale. But "something like that" is correct also, see rule 3 below. So the "something like that" should be baseline to baseline of last span line. (rule 2)

Other declarations:

1. If dropped initilale is smaller than the first 2 line, it must be raised
   initiale.

2. Baseline of dropped initiale must fit to baseline of that last span line
   of the text which one was reached by dropped initiale.

3. The dropped initiale cap-height must reach the first line's cap-height, or
   can be above of that, but never below.

4. The dropped initiale cap-height cannot be above than cap-height of virtual
   zero line of rendered text. In this case - when overflows - needs dropping
   again with one more line.

5. Dropped initiale has bottom accents (like ogonek) the line next to that
   must be egalised. This rule basically depends on the font's defined
   kerning.

6. The left-side (vertical zero line) of dropped initiale must fit to the
   text's vertical zero line.

Adjacent initiale: same rules except 5.

7. During printing at paged media the adjacent margin shows exclusively on
   the first page.

-----

David, I know you do adore when I always want to rewrite the w3 standard, but I do it again :)

There we are:

new css rules offers exclusively for :first-letter pseudo element:

initiale-type: raised|dropped|adjacent (deafult: raised)
initiale-egality: kerning|none (default: none) - means apply kerning or not.
initiale-lines: {decimal number}

this one requires explanation: we can define how many lines we want to catch with the initiale. if this value other than zero, the rendering algorythm automatically resizes the inintiale to fit it to the span lines' total height. Note :first-line pseudo element should have different rendered height than other lines, so this influences the behavior of this feature.

Anyhow w3c says UA can use own algorythm for it, while the "floated" first letter is not a float. But maybe it worths a w3c discussion for future usage of css4 perhaps, so I ask you needinfo.

If you like this idea, I can start preparing graphical samples what is valid and what is not with initiales.
Flags: needinfo?(dbaron)
The 1-7 rule is redundant a little.
2 and 3 implies 1.

Some clarify: rule6 means: the left side fits to characters without serifs. So left-side serifs are overfloving to left. (sry for my english mistakes)
This presentation contains embedded images.

How the dropped initiale behaves based on rule 1-6
Attached image one more invalid case (obsolete) —
I forgot 1 more invalid case (png image):

how ever fits to baseline of last span line's baseline, doesn't reach the cap-height of first line (rule 3), so invalid. This is the reason why we drop up.

So dropped initiale is always groving to upside - while baseline fits to baseline of last span line - until cap-height reaches the cap-height of "zero line". When reaches, redropped again. Height of the zero line is the normal text's height, not the first-line pseudo element's rendered height. This smells as an algorithm of implementation.
Attachment #8404291 - Attachment description: dropgraph.html → graphical presentation of dropped initiale
Attachment #8403907 - Attachment is obsolete: true
Attachment #8403890 - Attachment is obsolete: true
Raised initiale permanently depends on the kerning, it always must be egalised, especially at the text-bottom zone. Sample images in the attachment which one is valid or invalid.
Adjacent initiale is almost same as dropped initiale (same dropping rules) except it is permanently independent of kerning, there is no visual effect for it at all.

Serifs overflow to left based on the normal text.

Summary: the 3 algorithm is almost same.
Dropped initiale behaves in a same way with ogonek or at text-bottom zone as the raised initiale.
Same behavior for serifs at left side.
Same dropping mechanism for dropped and adjacent initiale.
Basical difference by using and applying kerning.
Raised initiale ignores drop and permanently accepts kerning.
etc.

I think i've finished with samples, it's ready to think forward based on the Comment 12
exceptions:

------

accents: by traditional usage of initiale it doesn't show up in a continuous text, usually it has empty lines at top, so normally there is enough space for accents.
So this behavior needs clarification. 
 - Permanently applying the text-top zone? (this is the current behavior of UNfloated letter)
 - Applying only if there is an accent? (this would be suggested)
 - Permanently ignoring the text-top zone? (this is the current behavior of floated letter)

------

issue: what happens when there is an inline-block element in the flowed text which one causes different height of that line than actual line-height value?
It doesn't influence the rule "baseline to baseline" and "cap-height to cap-height". If the calculating algorithm is a recursion it starts at first line and run line by line until it reaches the first "underflowing" status. At this point we can know the last status before it, and offset-bottom and offset-height of that status. So we can put the dropped/adjacent initiale by "stepping one back" to the correct line. This sounds either a recursion or an extended variant of 1preread (Knuth) algorithm.

issue: not enough line next to dropped/adjacent initiale. no problem, we should fill with virtual empty lines based on line-height value during calculating.

------

confusion: if name "initiale" causes confusion with the general css value "initial" we can use name "versal" for the initiale, in this case the new rules are:

 -moz-versal-type: raised|dropped|adjacent|?none
 -moz-versal-egality: kerning|none
 -moz-versal-lines: {decimal number}
 
shorthand sample is:

 -moz-versal: dropped kerning 5.5;
For padding reasons the serifs don't overflow to left.
But some interesting: serifs of letter T overflows to top
Contains accent sample as well.
http://figures.spec.whatwg.org/#wrap-side (22 July 2014 version)

good starting point for this enhancement :)

1 notice for this: the initiale's cap-height should fit to x-height exclusively when the first word doesn't overflow the x-height (but this is a very-very strict rule, so haven't added to rules1-7), anyway cap-height always fits to cap-height. Baseline is good at this example workaround.
a good workaround for an adjacent-cap with flex:

https://jsfiddle.net/utasir/vgfz13L1/
Spec is about to land nowadays, so I upgraded the title and the component

https://drafts.csswg.org/css-inline-3/#initial-letter-styling

I filed 1 issue for supporting the adjacent initial-letter as well:

https://github.com/w3c/csswg-drafts/issues/965

So it's almost complete :)
Component: Layout: Floats → Layout: Block and Inline
Flags: needinfo?(dbaron)
Summary: Floated :first-letter is misplaced → [initial-letter] ::first-letter is typographically misplaced
Please don't morph bugs into something different.
Summary: [initial-letter] ::first-letter is typographically misplaced → Floated ::first-letter is typographically misplaced
See Also: → 1552731
You need to log in before you can comment on or make changes to this bug.