<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pardes.git/test/pdf.zig, branch release-0.24</title>
<subtitle>Pardes</subtitle>
<id>https://git.0x4200.cafe/pardes.git/atom?h=release-0.24</id>
<link rel='self' href='https://git.0x4200.cafe/pardes.git/atom?h=release-0.24'/>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/'/>
<updated>2026-10-01T11:53:11Z</updated>
<entry>
<title>A pane's ctl read says Collapse and a PDF's PdfFit and PdfTint (`collapsed`, `fit:height tint:full`), and a Dump keeps the PDF's two</title>
<updated>2026-10-01T11:53:11Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T11:26:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=b7eb31674e01c992cafc91518e161258b921bd33'/>
<id>urn:sha1:b7eb31674e01c992cafc91518e161258b921bd33</id>
<content type='text'>
Neither showed in the tag or the ctl, and a Restore brought a PDF back
at width fit and the default tint. The ctl read ends with `collapsed`
when it is, and a PDF's `fit:` and `tint:` in the words PdfFit and
PdfTint take; the dump's image record carries pdf_fit and pdf_tint
(empty in older dumps: the defaults).

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A PDF place `:P:H` whose search hit H is not on page P, or with no search, is a miss with an err, as a page past the last is</title>
<updated>2026-10-01T11:53:11Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T11:22:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=f3070c04d3eaa0e0d3965478781c2d0b456446bf'/>
<id>urn:sha1:f3070c04d3eaa0e0d3965478781c2d0b456446bf</id>
<content type='text'>
The second number of a PDF place is a hit of the pane's search (its
search rows are `file.pdf:P:H`), and one that named no hit turned to
page P silently. pdf State.hitExists asks the pane's search for page P:
a hit it does not have, or any hit with no search, is now `&lt;file&gt; has
no search hit H on page P`, on the pane itself (`:P:H`) and from
anywhere (`file.pdf:P:H`); a search row's hit is always there.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>`:N:H` looked at on a PDF pane turns to page N, as `book.pdf:N:H` does from anywhere, not a refusal that a PDF has no text</title>
<updated>2026-10-01T10:16:43Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T09:32:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=bb9a5f19cf0ea6944fd8c67503e09aa5a2da4355'/>
<id>urn:sha1:bb9a5f19cf0ea6944fd8c67503e09aa5a2da4355</id>
<content type='text'>
A PDF's own pane took only `:N`; `:5:3` was refused as no text to
address while `book.pdf:5:3` turned to page 5 (its search hit 3).
lookPdfPage now reads the page before a colon and the hit after it.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A PDF's body puts each line of the page's text on a line of its own, not a heading and its paragraph run together with a space</title>
<updated>2026-10-01T04:35:12Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T04:25:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=b3bbad85c61f81c01fb983813ccc28ceb6361469'/>
<id>urn:sha1:b3bbad85c61f81c01fb983813ccc28ceb6361469</id>
<content type='text'>
MuPDF's text buffer joins the lines of one block with spaces, so a
typst page's heading and the text under it read as one line ("Page one
Hello normal PDF alpha."). The bridge now walks the structured text
itself, structure blocks included, and ends each line with a newline.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A +PdfSections row's first number is the page: a section that is not there, or is on another page, is a miss said, not a silent success</title>
<updated>2026-10-01T04:35:12Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T04:21:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=ea28dbf4ce827ee5544562bd19453c68599d912f'/>
<id>urn:sha1:ea28dbf4ce827ee5544562bd19453c68599d912f</id>
<content type='text'>
A look at `file.pdf:P:S` in +PdfSections went to section S whatever P
said, and one past the last section did nothing and answered ok. The
row's page is now held to: a section not in the outline, or on another
page than the row names, fails with which, as every other miss does.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A bare :N or :N:M look addresses the pane itself, its line N (column M), from every way a look comes; a PDF's :0 has no page 0</title>
<updated>2026-10-01T04:35:12Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T04:00:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=28e90e064bd317d0e253edb2f5b305a6192f560b'/>
<id>urn:sha1:28e90e064bd317d0e253edb2f5b305a6192f560b</id>
<content type='text'>
A look of `:12` had no path to resolve, so it fell through to a word
search for the text ":12" and found nothing. A digit-led address with
no path now names the looking pane, as `:/re/` already did: its look,
the root's (the keyboard's pane), Look, B3 and an event write-back all
reach it, a terminal's logical lines included. On a PDF, :0 is the
has-no-page miss rather than a refusal.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A PDF page taller than one raster is drawn at the size it is shown, in bands around the screen, not squeezed into 4096 rows and blown up</title>
<updated>2026-10-01T03:14:45Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T02:54:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=65262f4a033d382426c7f58d57a9b38e45918558'/>
<id>urn:sha1:65262f4a033d382426c7f58d57a9b38e45918558</id>
<content type='text'>
The render geometry (pdf_bridge.c) clamped a page's LONGEST side to
max_dimension: 4096 in the SDL policy, 1200 in Kitty's. A page 841.89 x
4818.9 pt, fit to a 1570 px wide pane, came out 715 x 4096 and was drawn
2.2 times too large at 1x, 4.4 times at 2x; Kitty's raster was 210 px
wide. Every request now caps a raster ROW at max_dimension, and caps
the height too only while that keeps the page at least as large as it
is shown (RenderRequest.display_width/height, set from the fit). A
tall page fit to width is rasterized at the pane's own width, in SDL,
and at Kitty's 96 dpi as any other page is there.

