PDF interop & export
What Redline writes into a PDF, what it reads back, what survives a round trip through other AEC markup tools, and where the deliberate limits are.
The interop rule is simple to state and hard to keep: a markup should go out as something another PDF tool can select and edit, and come back as something Redline can select and edit. Everything below is in service of that.
Writing#
Markups are written as real PDF annotations with /AP appearance streams — not flattened into the page content, and not rasterized. A reviewer opening the file in another PDF tool gets objects they can click.
settings.pdfMarkupOutput chooses the strategy:
| Value | Writes |
|---|---|
annotations (default) | Real annotations with appearance streams |
content | Markups baked into page content — a flatten |
both | Annotations plus baked content |
Appearance streams are drawn by the same code that draws the canvas. There is no second renderer, which is what stops the exported file and the screen from drifting apart.
A flatten honours the same rules as the screen — alignment, vertical alignment, wrapping and underline in text; the callout case included. Hidden markups and no-print layers are excluded from both export and printing.
One un-drawable markup no longer sinks an export. A markup that throws while being drawn is skipped, with the rest of the document written.
Reading#
Redline reads a PDF's own annotations back as editable markups, which is the other half of the round trip.
Merge, not just import. The annotation dictionaries are read directly for their name and subject keys, so a file that Redline saved can go out for review and come back with the reviewer's additions landing as new markups while Redline's own are recognised and skipped. Subject survives, so takeoff grouping survives with it.
Annotations we cannot model are retained in place, with their identity and appearance intact. Ones that were imported are replaced on save rather than duplicated.
Per-page import. A page that fails to import names itself in the message; it does not discard the document's other pages.
Round-tripping another application's files#
Redline is tested against real files produced by the established AEC markup applications, not only against its own output. What that buys you:
| Grouped markups | A stamp built from several annotations tied to a leader imports as one stamp, not as loose parts, and the grouping is written back on export |
| Replies | A reply is distinguished from a group — conflating them welds a reply onto its parent |
| Callout frames | Frame shape is recovered from the file's own keys and the proportions from the appearance, so a callout stays parametric under resize |
| Detail callouts | A detail bubble made of a bubble, captions and a plain line is recognised as such; dragging one stretches the leader instead of deforming the bubble |
| Line direction | Endpoint order is read from the dictionary, because the normalized rectangle loses it — which also protects arrow direction |
| Highlights | One box per line from the quad points, not one box from the annotation rectangle, so gaps between wrapped lines are not covered |
| Flags | A flag written as free text with a caption on a filled banner imports as a flag markup, reaching the Flags panel with its actions, rather than as white text on nothing |
| Text overflow | Overflowing text grows the box in the file and records the inset that lets it re-import at the same size, instead of creeping larger every cycle |
| Annotations stripped of their names | Some editors discard annotation names on save. Those files are recognised rather than re-imported as duplicates stacked on the originals |
A representative test file of 34 annotations round-trips 34 out, 31 of them as editable markups and the rest preserved by passthrough, with no compounding across two saves and line endpoints exact.
XFDF#
Redline emits standards-conformant XFDF and does not deviate. The target is ISO 19444-1:2019 (XFDF 3.0), with annotation semantics per ISO 32000-2.
Where Redline's model carries more than the standard can express, the extra data goes in a private namespace that conforming readers ignore. It never changes the meaning of a standard attribute and never appears in the default namespace — so a conforming reader that ignores the private namespace still gets a valid, correct document.
XFDF is how markups move between documents without moving the document: export the markups, send them, import them onto the recipient's copy.
Measurements on export#
Two behaviours differ between exporting and flattening, and the asymmetry is deliberate — see Measurement & takeoff. In short: an export keeps measurements live so they can be recalibrated, while a flatten bakes the number, because after a flatten the ink is the only record.
Signatures#
Signature fields — the blocks in a document that a signature goes into, which you place, rename, mark required and delete — are shipped.
Needs a cryptographic stack that does not exist in the application yet. Signature FIELDS are a different, shipped feature.
Signing with your own identity and placing a signature field are often called by the same name, and they are not the same job. Fields are shipped.
Batch Sign & Seal orchestrates applying a signature and seal across many documents once that stack exists.
Deliberate limits#
| Not done | Why |
|---|---|
| 3D PDF (PRC/U3D) rendering | PRC is effectively undocumented and has no open parser. The model is preserved through a round trip rather than dropped — it is simply not displayed, and the message says so, because "3D not supported" implies the content is at risk when it is not |
| Rights-managed (DRM) documents | Refused on open, with the handler named. Partially parsing one and rendering garbage that looks like a drawing is worse than declining it |
| Enterprise DRM connector | Needs a cloud tenant registration and a platform-specific SDK that breaks the Linux-primary rule. Worth building against a named customer, not before |
| CAD virtual printer driver | A per-OS kernel-level component, out of scope for the desktop application |
Formats#
| Format | Direction |
|---|---|
| Read and write | |
.amed | Read and write — the working format, keeps markups live |
.amedset | Read and write — the Set ledger |
| XFDF / FDF | Read and write — markups without the document |
| Images | Import as page content |