Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Explore logical Unicode PDF encoding with exact ToUnicode

Open
  • Is something wrong?
#1,620 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
java
Domain
backend

Research direction

The issue shares external Typst and Krilla implementations, including logical text code and an architecture document, but does not identify an OpenPDF file or define a requested change. Read the linked Krilla architecture and logical text implementation to understand the proposal; a concrete OpenPDF task would need to specify an integration point and acceptance criteria.

Written by the indexing model from the issue text.

Description

I am sharing an Enhanced Unicode PDF architecture developed for Typsastra. This is not a request for OpenPDF to adopt it, but a working reference that may be useful for future Unicode PDF encoding work, particularly as an alternative to relying on /ActualText.

The implementation was motivated by Khmer support but is script-independent and has been tested with multilingual complex-script content.

Implementations

Typst adapter

Converts already-shaped text into source-ordered logical units:

Krilla PDF backend

Implements logical CID allocation, synthetic TrueType glyphs, exact /ToUnicode, font sharding, and logical-order TJ output:

Architecture

The boundary between shaping and PDF generation is a source-ordered logical unit:

STRUCT LogicalUnit
    text: exact logical Unicode
    glyphs: already-shaped positioned glyphs
    visual_position: independent x and y position
END STRUCT

The contract is:

  • logical text is authoritative for extraction and accessibility;
  • glyphs are authoritative for appearance;
  • units remain in source order;
  • the PDF backend does not reshape the text.
flowchart LR
    A[Logical Unicode]
    B[Existing shaping engine]
    C[Positioned glyphs]
    D[Logical units]
    E[Semantic and visual key]
    F[Unique logical CID]
    G[Synthetic glyph]
    H[Exact ToUnicode]
    I[Logical-order TJ]
    J[PDF]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    F --> H
    G --> I
    H --> I
    I --> J

A CID is reused only when both the logical text and visual construction are identical:

semantic_key := exact Unicode + positioned glyph construction

IF semantic_key already exists
    reuse its CID
ELSE
    allocate a new CID
    create a synthetic composite glyph
    map the CID to exact Unicode through ToUnicode
END IF

Each synthetic glyph contains the unit’s shaped source glyphs as positioned TrueType components. Logical CIDs are then emitted in source order, with TJ adjustments reproducing visual placement.

Unsupported units fall back to ordinary glyph output rather than failing the document.

Possible relevance to OpenPDF

The smallest possible integration boundary would be a low-level API accepting externally shaped logical units:

INPUT
    source font
    exact Unicode text
    positioned glyphs

OUTPUT
    logical CID
    synthetic visual glyph
    exact ToUnicode mapping

This would not require OpenPDF to replace its shaping engine or redesign paragraph layout. OpenPDF’s existing Java2D GlyphVector output could potentially be adapted to the same interface later.

Test binary

A prebuilt Typst-compatible binary is available for testing:

https://github.com/Sovichea/typsastra/releases/tag/enhanced-unicode-v0.3.1

It supports Windows, Linux, and macOS. After downloading the appropriate archive:

typst compile input.typ output.pdf
pdftotext -enc UTF-8 output.pdf output.txt

Relevant fixture:

https://github.com/Sovichea/typsastra/blob/enhanced-unicode-v0.3.1/tests/fixtures/enhanced-unicode/unicode-selection.typ

There is no expectation that OpenPDF adopt this implementation. I am sharing it as a tested architecture that may provide useful ideas for exact Unicode /ToUnicode encoding without depending on /ActualText.

Dominant language
Java
Stars
4.4k
Forks
714
No merged PRs in 30d

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 LibrePDF/OpenPDF

All issues in LibrePDF/OpenPDF

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.