Such a page is not one buffer. A raster over 8192 rows (a texture's and
Kitty's 10000-pixel limit) or over 64 MiB is banded (pdf_view.zig): its
slot holds the rows on screen and a screenful either side, in 512-row
chunks, and is rendered again, keeping the chunks it has, once the
screen comes within half a screenful of its edge. Each chunk comes from
its own render reaching 32 rows past both edges, so a row of the page
is the same however it was scrolled to, and no chunk shows its clip
edge: band rows are within 3 levels of a whole-page render (108 pixels
of 45 million on the reported PDF). Highlights paint over the band's
clean rows as over a page's, and the band uses the page's CTM, so
search, selection and pointer geometry are unchanged.

A display-list render now culls to the band (a scissor in page space).
No pixel changes, but a frame that renders new rows of the reported
page at 2x fell from 33-43 ms to 13-16 ms (pdf-scroll-bench, --cell
16x32). design.pdf's scroll-bench pixels are identical.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>:N on a PDF turns to page N, from the pane and from the root's look; @pN:N answers ok with no err; an address in a pane with no text names the pane</title>
<updated>2026-10-01T03:12:17Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T00:10:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=591d3c7baecc434527d02e5894ac0240d2fa1c8d'/>
<id>urn:sha1:591d3c7baecc434527d02e5894ac0240d2fa1c8d</id>
<content type='text'>
A PDF pane took :N as a word to search for, and @p&lt;pdf&gt;:N failed as
"is no text to address" after the page had nothing to do with it, an
err in the log for a look that meant something. A PDF's address is now
its page: :N turns to it, one past the last is the has-no-page miss,
and a byte offset or a pattern is refused saying a PDF's address is a
page. The refusal for any other textless pane named an empty path when
the look was a bare :addr; it names the image or @p&lt;serial&gt; now.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Recent and /recent keep PDFs and images as they keep files, and an open file's row is where its dot is now</title>
<updated>2026-10-01T03:12:17Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-09-30T23:09:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=f8fe738416fe3a40a7136f2cb5528e8fd57f40df'/>
<id>urn:sha1:f8fe738416fe3a40a7136f2cb5528e8fd57f40df</id>
<content type='text'>
Only text files were recorded, so a PDF read yesterday was not there to
find again, and an open file's row showed the place it last closed at,
stale by however far it had moved since. A PDF is kept at its page and
reopened there from its row; an image by its path; an open one's row
reads its pane's place at the time of the listing.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>PdfSections on a PDF with no outline says so, "this PDF has no outline", rather than open an empty +PdfSections</title>
<updated>2026-10-01T03:12:17Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-09-30T23:03:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=30378c63d752bf27d44f6a64738bab5a2cddc863'/>
<id>urn:sha1:30378c63d752bf27d44f6a64738bab5a2cddc863</id>
<content type='text'>
An empty pane with no word of why read as a failure to load, and was
kept to be re-shown on the next press. With no outline there is
nothing to list: the press is refused with the reason, and a read or
slot failure is said too, where it returned silently.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
