Commit r78846 for Bug 54244 caused a regression when a table cell has a valign="top" attribute, the superscript tag (<sup></sup>) is used in the text in the cell, and other text in the cell has any other kind of tag.
* STEPS TO REPRODUCE
1. Load attached test case.
* EXPECTED RESULTS
The text (with the exception of the ® symbol) should all have the same baseline.
* ACTUAL RESULTS
The text that's outside of any tag (except <TD></TD> tags) has the wrong baseline.
This is a regression from r78846. The autospade script said r78842 worked and r78846 failed, but the only commit in that range that makes sense is r78846.
Compare attached screenshots by switching between tabs to see which text should be lower. (The text of the test case is a bit misleading.)
Created attachment 107367 [details]
The changes to InlineFlowBox::adjustMaxAscentAndDescent() (consulting verticalAlign() instead of logicalTop()) are possiblly at fault here.
Created attachment 107368 [details]
Created attachment 107369 [details]
This is still unfixed two years later.
It was recently reported at
and I've added a comment there linking to this page.
Created attachment 214973 [details]
There seem to be two bugs present:
- the incorrect baseline rendering of the majority of fonts in a table td with vertically-aligned bold or italic content;
- the amplification of such baseline errors, for any font, when superscript tags are used.
The bug is not apparent in Internet Explorer, Opera or Firefox, but does occur in Safari 5.1. The bug is partially present in Safari 6 on Mac and Chrome 30 on Unix. The bug appears to be dependent on operating system.
I attach a screenshot.
just adding a note that I run into this on occasion as i do a lot of html emails using table-based layouts for use in exact target, campaigner, etc.
This bug now seems to be fully resolved with Chrome 46. See https://code.google.com/p/chromium/issues/detail?id=135657