harold92 / flying-saucer

Automatically exported from code.google.com/p/flying-saucer
0 stars 0 forks source link

wrong "ex" calculation #54

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
*** This issue was imported from http://java.net/jira/browse/XHTMLRENDERER-305

It was reported by bago on 10.01.2010 20:41:25 +0100 and last updated in the 
previous bug tracker on 11.01.2010 02:45:23 +0100

Found in
Operating System: All
Platform: All

The priority for this issue at migration was Major.

Original description: 
SharedContext.getXHeight calculate the XHeight with a weird formula against the 
strikethrough. This doesn't seem to satisfy the regress test suite.

Switching from:

---
FSFontMetrics fm = getTextRenderer().getFSFontMetrics(fontContext, font, " ");
float sto = fm.getStrikethroughOffset();
float f = fm.getAscent() - 2 * Math.abs(sto) + fm.getStrikethroughThickness();
return f;

---
to

---
FSFontMetrics fm1 = getTextRenderer().getFSFontMetrics(fontContext, font, "x");
return fm1.getAscent();

---

Fixes this regress test suite:

t040302-c61-ex-len-00-b-a.html [FIXED]
t040302-c61-rel-len-00-b-ag.html [FIXED]
t100801-c548-ln-ht-02-b-ag.xhtml [FIXED]
t1507-c526-font-sz-02-b-a.xhtml [FIXED]
t1601-c547-indent-00-b-a.xhtml [IMPROVED]

I guess the current method has been the result of the "x" not existing in some 
font: can't we use the correct method and intercept if "x" does not exists and 
use the current method only in that cases?

Can you provide a font that show the issue with the missing "x" glyph?

Original issue reported on code.google.com by pdoubl...@gmail.com on 16 Feb 2011 at 9:47

GoogleCodeExporter commented 8 years ago
peterbrant wrote on 11.01.2010 02:45:23 +0100:
You'll get no argument from me that the current formula is weird, but the
suggested fix can't be correct (or more specifically it's only correct for the
Ahem font).

The ascent and descent returned from FSFontMetrics are the values provided by
the font and not based on the individual glyphs passed in the string.  It just
so happens that for Ahem these are the same.

I think your suggestion is a good one though: push the x-height calculation into
the TextRenderer implementation and base it off the actual size of 'x' (with
some fallback if it doesn't exist) (e.g. with getGlyphPixelBounds() for Java2D).
 This should be pretty easy to implement for all the supported output devices.

Original comment by pdoubl...@gmail.com on 16 Feb 2011 at 9:47