The children of an fo:inline or fo:basic-link element do not seem to be taken into account when computing the block-progression-dimension of the element's content rectangle and this may lead to counter-intuitive results for the user.

Given the following FO snippet:
<fo:block font-family="Helvetica" font-size="12pt">Lorem ipsum dolor <fo:inline id="outer"
    border="1pt solid red"><fo:inline id="inner"
    font-size="30pt">sit</fo:inline></fo:inline> amet</fo:block>

Assuming that we are in the default lr-tb writing mode, we are interested in computing the height of the red border rectangle. 

Section 4.6, Inline-areas, states that An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude.

In the case of the outer inline-area, text-altitude and text-depth are taken from the font metrics. Assuming we are using the standard Helvetica font available as one of the 14 PDF core fonts, this amounts to 11.1pt. So the border-rectangle is 11.1pt high.

The inner inline-area has a font-size of 30pt, which makes its content-rectangle 27.75pt high, which largely overflows the border-rectangle of the outer inline-area.

Now, if we replace the outer inline element with an fo:basic-link element, the active (clickable) area generated by the FO processor will also be 11.1pt high, so will not cover the whole inner inline-area, and to my knowledge there is no way to achieve this. The practical use case is an image surrounded by a basic-link to make it clickable. Only the bottom of the image will actually be active.

Should that really be the expected behaviour, or is that an oversight?