dce9b9f912
* Fix #624: preserve hard edges for non-interpolated images Select nearest-neighbour for Hayro's image pre-minification when /Interpolate is absent or false, retaining Catmull-Rom for true. Add a synthetic regression covering default, false, and true behaviour and record the vendored patch. Co-authored-by: Codex <noreply@openai.com> * M2: test non-interpolated minification with exact colours The #624 regression used alternating black and white columns. Nearest 8→4 sampling reads only white columns from that pattern, so an image skipped entirely still passed, and the check only asked for near-black or near-white pixels. Replace it with 2×2 colour blocks whose exact device output is asserted, with /Interpolate omitted equal to false, and /Interpolate true still blending. Add exact cases for gray, a non-integer 10→6 minification, and a matched soft mask. All pass on this head. On origin/main the same block image renders with blended mid-tones (for example 12eb12ff where pure green is expected), so these tests fail without the #624 change. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * M2: plan nearest-neighbour pre-resize without filter limits Non-interpolated images are pre-resized with nearest-neighbour, which copies source pixels and needs no filter tables, crossed intermediate or scratch. The preflight still applied the Catmull-Rom checks to it: a source wider than 2^20 pixels, or a filter plan over 128 MiB, was refused, and once such a source was wider than the backend's u16 limit the image was skipped. resampling_byte_len and image_resampling_size take the image's interpolation flag. Nearest keeps the source and target buffer bounds and refuses any scratch it reports. Filtered images keep their limits unchanged, and the existing image_resampling_size tests pass true. Measured: a 1.5M-pixel-wide RGB row drawn at 750×4 device pixels renders 0 non-white pixels on origin/main (the image is skipped) and all 3000 pixels with this commit. The 1.1M-pixel gray case is covered by wide_non_interpolated_sources_draw_after_shrinking. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * M2: keep non-interpolated Type 3 glyph images nearest Minified images inside Type 3 glyphs were drawn with ImageQuality::High, a bicubic sampler, whatever their /Interpolate. A non-interpolated image had already been pre-resized with nearest-neighbour, and bicubic sampling of that result blended it again. High is now used only for interpolated images, as elsewhere. Before this commit the new test saw an interior glyph pixel of [28, 28, 27] (not a palette colour) for a 4.6 × 2.3 px glyph of a palette image; after it, every interior pixel is a palette colour. /Interpolate true still blends. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * M2: nearest-sample masked minified images straight into premultiplied RGBA A non-interpolated image with a matching soft mask used to build a full-resolution RGBA copy, nearest-resize it, then premultiply the target. For a minified image most of that copy was discarded. nearest_premultiplied_rgba reads colour and mask from the same source pixel, selected with PicScale's nearest index (same fixed-point centre sampling as ResampleNearestPlan) and premultiplies only the target pixels. It falls back to the previous path if its target buffer cannot be allocated. Interpolated images, unmasked images and magnification are unchanged. New test: a ten-column gray ramp with a soft mask drawn six pixels wide must pick the same columns for colour and mask. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * M2: record the #624 image patch in vendor/README.md The hayro row listed the #624 regression test but not the patch itself. Add patch item (10) covering the nearest pre-resize and its planning, the Type 3 bicubic restriction and the premultiplied soft-mask path, and list every regression test that covers them. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> --------- Co-authored-by: Codex <noreply@openai.com> Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com>
hayro
A crate for rendering PDF files.
This crate allows you to render pages of a PDF file into bitmaps. It is supposed to be relatively lightweight, since we do not have any dependencies on the GPU. All the rendering happens on the CPU.
The ultimate goal of this crate is to be a feature-complete and performant PDF rasterizer.
With that said, we are currently still very far away from reaching that goal: So far, no effort
has been put into performance optimizations, as we are still working on implementing missing features.
However, this crate is currently the most comprehensive and feature-complete
implementation of a PDF rasterizer in pure Rust. This claim is supported by the fact that we currently
include over 1000 PDF files in our regression test suite. The majority of those have been scraped
from the pdf.js and PDFBOX test suites and therefore represent a very large and diverse sample
of PDF files.
As mentioned, there are still some serious limitations, including lack of support for encrypted/password-protected PDF files, blending and isolation, knockout groups as well as a range of smaller features such as color key masking. But you should be able to render the vast majority of PDF files without too many issues.
Safety
This crate forbids unsafe code via a crate-level attribute.
Examples
For usage examples, see the example in the GitHub repository.
Cargo features
This crate has one optional feature:
embed-fonts: See the description ofhayro-interpretfor more information.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.