In between doing interesting toolchainy stuff like building a system for safe database migrations, making Perl product rpm'ification sane on RHEL5 and implementing a magic inside+outside-aware web testing module, I've also been tasked by $work to make some upgrades to our online configurable product system.
Which, to sum it up, means business cards.
Business Cards that are preset web-based templates that company employees can provide varying error-checked details to and have cards appear on their desk a week later.
There's letterheads and other easier stuff too, but mostly nobody pays attention to that, since business cards are both the most tricky and have the highest emotional factor for clients.
Business cards are also the print industry's loss leader. If you can get a company's business cards right, then you have a decent chance of getting the REST of their print business too.
So print companies ALSO care a lot about business cards.
Now doing layout logic for something small like a business card doesn't seem THAT complex, until you discover that it's all being done to print industry standards, which adds insane (but necessary) complexity to the problem.
Concepts like "colour" and "dimensions" and "font" and "position" and "background" a myriad of other fundamentals need to be redefined in entirely different ways.
All of this complexity results in about 50,000 SLOC and 30-35 tables, to not only produce you a business card correctly, but let you see it in advance on screen absolutely and provably identical to the way it will come back from the print shop. WYSIWYG for custom print jobs.
The current implementation, integrated into the large 200,000 SLOC system, is a port of an implementation originally created by a startup that $work bought years ago. Their implementation was 100% Microsoft, and couldn't be integrated directly, so it was ported instead.
The current version uses PDF::API2 under the covers to provide the primary layout rendering to PDF, from which we then cook it into a gif for screen previewing.
Unfortunately, PDF::API2 in the default usage does not appear to live up to print industry standards.
Oh sure, it prints basic documents, letterheads, invoices and so on good enough.
But for business cards, it's a Big Deal when a company executive has the hyphen in his last name sitting too far to the left.
Why doesn't it work right? To be honest, I'm not entirely sure yet. I have a week allocated in the next month some time to work out exactly why.
But the short version seems to be that PDF::API2 "doesn't do fonts like any other Windows or Mac program that the rest of the industry uses".
A font taken from Windows or Mac and put into PDF::API2 comes out different. This isn't simply a matter of differences between programs. They appear to work EVERYWHERE else, except for in "our product".
Although I'm entirely sure, we suspect the work of some form of proprietary Adobe auto-hinter magic that is licensed in "everything else", but which isn't available to us.
So PDF::API2 is just using the font metrics available in the font, which can be minimal because they assume the presence of the auto-hinter.
So suffice it to say that while PDF::API2 works just fine, be very cautious if you plan to use it for some form of document that has to replicate a design to high print standards.
You may not get out what the designer put in...
(More details as I investigate further, at which time I'll also hopefully have some proper bugs to submit)