Hi All,
I am using a legacy template to validate and barcode a PDF based on the number of pages. This is done in a script task merging the source and template output and relies heavily on Alambic API calls.
Currently, the barcode is put at a fixed location on the media. I need it to follow the outside of the TrimBox instead, after having verified that said TrimBox is there and has sufficient space.
I know how to do this if I know the TrimBox position in advance, so the only thing that I need to know is - can I determine the TB location in Workflow (scripting or otherwise)?
Thanks
Unfortunately, no. You can get the MediaBox with Page.MediaSize or the CropBox with Page.Size, but not the TrimBox.
Thanks for the answer. Are you aware of any external tools that can do this, preferably something that can be called from the script task and write the results to a variable?
It seems like a bizarre choice on OL’s part. Everybody and their mothers use the TrimBox in prepress, while from what I was told I get the impression the CropBox is the equivalent of a person you invite to a party while secretly hoping they don’t show up.
The MediaBox and CropBox are the “original” boxes for PDF and can be seen as the most important ones, because the first indicates the size of the output media (or at least the intended final size 
- granted, in more complex production pipelines, this might get changed in various ways), while the CropBox controls the imaging area. All the others (trim, bleed, etc.) were added in subsequent revisions of the standard.
So I guess it depends on the market. For example, office printing will be much more interested in the MediaBox, as this is what will drive the selection of the media.
As for an alternative, I know that iText can be used to do some manipulation of PDF files. As far as I know, it is a library and not an end-user product, so additional programming may be required.
If you are the adventurous type, you could parse the PDF yourself. The objects that define the various boxes are typically not compressed so they can be read as plain text. If the pages in your PDF all have the same size, you could get away with finding the first one and applying the values to every page.
Don’t get me wrong, I can see the benefit of any given box for certain situations, but for our particular prepress workflow TrimBoxes are used as base for spread and n-up imposition and CropBoxes don’t contribute to this in any way; as a matter of fact, the presence of a CropBox is unwelcome as it makes it more difficult to eyeball the bleed area and assess if it is sufficient. I don’t think I’m the only person who would benefit from the inlusion of trim and bleed manipulation in Alambic. I’m pretty sure I even saw a feature request somewhere on the site from a couple years back.
As for alternatives; these are much appreciated. I like adventurous, might just go with that for the time being and look into doing some work with iText in the future.