Builds two throwaway documents from the same PDF bytes — A at the default
(true, how every template in the catalog was made) and B with
RenderUnsupportedPdfFeatures = false — and compares them. Both documents,
and their pdfs rows, are deleted before the page renders. No live template is
touched.
?id=50045 — read-only census of a live document, creates nothing
?uuid=2D8206A | ?alias=tplFile-X.PDF | ?file=C:\path\x.pdf
— the A/B comparison
Compare these two by eye — that is the whole decision: unsupported_2D8206A_A_55651.pdf unsupported_2D8206A_B_55652.pdf
source: blob tplFile-2D8206A.pdf
source bytes: 144,922
A RenderUnsupportedPdfFeatures = true (the default -- how every
template in the catalog was made)
docID 55651 pdfID 23536
B RenderUnsupportedPdfFeatures = false
docID 55652 pdfID 23537
==============================================================================
1. THE OBJECT MODEL -- does B drop objects, or only stop painting them?
==============================================================================
object type A B delta
PdfButtonField 2 2 -
PdfCheckField 12 12 -
PdfLinkAnnotation 1 1 -
PdfTextField 39 39 -
TOTAL 54 54 -
pages: A 1, B 1
==============================================================================
2. THE GUARD -- PdfObject.Deletable, which is what the client API reads
==============================================================================
RAD PDF documents Deletable as 'whether this PdfObject instance can be
deleted in the PdfWebControl CLIENT interface'. That is the flag
admin.templateMapper.js:1439 trips over. Nothing below is deleted.
object type A not-del. B not-del.
(nothing on either document is marked non-deletable -- this PDF has no
feature RAD PDF treats as unsupported, so it cannot answer the
question. Re-run against the form that actually showed the error.)
the buttons and signature fields themselves:
A:
p1 Button DELETABLE 92,1527 264x40 Button3
p1 Button DELETABLE 915,1524 233x40 Button2
B:
p1 Button DELETABLE 92,1527 264x40 Button3
p1 Button DELETABLE 915,1524 233x40 Button2
==============================================================================
3. WHAT IT COSTS -- the stored background, and two PDFs to eyeball
==============================================================================
A docID 55651 objs 0 docXml 23,106 B pdfID 23536 pdfs row 162,536 B
B docID 55652 objs 0 docXml 23,104 B pdfID 23537 pdfs row 162,534 B
An A pdfs row bigger than B's means A carries flattened artwork B does
not. A count cannot show a MISSING RULE though, so compare these two by
eye -- that comparison is the whole decision:
A -> /out/unsupported_2D8206A_A_55651.pdf (139,366 B, sha256 9910c59530e368d5…)
B -> /out/unsupported_2D8206A_B_55652.pdf (139,366 B, sha256 3728dadc687bed3a…)
==============================================================================
4. IS THE FLAG RECORDED DOCUMENT-LEVEL?
==============================================================================
If the ONLY difference between A and B is an attribute on docXml's root
element, then the flag is stored state rather than a baked-in rendering,
and an existing document could in principle be flipped without the
re-import the error message implies. If A and B are identical here, it is
held somewhere this cannot see and a re-import is the only route.
A root: <pdf v="5.6.0.0">
B root: <pdf v="5.6.0.0">
root attributes are IDENTICAL -- the flag is not recorded here.
==============================================================================
5. SERVER-SIDE PdfObject.Delete() ON THE BUTTONS
==============================================================================
This is the call deletePdfContent's rebuild makes on EVERY freshly
imported object before it restores the captured set
(AdminController.cs, the `foreach (PdfObject o in existing) o.Delete();`
loop). If it throws on a pre-existing button, the whole content-delete
rebuild dies after the blob has already been rewritten -- which leaves the
file edited and the mapper document stale, and surfaces the RAD PDF
message to the user as if it came from Manage PDF.
Deletable says true on both. That is a DIFFERENT flag from whatever the
server-side Delete() enforces, which is the whole reason this is measured
rather than predicted. Nothing is saved.
A (flag=true) Delete() over all objects: tried 54, ok 52, threw 2
first refusal: PdfButtonField Button3 -> RadPdfDocumentEditorException: Pre-existing PdfButtonFields and PdfSignatureFields can not be deleted unless PdfWebControl.RenderUnsupportedPdfFeatures=false (when the document was created)
A (flag=true) ImportObjects() OK
A (flag=true) Save() OK
A (flag=true) after a fresh load: 56 object(s)
B (flag=false) Delete() over all objects: tried 54, ok 54, threw 0
B (flag=false) ImportObjects() OK
B (flag=false) Save() OK
B (flag=false) after a fresh load: 54 object(s)
---- cleanup ----
deleted document 55651
pdfs row 23536 removed
deleted document 55652
pdfs row 23537 removed