Determining text boxes outside baseline

[Naltharial]

When using insertTextbox (and insertText, assuming an equivalent Point), the text that MuPDF PyMuPDF checks for being "inside" the box is only the portions of the glyphs above the baseline. Any descenders (g, j, y, ...) or ascenders are not counted in the check.

Is there any recipe on how to make sure that the entirety of the text fits inside a given box, not just the main line of it?

Example:

doc = fitz.open()
page = doc.newPage()

r1 = fitz.Rect(200, 210, 200 + 100, 210 + 11)

fill = tuple(c/255.0 for c in (255, 0, 0))
color = tuple(c/255.0 for c in (0, 255, 255))

shape = page.newShape()
shape.drawRect(r1)
shape.insertTextbox(
    r1,
    "aabbggjjvv",
    color=color,
    fontsize=11,
    align=fitz.TEXT_ALIGN_CENTER,
    fontname='tiro',
    encoding=fitz.TEXT_ENCODING_LATIN
)

shape.finish(width=0, color=None, fill=fill)
shape.commit()

r2 = fitz.Rect(200, 210 + 11, 200 + 100, 210 + 11 + 11)

fill = tuple(c/255.0 for c in (0, 0, 0))
color = tuple(c/255.0 for c in (255, 0, 255))

shape = page.newShape()
shape.drawRect(r2)

p1 = fitz.Point(200, 210 + 11 + 11)
shape.insertText(
    p1,
    "aabbggjjvv",
    color=color,
    fontsize=11,
    fontname='tiro',
    encoding=fitz.TEXT_ENCODING_LATIN
)

shape.finish(width=0, fill=fill)

ret = shape.commit()

doc.save("test.pdf")

[Naltharial]

Also, this might be a duplicate of
https://github.com/pymupdf/PyMuPDF/discussions/765

but I wanted to make sure the same things are covered, since this isn't exactly about bbox overlaps, just text glyphs.

[JorjMcKie]

The text insertion function are unique to PyMuPDF - these are no features of MuPDF, although under the hood basic MuPDF functions are certainly employed.

• insertText does no containment check, except that the insertion point must be on the page and multiple line height do not exceed page borders
• insertTextbox does check whether a full line height will fit. I will confirm again, that this takes place before the very first character insertion too.
• Up to v1.18.4 line height and the insertion point were calculated using font-independent fixed values. This is changed in v1.18.5, where font properties are used for this. So glyph bboxes should always be fully contained in text boxes for both insertTextbox and TextWriter.fillTextbox - nomatter which font.

[JorjMcKie]

To me, the easiest way to make your type of checks in a consistent way is however using the TextWriter class.
This separates text preparation from writing the text.
You prepare text by adding it to a text writer object, either text piece by text piece or by adding textboxes. During this stage, multiple arbitrary fonts and font sizes in the same text writer may be used.
When finished (or after each added text piece), check the rectangle of the text writer to see if it would fit. The text writer rectangle at any time includes the full union of all glyphs used so far.
You then can decide to abandon the text writer or still write it, but use a shrink factor ... etc.
What is more, the text can also be written multiple times to different or the same page, different or same PDF - each time in a different color, opacity, ...

[Naltharial]

Thanks Jorj, I will update to 1.18.5 and switch to TextWriter for a more consistent approach.

Does calculating height with font properties require set_small_glyph_heights, or is that just for shrinking bboxes down to font size?

[JorjMcKie]

Does calculating height with font properties require set_small_glyph_heights, or is that just for shrinking bboxes down to font size?

Setting this option to true has an effect on all returned bbox (and quad) heights of page.searchFor(), page.getTextbox(), page.getText().

But even if this option is false, small bbox heights can still be computed using values of the span dictionary span["ascender"] / span["descender"]. Spans are delivered for page.getText(option, ...) if option = "dict" or "rawdict" only. See the new documentation version for how to do that.
If this option was true, then the bbox heights already are small, and the computation should deliver the same result.

As I wrote somewhere else, outputting text is not influenced by the setting of this option.

The main motivation for having such an option is the ability to get string searches resulting in minimal rectangles / quads, so that defining other objects (annotations ...) based on those results have no unwanted / innocent overlaps with text that hasn't been searched for.