cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

Arbortext Print Composer versus Arbortext Publishing Engine

aleslie
1-Visitor

Arbortext Print Composer versus Arbortext Publishing Engine

When choosing between Print Composer as opposed to Arbortext Publishing Engine for generating PDFs, am I correct in saying that the former is more suitable for lower levels of output rather than the latter which is suitable for very high levels of output ?

Please can someome clarify when one should use the latter over the former ?

Regards,

Andy

9 REPLIES 9

Hi Andy,

Print Composer is designed for desktop usage, whereas Publishing Engine
is designed for server usage. All else being equal, either product
should produce identical outputs from the same input. Publishing Engine
also includes much more additional functionality, such as Web Composer,
Import/Export, Digital Media Publisher etc.

BTW, I thought I heard rumour that Print Composer is being phased out
(Arbortext Styler includes identical functionality) but I don't know how
true that rumour is. What I do know is that the current Arbortext
Reseller price lists from PTC don't include the Print Composer product.

Cheers,
Gareth

It's not quite that simple as they are two different programs. If there is any doubt about your quantity of output then chances are good that you do not need the hugely expensive APE.

The print composer is client-side publishing software that is inexpensive, but has no good way to queue large numbers of documents. It runs on a single computer - not necessarily a server. It can use the individual Adobe Acrobat instead of requiring the 10x more expensive Adobe server software. For some of us it is the only game in town because APE costs more than our annual budget (including salaries) for producing PDFs. We already purchased the Print Composer before E-3 (PE as it is know now) was available and management won't go for buying something new at 10 to 50 times the cost when we have something that works so well.

Arbortext Publishing Engine is "server-side" publishing software that is expensive and probably too hard to use. There have been times when Arbortext tells me I "could use" APE to solve a problem, but when they find out that I have no budget they usually know how to do it on Print Composer. For installation Arbortext Publishing Engine requires a Windows server and (if I remember correctly) the "How to install E-3" training course used to cost $34,000. No idea what your training costs would be, but without the right training APE might just be something you buy and never get up and running.

Hope this helps,
-Andy Esslinger

We have the PE. PTC came here and set it up for us. I'm not in Accounting and it was before I started helping so I don't have a clue about the cost.

I've upgraded it a few times and I would say it was like installing just about any other server software. Mostly it works out of the box, but there are probably hundreds of settings (a mini-webserver, Java, the PE itself, plus fine-tuning the server software) that might need adjusting for your particular application. Some of it is well documented, some of it isn't. They do provide a PDF of many of the settings, but as usual the documentation has no examples, just descriptions.

If you can install Linux on your personal computer and get every single device compiled in and working, then you could install PE and probably get it running and tuned up by yourself.

Having it on the server is both a good thing and a bad thing. It says it does a great job of tracking graphics from your desktop to the server for instance...however our Army stylesheet wasn't built for the PE and it strips out path locations, making graphic PIs necessary to get PE to partially work for us - although the PE documentation says graphic PIs might make things worse on a PE.

Another issue is we have a 38,000 page book with a medium amount of gentext and graphics that won't print. The largest chapter - 15,000 pages - won't print. Java heap error. PTC has a copy and they are working on it, but so far the answer is to wait for PE version 6 and run it on a 64-bit Windows server 2008 - this will be the first time ever you can truly break the 2GB/3GB RAM limit.

One good thing on a 4-5 hour run is that about 2/3rds of that is on the server so you can get back to work sooner, anyway.

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support,Land & Armaments/Global Tactical Systems

T832.673.2147 | M 832.363.7234 | F 832.673.2376| x1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

Hi Andy--

Here's my take on it: Print composer is just fine if you are a single person producing a single document at a time, and those documents tend not to be very big.

Publishing Engine is meant for settings where you have multiple authors publishing a reasonably high volume of documents. It's a continuum: the more people you have publishing, and the more documents they are publishing, the more PE makes sense. As Gareth pointed out, you do get some additional capabilities with PE that aren't directly related to producing PDF output.

Also, I'd like to temper Andy E's pessimism about PE a bit. Yes, it is a server-based product, so there's a bit more to setting it up than just running an installer. And in the past I, too, have had the frustration of PE being beyond the scope of my budget and having to do without it. However, in my judgment setting up PE is not as difficult as it might sound from Andy's description. PE comes with pretty decent documentation, and an experienced system administrator ought to be able to get a basic configuration up and running without too much trouble.

On the other hand, PE does have the complexity to support a lot of configuration options as well as your own customized publication functions. If you want to use those features, then of course you will need to get some more in-depth knowledge. In that case, either training courses or the help of a consultant (or both) would be a good investment.

--Clay

Hi Andy,

It sounds like you have had some pretty scary quotes for PE in the past.
The bottom line is that PE is worth the expense only if it brings the
value that a business requires. Having said that, the balance has been
tipped in favour of PE recently with some great added value through
features such as Advanced Print Publisher (3B2) and DMP that now ship as
part of PE itself.

I think rather than focussing purely on up-front software cost, it is
rational to perform an ROI study based on projected business use and
benefits. For example, it may turn out all you need is an off-the-shelf
XSL-FO engine - so why buy Print Composer? On the other hand, it may
turn out that getting PE will save a fortune in production costs, eg.
the Advanced Print Publisher option lets you shortcut what was
previously a bunch of costly manual workarounds. Or the DMP feature
opens up new markets and revenue to the business. You get the idea.

I hope I'm not sounding like a PTC fanboy 🙂 I just wanted to make the
point that I do think PE has it's place, as does XSL-FO, InDesign and
all the other great Arbortext publishing products such as Styler and
Print Composer.

Cheers,
Gareth

