Repository navigation
Layers close one, and closed a disclosure on the way - #108
Merged
Merged
Conversation
pdf-layers is claimed, through `pdfops layers` in go-pdfkit/ops v0.15.0.
⛔⛔ Building it found that every ops verb was REVEALING a hidden layer.
Measured with a probe: a drawing with a layer switched off, run through
`pdfops watermark`, came back with no /OCProperties at all — the content still
marked as belonging to a layer, the layer object still reachable through the
page's resources, and nothing left saying which layer was hidden. So it showed.
A drawing distributed with an "internal pricing" layer turned off revealed it
to any verb at all.
That is the second loss of this kind in two pieces of work: page labels went
the same way, for the same reason — a catalogue entry that cannot be copied
across a rebuild was dropped rather than rebuilt. The difference is the
consequence: a renumbered toolbar is a defect, a revealed layer is a
disclosure.
What the file says about its own layers is now obeyed: /BaseState OFF inverts
the question, /Locked refuses to be switched, and the nesting is written back
nested. Dropping a HIDDEN layer is refused, because its content stays in the
page and stops being optional — the hidden drawing would become permanently
visible.
Pasted from the tool's own output:
covered 81
not covered 33
parity 71.1% (81/114), every claim verified
Measured 2026-10-11 against BentoPDF 3a5f146 (v2.8.8, 114 tools), pdfops and
ops at v0.15.0, ooxml v0.2.0, opc v0.1.0, odf 3d1deee (= v0.7.0), convert
45fbb5d, render 3bb5dcf, app 1feda5d, rtf 6bc4897, markdown eafebfd,
data 128b6c7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pdf-layersis claimed, throughpdfops layersingo-pdfkit/opsv0.15.0.⛔⛔ Building it found that every
opsverb was revealing a hidden layerMeasured with a probe written for the purpose: a drawing with a layer switched
off, run through
pdfops watermark, came back with no/OCPropertiesatall — the content still marked as belonging to a layer, the layer object
still reachable through the page's resources, and nothing left saying which
layer was hidden. So it showed.
That is the second loss of this kind in two pieces of work — page labels
went the same way, for the same reason: a catalogue entry that cannot be copied
across a rebuild was dropped rather than rebuilt. The difference is the
consequence:
Both are rebuilt now, and in both cases a mutation restoring the old behaviour
is caught.
Measured 2026-10-11 against BentoPDF
3a5f146(v2.8.8, 114 tools),pdfopsand
opsat v0.15.0,ooxmlv0.2.0,opcv0.1.0,odf3d1deee(= v0.7.0),
convert45fbb5d,render3bb5dcf,app1feda5d,rtf6bc4897,markdowneafebfd,data128b6c7.🤖 Generated with Claude Code