Variable Printing

[JayTBird]

I have a monthly newsletter that I create for multiple companies to send to
their customers, the content is the same for each newsletter but each of
these companies wants their logos, color and font schemes in their
newsletters. To make matters a little more complicated, each company wants
the newsletter to come from the salesperson within the company that
originally made contact with the customer (including a picture).

So their is a data hierarchy of
Company - Logo, Fonts, Colors, web address
Branch - Physical Address, Toll Free Phones
Salesperson - Names, Pictures, EMail, phone

I figured that I have 2 choices (neither of which I have really figured out
how to do 100%) on how to create a database driven publication in Publisher
to do this...

Option 1: Make a template to work with every company with 100% variability
on the newsletter header, footer, side bar and photos - but I don't really
know if you can programatically control fonts, etc in Publisher

Option 2: Create one template per company and variably change the other
data. What I don't know here is if there is some way to do a mail merge into
multiple templates. Meaning - the database stores the name/location of the
template to use for the record.

Am I stretching publisher to it max with this application? Is there a
better solution? I do have a little budget for this project if someone could
suggest a resource who could come to me with a practical approach.

Thanks in advance for any assistance.

 

[Ed Bennett]

Am I stretching publisher to it max with this application?

You're certainly pushing it quite a way, and are probably letting
yourself in for some pain.

Is there a
better solution?

I can't think of one off the top of my head, unfortunately.

Color Schemes are easily accessed and switched through code.
Unfortunately, Font Schemes aren't made available in the same way. You
could, however, manually program a solution to switch all the font
styles in the publication to the set used by a particular organisation.
You'd have to check through each publication before printing, though, as
different fonts have different metrics and so a publication that comes
close to overflowing text boxes in one scheme may lose words into the
overspill area in another font scheme.

Despite this limitation I'd still choose option A, as it is more
manageable. It would require some VBA automation, both for the tweaking
of the document and the data import, as I'm presuming your data are
normalised, such that Publisher couldn't merge directly. It's possible
that you could create a query that "un-normalised" the data so that
Publisher could merge directly, but Publisher doesn't like merging from
queries, and its merge engine can be somewhat "fragile", so coding up
your own mini-merge engine is probably the easier workaround.

I do have a little budget for this project if someone could
suggest a resource who could come to me with a practical approach.

That would depend, of course, on how small "small" is, and on when you'd
need the project completed by.