Why not just have FP desktop run in "InDesign?"

Already have Fusion Pro doing a plug-in the program, why not just do everything there???

Fonts, Layout from customer, preview, just some of the issues. Plus, Acrobat crashes constantly(two completely different machines, latest CS3 update tested).

Hello,

Thanks for the great question. This speaks to the very core of our VDP technology and the unique approach we have taken with our products.

To start, one important item to point out is that most InDesign-based VDP solutions use the composition engine that's built into InDesign itself. FusionPro, on the other-hand, uses a composition engine built by Printable as opposed to a 3rd party such as Adobe or Quark. So, the VDP solution that's InDesign-based "asks" InDesign to create the VDP output as opposed to making these pages itself (like FusionPro does).

There's a whole host of reasons why we have chosen the Acrobat plug-in route as opposed to the InDesign approach for VDP template design. Here's a couple of the main ones:

1) InDesign was never designed to be a VDP solution. Adobe's InDesign product is designed to be a desktop graphic design package and this continues to be the focus of the product today. It was NOT designed to be a dynamic VDP layout and output solution. While it can be extended to deliver on some of the needs in VDP, it can be argued that this is an unnatural extension of the product to accomplish a task that it wasn't initially designed for. However, FusionPro was designed from the ground up to solve the unique challenges that designers face in the VDP workflow. Every line of code, every use-case, and every new capability is considered from a VDP perspective as opposed to a static page-layout design perspective.

2) Owning the composition engine source-code. The FusionPro VDP composition engine source-code is owned and maintained by Printable. This allows us to extend any aspect of the product as needed to meet the needs of the VDP user. This is not the case with InDesign as the source-code of the composition engine is owned and maintained by Adobe. Going the InDesign route for VDP can result in situations where the product can simply not be extended to meet specific VDP needs as the VDP vendor does not have access to the InDesign source-code. This is not the case with FusionPro as our team can make any change necessary to meet the VDP user needs.

3) Adobe PDF is the defacto standard for electronic print documents. The Adobe PDF document format offers some great features (document portability, WYSIWYG on every computer/printer, free proofing with Reader, etc) that no other document format offers. PDF can be created from any program (Quark, InDesign, Illustrator, MS Office, etc) thus it opens the wides set of possibilities for the user to accept base-artwork. This is a key reason why we have chosen the Adobe PDF workflow as opposed to an InDesign workflow.

4) Time to market! With every new release of the InDesign product, solutions that utilize InDesign as the composition engine must re-examine their entire integration to InDesign to determine what has changed in the API from the previous version. This process often results in moderate to extreme re-coding efforts for the integration to support a new version of InDesign. Spending all this time coding to the new version to deliver the same functionality as was in the previous version both impacts speed to market (there are numerous VDP products that still do not support InDesign CS4 - we've supported it since January) as well as the time that could better be spent on new functionality in the VDP solution.

These factors are just 4 of many reasons why Printable has chosen to go the Adobe PDF and Acrobat plug-in route as opposed to a full InDesign route for our VDP solutions. We recognize that InDesign is one of the most popular page-layout applications on the market thus we offer the InDesign export plug-in to aide users in migrating to the Adobe PDF workflow where we perform our VDP work. It should also be noted that while many users are using InDesign for all of their base-design for their VDP templates, there are many, many users that do not (a number of templates start as completely blank pages - other users do not have the InDesign product at all) thus an InDesign-only solution would not be something that those users could utilize to meet their VDP needs.

Hopefully this helps explain why we have chosen the Adobe PDF/Acrobat route as opposed to the InDesign route. If you have any additional questions about this, please let us know at your convenience.

Thanks!

Hello,

Hopefully this helps explain why we have chosen the Adobe PDF/Acrobat route as opposed to the InDesign route. If you have any additional questions about this, please let us know at your convenience.

 

Thanks!

Great answer! From a workflow perspective, I can also state that this workflow also opens up many possibilities that we, in the print world, deal with on a daily basis..

We don't always get pristine files. We get Powerpoint, MS Word, Publisher, Excel files from clients that simply do not know any better or lack the resources and/or training to produce files for print. By having Fusion Pro as a PDF based solution, it does offer the ability to deal with these non-conforming files and produce product with them. That, in itself, is a bullet-able feature to add to the list!

Another great feature is the list of output formats that FP supports. Anyone that has used, let's pick XmPie, drools at the fact that each of these output choices comes at a considerably priced add-on.

I have yet to see anyone that has put FusionPro into production that has not been satisfied.. Is there things that you cannot do in it? Sure. IMHO, Printable does react pretty well to trying to integrate users' requests into the package.

Which brings up the question, is there a request or suggestion section on this forum? If not, could one be added? It would be the best data mone you could ask for to find out what to concentrate on?

-Mark- (the other one)

I used XMpie for 4 years and FP is way more "USER" friendly when it comes to programming. I don't care much for Javascript as I'm not code savvy.

Just curious as I'm just used to using InDesign. I'm getting used to the program and I'm dealing with only "one" monitor. If you ever went from using two-monitors to one-monitor work-flow, you know what I mean.

What are people using for changing artwork in Acrobat? professional, Pit-Stop??? I'm talking about either adding or changing text(minor change) or simple X/Y coordinates for a "Dear" Letter. I'm really a novice when it comes to Acrobat and what it can do.

Thanks for the great answer also!

Ryan:)

