Back to Plate

Block geometry should flatten recursive text leaves before rebasing richer-inline shapes

docs/solutions/logic-errors/2026-04-04-block-geometry-should-flatten-recursive-text-leaves-before-rebasing-richer-inline-shapes.md

53.0.62.2 KB
Original Source

Block geometry should flatten recursive text leaves before rebasing richer-inline shapes

What happened

The earlier mixed-inline work still leaned on a hidden shortcut:

  • direct text children
  • direct inline children with one text child

That was good enough until richer inline descendants showed up:

  • inline wrapper
  • nested inline wrapper inside it
  • multiple text leaves under the same inline subtree

At that point the old geometry model was bullshit.

What fixed it

The durable fix was to flatten each block into recursive text-leaf entries:

  • text leaf path inside the block
  • text length

Then reuse that one geometry source for:

  • point -> block-relative text offset
  • block-relative text offset -> point
  • fragment extraction
  • explicit-at selection rebasing
  • explicit-at range-ref rebasing

That let the existing transform stack survive richer inline descendant trees without a new algorithm for every wrapper shape.

Why this works

The hard part is not “how many inline wrappers exist.” The hard part is “what is the linear text geometry of this block?”

Once that geometry is represented as ordered text leaves, deeper wrappers stop being special.

They become:

  • another path prefix inside the block
  • another text span in the flattened leaf list

That is the right abstraction level for the current v2 proof shape.

Reusable rule

When a block starts supporting richer inline descendants:

  • stop doing geometry off direct children
  • flatten to recursive text leaves first

If the geometry helper still talks like the block has only one level of inline children, it is already lying.