Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Explore logical Unicode PDF encoding with exact ToUnicode

Aperta
  • Qualcosa non va?
#1,620 1 commento 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
4.4k
Fork
714
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LibrePDF/OpenPDF

Tutte le issue di LibrePDF/OpenPDF

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.