Just curious as I'm just used to using InDesign. I'm getting used to the program and I'm dealing with only "one" monitor. If you ever went from using two-monitors to one-monitor work-flow, you know what I mean.

I feel you there.. I had a Macbook Pro and Cinema display for the palettes until the job market changed.. Adobe products are real estate hungry!

What are people using for changing artwork in Acrobat? professional, Pit-Stop??? I'm talking about either adding or changing text(minor change) or simple X/Y coordinates for a "Dear" Letter. I'm really a novice when it comes to Acrobat and what it can do.

Thanks for the great answer also!

Ryan:)

Hands down, Pitstop.. there is so much you can do in it, it is amazing. Heck, you can even get Microsoft documents to print correctly.. Whenever you do a task in global changes, save it as an action list - you will never have to do it again or use it for altering slightly for another task.

I keep a stash folder for JavaScript that I have used in the past. I try to comment all of my rules so three months from now I have a clue as to what I was trying to accomplish.

This forum has a wealth of information and a bunch of people who are willing to help.. Just put out an effort and when you get stuck, ask..

I agree with the decision to have FP run in Acrobat. It is a common ground to bring files in from multiple originating softwares and platforms. However, I do have constant issues with customers creating overly formatted text that FP just will not translate correctly, especially from InDesign. In these cases, I either have to try to reinvent their formatting (which is usually a compromise at best), or switch to my alternative program, Kodak's DarwinPro (which currently fails to support transparency!). I really wish the FP text formatting was much more robust, and would more closely mimic what the vast majority of designers are using these days, InDesign. Nothing is more aggravating to me than to have to recreate text formatting on a HOT variable job, with the press operator and salesperson breathing down my neck.

Scott Schardan

FP 6.0

Mac OS 10.4.11

Nothing is more aggravating to me than to have to recreate text formatting on a HOT variable job, with the press operator and salesperson breathing down my neck.

They expect every job to be done in the same amount of time. Whether it's a basic postcard setup to a multiple graphic/multiple text with formatting and programming that is involved, they think it should be a "breeze."

Once I start explaining the situation to them that you have to do this in-order for this to work and so-forth, they start to see the "big" picture.

I trained a traditional off-set guy who knew nothing on variable data prep and he was blown away on everything that could go wrong if not done correctly. From prepping data(postal software), prepping artwork, merging the two together, Ripping the artwork and getting it to print correctly at the press. If anything minor is off, the whole job is TOAST.