openai / openai/codex

Arabic word order is reversed in PPTX file preview despite correct source RTL metadata

Open
#43,440 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

Problem

Arabic phrases appear in reversed word order in the Codex desktop PPTX file preview. The source PPTX stores the text in correct logical Unicode order and sets native paragraph RTL metadata. The reporter observes correct Arabic in PDF previews, but incorrect ordering in PPTX previews.

This report concerns the presentation/file preview, not chat-message alignment.

Environment

  • macOS
  • Installed desktop app bundle identifier: com.openai.codex
  • App version: 26.901.51231 (build 8109)
  • Bundled @oai/artifact-tool: 2.8.59, runtime bundle 26.905.11957

Reproduction

  1. Create a PPTX slide containing a native editable Arabic text paragraph in logical Unicode order, for example the following title.
  2. Set the paragraph to right-to-left (a:pPr rtl="1") and right alignment (algn="r"), with an Arabic-capable font.
  3. Open the PPTX in the desktop file preview.
  4. Compare word order with the original text and a correctly rendered presentation/PDF.

Example title in logical order:

‫لماذا تزدحم الرياض؟‬

Expected reading sequence: لماذاتزدحمالرياض؟ (read from the right).

Observed in the independent rendered preview: word placement makes the phrase read in the opposite word sequence. Other Arabic titles, subtitles, and mixed Arabic/number text in the tested deck are also affected.

The direction controls around the displayed issue example are for GitHub readability only; they are not present in the source PPTX text.

Independently verified evidence

A five-slide Arabic deck reproduced the problem using the bundled presentation renderer:

  • Original slide XML contains the correct logical text and a:pPr rtl="1" algn="r".
  • A local Arabic structure audit passed for 54 Arabic paragraphs, including 19 mixed-language paragraphs. This establishes only the audit's tested criteria, not complete OOXML conformance.
  • Importing the PPTX with PresentationFile.importPptx retains the correctly ordered title in the exported layout JSON.
  • Exporting slides 1 and 3 to PNG with the bundled renderer produces incorrect Arabic word ordering.
  • The deck uses Thmanyah Sans. A cross-font regression test would help determine whether the issue is broader; that comparison has not been performed.

Reproduction code for an affected PPTX:

import fs from "node:fs/promises";
import { FileBlob, PresentationFile } from "@oai/artifact-tool";

const presentation = await PresentationFile.importPptx(
  await FileBlob.load("repro.pptx")
);
const slide = presentation.slides.getItem(0);
const png = await presentation.export({ slide, format: "png", scale: 1 });
await fs.writeFile("preview.png", new Uint8Array(await png.arrayBuffer()));
const layout = await slide.export({ format: "layout" });
await fs.writeFile("layout.json", await layout.text());

Investigation / suspected cause

Read-only inspection of the installed application indicates different preview paths:

  • PPTX: Walnut PptxReader.ExtractSlidesProto, followed by the presentation canvas renderer.
  • PDF: PDF.js page rendering.

The inspected presentation text drawing path places text segments with increasing horizontal coordinates and draws them separately. Incomplete paragraph-level bidirectional ordering is a plausible explanation, but the exact faulty stage has not been isolated. Left alignment or segmented drawing alone does not prove the defect.

The independent bundled-renderer reproduction is not proof that the installed preview uses the exact same implementation/version.

Expected behavior

Respect native paragraph RTL metadata and preserve correct visual word order, Arabic shaping, and mixed Arabic/English/number layout. Valid source text should not need to be manually reversed to display correctly.

Verification limits

The in-app symptom and PDF comparison are reporter observations. Diagnostic work independently reproduced the issue with the bundled renderer and inspected static application code; it did not automate a fresh visual comparison inside the app. ChatGPT web was not tested. No matching PDF of the particular diagnostic deck was generated during the investigation. No fix has been applied.

Related reports

  • #14578 concerns general RTL text rendering, rather than this specific PPTX preview reproduction.
  • #33610 concerns PPTX preview fidelity for overlapping shapes, a different symptom.

Contributor guide

Open the contributing guide

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.

Research direction

Start with the bundled reproduction using PresentationFile.importPptx and slide export, then inspect the PPTX path through Walnut PptxReader.ExtractSlidesProto and the presentation canvas renderer. Compare the source a:pPr rtl="1" metadata, exported layout JSON, and PNG output. Done means Arabic and mixed-direction text preserve the expected visual word order, with regression coverage for the reproduced deck.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, rust
Domain
desktop, internationalization
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.