Bugzilla

The 13px (aka 780 app unit) values seem to come from our usage of `nsFontMetrics::MaxDescent()` when we evaluate this expression:
```c++
	    nscoord fontAscent =
	        wm.IsLineInverted() ? fm->MaxDescent() : fm->MaxAscent();
```

That ends up getting us here:
```c++
	static gfxFloat ComputeMaxDescent(const gfxFont::Metrics& aMetrics,
	                                  gfxFontGroup* aFontGroup) {
[...]
	  return floor(std::max(minDescent, aMetrics.maxDescent) + 0.5);
	}
```
Here, `aMetrics.maxDescent` is 12.5 (the value we expect as our half-baseline), and it's what `std::max` chooses.  We then add 0.5 to get 13, and then floor the result, staying at 13 (i.e. we round to the nearest whole pixel value).  And then up the stack, we convert that back into app units and get 780.

So, tl;dr: we're are explicitly deciding against using a fractional-pixel-value for our central baseline (in the rounding "add-0.5-and-floor" logic in ComputeMaxDescent here).  So we use 13px as our central baseline for the line layout here, which is why we end up off-by-1px.

The 13px (aka 780 app unit) values seem to come from our usage of `nsFontMetrics::MaxDescent()` when we evaluate this expression:
```c++
	    nscoord fontAscent =
	        wm.IsLineInverted() ? fm->MaxDescent() : fm->MaxAscent();
```

That ends up getting us here:
```c++
	static gfxFloat ComputeMaxDescent(const gfxFont::Metrics& aMetrics,
	                                  gfxFontGroup* aFontGroup) {
[...]
	  return floor(std::max(minDescent, aMetrics.maxDescent) + 0.5);
	}
```
Here, `aMetrics.maxDescent` is `12.5` (the value we expect as our central baseline for `25px`-font-size text), and it's what `std::max` chooses.  We then add `0.5` and then floor the result, ending up at `13`. (i.e. we round to the nearest whole pixel value).  And then up the stack, we convert that into app units and get `780` (the app unit equivalent of `13px`)

So, tl;dr: we're are explicitly deciding against using a fractional-pixel-value for our central baseline (in the rounding "add-0.5-and-floor" logic in ComputeMaxDescent here).  So we use 13px as our central baseline for the line layout here, which is why we end up off-by-1px.