Help · Utilities · Job identification

Metadata Tagger guide

What it writes into the PDF, the XMP standard it follows, the window and using it in a workflow.

Overview

The File Name Tagger writes the mark codes and the job ticket into the filename. The Metadata Tagger writes exactly the same thing into the file, and leaves the name alone. Two tools rather than one switch, because a shop normally standardises on one or the other, and one folder tree per tool means a drop is never ambiguous about which it was meant to be.

	File Name Tagger	Metadata Tagger
Where the tag goes	`Flyer (J123 L7 RBQC) [CU-Acme_Printing QY-2500].pdf`	XMP packet and Info dictionary; the name stays `Flyer.pdf`
Visible in	Explorer, any folder listing, an email attachment name	Acrobat's Document Properties and Additional Metadata, `pdfinfo`, a RIP, an MIS
Survives	Anything that copies the file, including a RIP that rewrites the PDF	Renaming, re-filing, being pulled into a job folder under a new name
Lost by	Anyone who renames it — and customers do	A processor that strips or rebuilds metadata

They read each other — the token strings are identical, so a file tagged either way decodes in the mark applier, in a workflow, and in the other tool's Inspect panel. Nothing about the vocabulary is duplicated: both tools call the same encoder.

What it writes

Two carriers, on purpose. Belt and braces, because prepress is full of tools that only read one of them:

Carrier	What lands there
XMP packet	An `rdf:Description` under the ImposeIQ namespace `http://duplo.com/ns/imposeiq/1.0/`, prefix `iq`. Holds `iq:marks`, `iq:ticket`, `iq:version`, a readable `iq:marksReadable`, and one element per ticket field. Written uncompressed, which is how several RIPs find a packet.
Info dictionary	`IQMarks`, `IQTicket`, `IQTagVersion`, `IQMarksReadable`, plus a readable key per ticket field. This is the dictionary Acrobat's Document Properties actually shows.

The iq:marks and iq:ticket strings are the authoritative pair — the same tokens the filename version writes between its brackets. The per-field keys are there so an MIS can map one value without implementing the grammar:

Info key	XMP element	Field
`IQCustomerName`	`iq:customerName`	Customer name
`IQCustomerNumber`	`iq:customerNumber`	Customer number
`IQContact`	`iq:contact`	Contact
`IQJobNumber`	`iq:jobNumber`	Job number
`IQPoNumber`	`iq:poNumber`	PO number
`IQQuantity`	`iq:quantity`	Quantity
`IQSets`	`iq:sets`	Sets / kits
`IQDueDate`	`iq:dueDate`	Due date
`IQPriority`	`iq:priority`	Priority
`IQStock`	`iq:stock`	Stock
`IQFinishedSize`	`iq:finishedSize`	Finished size
`IQFinishing`	`iq:finishing`	Finishing
`IQSalesRep`	`iq:salesRep`	Sales rep
`IQCostCenter`	`iq:costCenter`	Cost center
`IQNote`	`iq:note`	Note

Title, Subject, Keywords and Author

Those four are the fields a person actually sees, so the ticket can fill them in. The setting lives beside the folder pickers and has three positions:

Setting	What happens
Fill where blank the default	Title gets the file's own name, Subject the ticket summary, Keywords the codes, Author the sales rep — but only where the artwork left them empty. Whatever the designer put in Title is theirs and stays.
Always overwrite	Stamped every pass, so Explorer's Details pane and Acrobat always show the current ticket. Whatever those four fields carried is lost.
Leave them alone	Only the `IQ` keys and the XMP block are touched.

Producer and ModDate are never touched. A prepress operator who sees the Producer change notices, and rightly distrusts it. The tag is added; nothing else about the document's identity moves.

Metadata another tool already put there

Artwork usually arrives with an XMP packet already in it — Dublin Core from InDesign, the press's own fields, a color policy. That packet is merged, not replaced. Only the ImposeIQ rdf:Description is removed and rewritten; everything else is left byte for byte as it was, and re-tagging the same file over and over leaves exactly one copy of our block rather than stacking them.

One case where it cannot merge — a packet with no readable <rdf:RDF> container cannot be edited safely by hand. The tag is written into a fresh packet and a warning goes in the log saying what was lost. It is rare, and it is said out loud rather than done quietly.

Profiles, folders and the drop panel

Identical to the File Name Tagger, deliberately — an operator who knows one knows the other. One profile per watch subfolder, the folder is the instruction, a file is only touched once it has stopped growing, nothing reaches disk until Apply, and the Job ticket for this drop panel layers job number, PO, quantity and due date on top of the profile for the files you drop by hand. Choose a PDF… loads a single file to tag by hand, and Open this profile’s folder jumps straight to the watch folder that profile is bound to — the quickest way to confirm files are landing where the profile expects.

The one visible difference is the preview. The filename version can show the finished name in a line; here the honest answer to "what does this do to my file" is a list, so the preview shows the two token strings, how many Info keys they become, and the marks and ticket in plain words.

Inspect a PDF

Reads what a file is already carrying and changes nothing. The badge says which carrier answered, which is the useful part:

Badge	Meaning
XMP packet	Fully tagged. This is what a file this tool wrote looks like.
Info dictionary	The XMP was stripped somewhere upstream but the Info keys survived. The tag still reads; something in the chain is rewriting metadata.
Filename only	Nothing inside the file — the codes are in the name, from the File Name Tagger or an MIS. Dropping it on a profile writes the tag inside, but from the profile's settings, not from the name.
Not tagged	Nothing of ours anywhere.

It also shows Title, Subject, Author and the page count, so it doubles as a quick check on what a customer actually sent.

In a workflow

Tag PDF metadata (Files) is the same encoder driven by step settings, for jobs that arrived by email and went through preflight rather than being dropped in a folder. It has three modes:

Mode	What it does
Write	Writes the tag into every PDF in the job. Takes the ticket from the Job ticket step by default, or from its own fields.
Read	Changes nothing; sets `[var.ticket_*]`, `[var.pdfTagMarks]` and `[var.pdfTagSource]` from what the file already carries. For a workflow receiving files another shop tagged.
Strip	Removes our block from both carriers and leaves the rest of the metadata alone — for a file going out to a customer.

Both at once — nothing stops a workflow running Tag PDF metadata and Tag filename back to back. Belt and braces for a job crossing a system you do not control: whichever survives, the instructions arrive.

Return to Metadata Tagger · Downloads · Support