The group I support consists of 18 authors, 3 editors, 2 translators and 1 developer (me). We publish technical books with up to 1600 pages, containing as many as 220 EPS graphics and about 18% generated text (all cross references, numbering, TOCs and indexes). We release about 12-15 books per year. The DTDs and FOSIs we use are all custom, maintained in-house.

We've used Arbortext since the Adept 5.0 days and always used Print Composer for composition. Print Composer is installed with Editor on every user's PC; we need just 4 concurrent licenses for Print Composer. Acrobat Distiller is also installed on each user's PC for creation of PDFs if required. Licenses, doctypes and configuration files for this environment are maintained on a single system to ensure consistent performance and output.

The cost of this setup is a small fraction of the cost for the Publishing Engine alternative. We simply could not justify the PE costs, we'd never get management approval for the expense.

It would severely cripple our operations if Print Composer were phased out. Styler is not an equivalent replacement for FOSI and, in my (limited) experience, is more difficult to use when formatting needs become complex.

Publishing Engine certainly has a place in large organizations but for an organization of our size Print Composer is the only cost-effective solution provided by Arbortext.

Cheers,

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

I'll add my two cents.

Yes PE has additional capability in terms of tools and output capabilities
-if you can use them or have need for them then ther is no choice. If you
have a need for large publications and many many writers printing at one
time or huge volume there is no other choice.

On the other hand if you have a severly IT/security related environment,
using PE is a pain to use. PTC wants all the stylesheets and configuration
on the server machine. You need access to that machine to make changes.
You need to restart the server at different points to get stylesheet
changes recognized. All this is not terrible if you can make those
changes, but trying to get an IT person to focus and support you in a
timely manner makes this a difficult situation at best. Then try and
trouble shoot something with PTC when they ask you to make a change or
reboot becomes difficult. We then found some issues with processing steps
that worked differently for composer than PE. Graphics are handled
diffeently where they are missing composer ignored the problem where PE
just shut down with no useful error message. I find PE to be much more
finicy/quirk in its operation. I had stylesheets that worked locally when
tested but would not work immediately in PE due to configuration and
server memory refreshing/buffering that made troubleshooting more
difficult than it needed to be.

We added PE to a working environment in which I had custom directories
setup, everyone pointed to this location and stylesheet development being
managed from their. The Editor works with the APTCUSTOM variable yet PE is
bascially only supported if you have all this on the server in some way.
You either have to move your development environment to the PE server or
use some tool like ant to keep directories consistent (and then remember
to restart/refresh PS so those changes are recognized). this then caused
issues with our IT rules - not a PTC issue but it is the reality of the
environments their product is used in.

Also, even if you have PE, a copy of Styler or Composer would be required
to do any stylesheet development.

As others have said, PE has its place and advanatages, but at the same
time it brings an overhead cost - software cost beig one of them. I
recommend keeping it simple if you can, if you can't then you need to bite
the bullet on cost and complexity - everything is a tradeoff depending
upon your requirements.

..dan

> Hi Andy--
>
> Here's my take on it: Print composer is just fine if you are a single
> person producing a single document at a time, and those documents tend not
> to be very big.
>
> Publishing Engine is meant for settings where you have multiple authors
> publishing a reasonably high volume of documents. It's a continuum: the
> more people you have publishing, and the more documents they are
> publishing, the more PE makes sense. As Gareth pointed out, you do get
> some additional capabilities with PE that aren't directly related to
> producing PDF output.
>
> Also, I'd like to temper Andy E's pessimism about PE a bit. Yes, it is a
> server-based product, so there's a bit more to setting it up than just
> running an installer. And in the past I, too, have had the frustration of
> PE being beyond the scope of my budget and having to do without it.
> However, in my judgment setting up PE is not as difficult as it might
> sound from Andy's description. PE comes with pretty decent documentation,
> and an experienced system administrator ought to be able to get a basic
> configuration up and running without too much trouble.
>
> On the other hand, PE does have the complexity to support a lot of
> configuration options as well as your own customized publication
> functions. If you want to use those features, then of course you will need
> to get some more in-depth knowledge. In that case, either training courses
> or the help of a consultant (or both) would be a good investment.
>
> --Clay
>
ebenton
1-Visitor
(To:aleslie)

I know this is not a survey, but we use Print Composer for similar-size books and most of the same reasons, plus the custom software that we maintain, which incorporates Arbortext Editor , Print Composer, Adobe Acrobat (Distiller) and some others, is used by 3 or 4 other defense "co-contractor" companies, and most of them can't afford PE at all.

Our group sounds a lot like Mr. Taylor's, but on a larger scale. We support over 100 authors scattered throughout the U.S., Canada, England, Germany, and India. They all access our PE server in Shoreview, MN, for generating PDFs. Our PE server is a Sun machine running Windows Server 2003 and has dual-CPUs. It is incredibly fast. Our PDFs and all FOSI-driven and we use exclusively the direct-to-PDF mode. Locally, I have a Styler license and can generate direct PDF for FOSI development. We also use Styler to generate the authoring view (but because of some strange Styler errors, I export as a FOSI and that's what get stored in the doctypes).

We started with Adept 5 as well and used Print Composer for just about everything until PE (then E3) came along. Fortunately for me, another one of our developers handles the PE configuration, etc. I only upload FOSIs and restart the server when necessary.

Besides over 100 authors, we have 5 or 6 editors and in our group 6 developers. Our XML system is entirely custom and schema-driven throughout.

Having Styler doesn't mean you have to use styler for your print formatting. As I mentioned, I use the Styler direct-to-PDF to test our FOSI-based print doctypes. So, I think it is an excellent replacement for print composer.

Dave Hintz
Siemens
Announcements

Top Tags