Note that the highlights only indicate the most obvious issues. Rows in XL are 12.75 pts/17 pixels tall while in gnumeric they are 8.25 pts/11 pixels. Font size is the same (10).
Looks like for all wrong rows ROW record has "0x00 0x01 0x0f 0x00" at the end, and for right rows it's "0xc0 0x01 0x15 0x00".
Special case is "0x40 0x01 0x15 0x00" -- this row is about the same incorrect in gnumeric and XL.
Bit F controls index to XF, which does nothing with row height.
So I believe bit E should be read like this:
"If row height was set manually, then take miyRw value for height,
otherwise match row height to the font size".
Interesting... It corrects all rows in the attached file, but only one in the file attached to #660605.
For this one text in B5:E5 is ellipsised, I didn't check what could be the reason for that yet.
When opening an xls files where lots of rows do not have hard (ie. user set) heights, this could theoretically be rather expensive but:
If I take a gnumeric sheet with 1M rows and fill the first column with a linear series (start=0, step=1) the filling takes a very long time. If I then select the whole sheet and choose autofitting of the row heights then that takes only about 2 or 3 seconds, and in this situation all 1M rows are being fitted (and undo information about the original row heights is being saved).
The patch would not save undo info so it would likely be slightly faster. As a consequence I would expect this patch to only increase loading time for a file by a tiny percentage.