Keep the XML file structure, but do it smarter. I have no idea what smarter would be, but this is the only backwards-compatible solution.

Well, I assume by "smarter" you mean "more concise", which unfortunately is not that simple with XML (see HTML for an example of this problem ;). However, maybe if you were to follow the Ruby-on-Rails idea of "intelligent defaults" this might work. The problem of course is, what are those "intelligent defaults"? Taking this idea to an extreme, and you will end up with a PDFML of some kind, which might not be a bad thing.

Somehow, do a TT plugin that provides a bunch of helper functions. Doing this, your template would consist solely of TT directives, some of which would be provide by TT and the rest provided by this plugin. I like this idea, but don't have much of a plan to accomplish it.

I know nothing of TT plugins, but it sounds like what you really want to do is to re-use the TT parser and get some kind of AST (abstract syntax tree) which you can use to build your PDF from.

This idea has it's merit, especially since you get a high quality parser that has been thoroughly battle tested already. However, I question if a PDF-mini-language embedded in TT would not end up being almost the same as writing it using Pure Perl as your template language. And if given a choice between TT or Perl as my mini-language, I might lean towards Perl since it as much more robust. But then again, restricting functionality is sometimes a good thing too.

Overall, I am skeptical of this approach, I am not convienced it will buy you anything more than Pure Perl.

Do something else. I have no idea what "else" would be.

Well, you can write your own DSL (domain specific language) for PDF templating. Using something like Parse::YAPP or Parse::RecDescent is probably not all that much more difficult than making the XML "smarter" anyway. This would force others to learn your new language, but if you keep it "familiar", then it probably won't be any harder to learn than some esoteric XML dialect.

Whatever you choose, I would recommend creating a kind of Object Model for PDFs, similar to the HTML DOM (but not as complex and ugly). If done properly, this would serve as the "runtime" for your PDF templating language, and would allow for multiple "front-ends" to be written (XML, DSL, TT, etc). It would also be easy to exchange various "back-ends" as well (pdflib, PDF::API2, etc).

Anyway, thats my 2 cents (and an upvote).