Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Explore logical Unicode PDF encoding with exact ToUnicode

Abierto
  • ¿Algo no está bien?
#1,620 1 comentario 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
4.4k
Forks
714
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de LibrePDF/OpenPDF

Todos los issues de LibrePDF/OpenPDF

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.