pdfcraft/vendor/hayro-interpret
TheLastRoadRunner a259af95c3
fix(render): draw Turkish Ğ İ Ş ğ ş in non-embedded fonts (vendored hayro-interpret patch 26) (#1409)
A PDF whose fonts aren't embedded is drawn with PDFium's Foxit stand-ins
for the standard 14 fonts. Those carry only the 230-odd glyphs of the
Standard, WinAnsi and Mac Roman encodings, so a letter a font names beyond
them in its /Differences mapped to .notdef and drew nothing. iText 2
writes Turkish exactly this way (Times New Roman left unembedded,
/Gbreve /Idotaccent /Scedilla /gbreve /scedilla over Ð Ý Þ ð þ), and such
letters showed blanks for Ğ, İ, Ş, ğ and ş while ı, ç, ö and ü drew.

StandardKind now builds a Latin Extended-A letter the stand-in lacks from
the base letter and accent it does have, as Type 1 seac composites and
the standard-14 AFM composites are built: the accent is centred on the
letter, raised over capitals and letters with ascenders (and moved along
the slant in italics), cedillas hang below and ogoneks from the right
edge. Composite glyph ids sit above any font's glyph count, one per
character code; their width comes from the standard metrics of the name.

Test: raster::tests::accented_letters_the_standard_stand_ins_lack_are_built_from_their_parts
(fails without the patch: Gbreve drew no pixel).

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 07:57:03 -04:00
..
assets honour the /Lab colour space /WhitePoint (#1203) (#1237) 2026-10-12 02:08:21 -04:00
examples more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
src fix(render): draw Turkish Ğ İ Ş ğ ş in non-embedded fonts (vendored hayro-interpret patch 26) (#1409) 2026-10-12 07:57:03 -04:00
.cargo-ok more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
.cargo_vcs_info.json more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
Cargo.lock more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
Cargo.toml Never crash: Type 1 font programs can't hang or overflow the stack (skrifa 0.47) 2026-10-05 10:47:39 -04:00
Cargo.toml.orig more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
LICENSE-APACHE more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
LICENSE-MIT more progress, roadmap, wip 2026-09-30 11:00:02 -04:00
README.md M2: bound PDF functions and reject invalid calculator operations (#581) 2026-10-09 18:53:42 -04:00

README.md

hayro-interpret

Crates.io Documentation

A crate for interpreting PDF files.

This crate provides an abstraction to interpret the content of a PDF file and render them into an abstract [Device], which clients can implement as needed. This allows you, for example, to render PDF files to bitmaps (which is what the hayro crate does), or other formats such as SVG.

It should be noted that this crate is still very much in development. Therefore it currently lacks pretty much any documentation on how to use it. It's current API also only really makes it useful for rendering to PNG or SVG, though this will be improved upon in the future.

Examples

See the examples folder on the GitHub repository. Apart from that, you can also consult the implementation of hayro and hayro-svg to get an idea on how to use this crate.

Safety

This crate forbids unsafe code via a crate-level attribute.

Cargo features

This crate has one optional feature:

  • embed-fonts: PDF processors are required to support 14 predefined fonts that do not need to be embedded into a PDF file. If you enable this feature, hayro will embed a (permissively-licensed) substitute for each font, so that you don't have to implement your custom font loading logic. This will add around ~240KB to your binary.

License

Licensed under either of

at your option.

PdfCraft function limits

The PdfCraft patch rejects function construction after 64 nested functions or 10,000 total function nodes, including repeated references, and detects cycles on the current path. Shared children in different branches remain valid. Stitching functions reject empty or unresolved child lists instead of silently truncating them. Calculator functions have a shared limit of 64 procedure levels and 10,000 parsed tokens (operators and procedure openings); evaluation has its own 10,000-operator limit across selected branches. These are implementation resource limits rather than PDF format limits. Rejection returns the existing None, and the optional logging feature reports the reason and limit; no new interface warning is introduced.

Calculator integer division without an integer result is also rejected. Bit shifting discards bits beyond the 32-bit word and fills with zeroes, including logical right shifts of negative words; rotation accepts the full signed shift range without negating the minimum integer. Fixed-size operand and procedure-stack overflow errors propagate instead of truncating work. Normal function signatures and supported color/transfer-function behavior remain unchanged.