Automating Prepress article now live on MSDN

[Andrew May [MSFT]]

The first of three article detailing how to automate commercial printing
prepress operations using the Publisher object model is now live on MSDN:

http://msdn.microsoft.com/library/?url=/library/en-us/odc_pb2003_ta/html/ODC_pb_Prepress1_.asp

These articles covers the same issues as the Publisher Prepress Reference,
from a developer standpoint. The first article includes defining the color
mode and inks used in a publications, and controlling print output.
Programmatically print publications as separations, including customizing
the print output of each plate.

And as always, if you read it, please rate it. Let us know what you think!
(My apologies for the cross-posting, but I wanted to let everyone who might
be interested in this article know it was published.)

Thanks,
AJ

 

[R]

You are cracking me up - write code to output Publisher files. So now I have
to by MS Visual Basic to output files. lol!

 

[Brian Kvalheim - [MS MVP]]

Hi R ([email protected]),
in the newsgroups
you posted:

|| You are cracking me up - write code to output Publisher files. So
|| now I have to by MS Visual Basic to output files. lol!

Um, no you don't. It's already included with Publisher. ROFL LOL

--
Brian Kvalheim
Microsoft Office Publisher MVP
Official Publisher MVP Site:
http://www.kvalheim.org

This posting is provided "AS IS" with no warranties, and
confers no rights.

 

[Brian Kvalheim - [MS MVP]]

Hi R ([email protected]),
in the newsgroups
you posted:

|| You are cracking me up - write code to output Publisher files. So
|| now I have to by MS Visual Basic to output files. lol!

Just once I wish people would THINK before posting.

--
Brian Kvalheim
Microsoft Office Publisher MVP
Official Publisher MVP Site:
http://www.kvalheim.org

This posting is provided "AS IS" with no warranties, and
confers no rights.

 

[mact]

I'm just wondering why the bashers enjoy hanging around here so much.

it can't be our hot buffet or no host bar....

 

[Mike Koewler]

Brian,

Actually, it's easy to see how Joe could have thought that. The article
talks about "programmatically' being able to change color modes, it
lists the specific name of color modes and show the code Pub uses to
accomplish this. Nowhere does it say this runs automatically in the
background, nor do I think many printers would care about the innards.

Of course, I am not a printer, just a layout artist!

Mike

 

[Brian Kvalheim - [MS MVP]]

It's all in the research

--
Brian Kvalheim
Microsoft Office Publisher MVP
Official Publisher MVP Site:
http://www.kvalheim.org

This posting is provided "AS IS" with no warranties, and
confers no rights.

 

[Brian Kvalheim - [MS MVP]]

BTW, if you look at the first sentence at the top it says:

"Summary: Define the color mode and inks used in a publications, and control
print output using the Publisher 2003 object model."

Note "using the Publisher 2003 object model"

--
Brian Kvalheim
Microsoft Office Publisher MVP
Official Publisher MVP Site:
http://www.kvalheim.org

This posting is provided "AS IS" with no warranties, and
confers no rights.

 

[Mike Koewler]

Brian,

Wouldn't it make more sense to say "Pick your color mode from the drop
down menu"?

KISS

Mike

 

[°°°MS°Publisher°°°]

Users cannot be pissed off having to use the VB stuff to output files. This
is after all year 2004, why is there a reason it cannot be simple!!!

--

 

[R]

Don't consider myself a basher as I've posted numerous
helpful responses. That article just made me laugh as
very few prepress people will be able to use it. I write VBA
procedures myself already for interaction between access, word
and excel.

You say it's all in the reasearch but very very very few of us
have time to spend all day working on stuff like that - we have
deadlines to meet - if presses come to a stop that's very very bad.
The only reason I know about it is I used to have a job at a software
company where I was trained on it. It would take many weekend
of the average operators time to figure out how to use that as
there usually isn't time during the day and it would likely fail on
most jobs due to customers mistakes anyway - leaving prepress
operators to go back to the original document to fix something,
it's just the nature of the beast - it's not that publisher is the wost
program,
(word beats it hands down in my opinion) for prep output - it's just
that user who bring the files are just using it because it's there on
their computer - not because they made up their mind to be professional
page designers with publisher.

same thing applies to people who inherited PM, Quark or Indy. When
the whole world goes CMYK exclusively then you can really automate
production, but not reliably with spot colors w/o a whole lot of training
on properly setting up a document.

We already use automated processes to receive and process files, so I know
what I'm saying here. Even Adobe products don't support the same Pantone
naming conventions (C / U / CV / CVU / CVC) it's a real pain when your
document
has the same color with 6 different names.

 

[Brian Kvalheim - [MS MVP]]

You speak with too much of a blanket statement. I know of many commercial
printers, including the shops my family own, that will indeed use such
features, and have since Publisher 2002.

--
Brian Kvalheim
Microsoft Office Publisher MVP
Official Publisher MVP Site:
http://www.kvalheim.org

This posting is provided "AS IS" with no warranties, and
confers no rights.

 

[°°°MS°Publisher°°°]

Brian real businesses do not have time to mess around with VBA to output a
document.
VBA is for the hackers and players, not for use by real world businesses.

--

 

[Mac Townsend]

Users cannot be pissed off having to use the VB stuff to output files.
This

is after all year 2004, why is there a reason it cannot be simple!!!>>

This is not what was said.

What was said was that MSPub now (or very soon will) constitute an "output
engine" that can be used in a variety of situtations.

One could write a front end to handle automatic creation of a telephone
book. Or a simple format catalog. Or a number of other data-driven tasks.

None of which would be considered "prepress" (unless one considered
"composition" to happen before "press") and none of the situtations I can
think of off the top of my head are functions that any prepress department
would provide.

It is unfortunate that the word "prepress" was used in the subject title.

 

[Mike Koewler]

It is unfortunate that the word "prepress" was used in the subject title.

Mac, it was also used in the Topic of the Article: Automating Commercial
Printing Prepress Tasks in Microsoft Office Publisher 2003, Part 1

There are also numerous references to the Pub 2003 Prepress Reference Guide.

I'll be honest, I haven't tried to get a copy of 03 - I am still running
- quite happily - 98. Neither have I read much about using VB in DTP
apps, except for an article about a program (that is three versions old)
that could query a database, insert data and pictures and then e-mail
the resulting file to potential customers, such as people interested in
buying a specific type of house in a specific price range. I don't see
this have a wide market appeal, though. Yet, if it adds little to the
cost of the program, why not add it!

Mike

 

[Mac Townsend]

I've tinkered with it enough this weekend to see where for simple documents
it would be a pretty quick and easy dbp type of thing. Not sophisticated
enough without vba (?) to compete with some of the other bundled solutions
(like Ventura's) but it certainly seems as capable as the Quark Xpress Xdata
XT that costs about $300 all by itself!

but this sort of thing falls outside the realm of "prepress" IMHO. It's
composition.