GPOS mark offsets (xOffset/yOffset) are effectively ignored at render time — Arabic dots / combining marks misplaced (4.9.0)

Open
  • Is something wrong?
#3,576 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
react, typescript
Domain
backend

Research direction

Start by locating textkit's resolveRunYOffset and the render package's renderGlyphs and _renderGlyphs entry points. Trace how GPOS xOffset/yOffset values are scaled and preserved, then compare generated PDFs with fontkit's native RTL positions using the Arabic reproduction and the reported Thai strings. Done means marks match fontkit placement without regressing the zero-code-point bidi behavior from #3555.

Written by the indexing model from the issue text.

Description

Describe the bug

GPOS mark positioning (xOffset / yOffset from fontkit) is effectively ignored when glyphs are drawn. Marks end up at the pen position instead of where the font places them. In Arabic this is visible on letters whose dots are separate zero-advance glyphs in Noto Sans Arabic. For example, the two dots of final yeh in في / العربي are drawn beside the letter instead of under its bowl.

Versions: @react-pdf/renderer 4.9.0 (@react-pdf/render 4.7.0, @react-pdf/textkit 7.0.1), fontkit 2.0.4, Node 22.

To Reproduce

import React from 'react'
import { Document, Page, Text, Font, renderToFile } from '@react-pdf/renderer'

Font.register({ family: 'AR', src: 'https://fonts.gstatic.com/s/notosansarabic/v33/nwpxtLGrOAZMl5nJ_wfgRg3DrWFZWsnVBJ_sS6tlqHHFlhQ5l3sQWIHPqzCfyGyvuw.ttf' })

renderToFile(
  <Document><Page style={{ padding: 20 }}>
    <Text style={{ fontFamily: 'AR', fontSize: 40 }}>في دول الخليج العربي</Text>
  </Page></Document>,
  'out.pdf',
)

Compare with the same string shaped by fontkit directly (font.layout(s, undefined, undefined, undefined, 'rtl'), then draw each glyph path at x + xOffset, y - yOffset). In the PDF the yeh dots are offset sideways; with fontkit's own positions they sit under the bowl.

Root cause (as far as we can tell)

  1. textkit scalePositions converts xOffset / yOffset to points (× fontSize / unitsPerEm).
  2. textkit resolveRunYOffset then overwrites every position's yOffset with the sub/super offset (attributes.yOffset * unitsPerEm, in font units). So the GPOS yOffset is always lost.
  3. render renderGlyphs converts xAdvance to 1/1000 em (× 1000 / fontSize) but passes xOffset / yOffset through unchanged. _renderGlyphs then does x + pos.xOffset * scale with scale = fontSize / 1000. A value already in points gets multiplied by fontSize / 1000 again, so at 10pt the offset ends up about 100× too small.

Fix that worked for us

In resolveRunYOffset, keep the GPOS offsets and convert them into the unit render expects:

const toPerMille = run.attributes?.fontSize ? 1000 / run.attributes.fontSize : 0;
const positions = run.positions.map((p) => Object.assign({}, p, {
  xOffset: (p.xOffset || 0) * toPerMille,
  yOffset: yOffset + (p.yOffset || 0) * toPerMille,
}));

With this, together with keeping zero-code-point mark glyphs during bidi reordering (see #3555), glyph positions matched fontkit's native RTL layout exactly. That held for 8 Arabic test strings, and Thai stacked tone marks also matched.

Expected behavior

Mark glyphs are placed using the font's GPOS offsets, the same as fontkit's own layout.

Dominant language
TypeScript
Stars
16.8k
Forks
1.3k
Avg merge
11m
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from diegomura/react-pdf

All issues in diegomura/react-pdf

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.