Re: Large Flare projects (2,000+ pages)

Subject: Re: Large Flare projects (2,000+ pages)
From: Shawn Connelly <shawn -at- cohodata -dot- com>
To: "Janoff, Steven" <Steven -dot- Janoff -at- hologic -dot- com>
Date: Wed, 26 Aug 2015 18:02:11 -0700

Hello Steven,

Sorry I am late to this conversation, though I am pleased that you found a

I am a MadCap Flare v11 user (switched from FM to Flare v9 with mixed
results - meaning, I both "love" and "hate" Flare - LOL)

Two points, I would love to ask you about:

Earlier, you said,
*"and Support indicated (today) that the solution we're looking for is
outside their scope, and they have no easy solution within Flare."*

I am curious, could you elaborate on what MadCap support claimed was out of
their scope. It just doesn't seem like MadCap support.

Later, you said,
*"The 2,000+-pagers come out in a minute or two, as a single PDF. No


I found that jumping from v10 to v11 resulted in a slight drop in
publishing speed (to both HTML5 and PDF). Still, my Flare publishes at an
average rate of 1.8 seconds per page. In other words, 2000 pages would take
approximately 1 hour. That is when I process a job on my workstation. I
also have a python script which sends new documents to a build server and
uses madbuild.exe for remote document building. But even the dedicated
server takes a long time to complete (~ 1.4 seconds per page).

My documents are quite graphic rich plus since [vector] PDF image support
was added, one of the greatest bottlenecks is the processing of PDF images.
In fact, about 40% of the publishing time is spent on those images, so that
definitely skews the time per page value.

I am guessing your documents are mostly text? If not, what might be your

Best regards,

On Thu, Aug 13, 2015 at 4:52 PM, Janoff, Steven <Steven -dot- Janoff -at- hologic -dot- com>

> > Is it that difficult and requires such kid gloves? ...
> No and no.
> The 2,000+-pagers come out in a minute or two, as a single PDF. No
> problem.
> 15 minutes is a long time, even for 4,000 pages.
> Flare has improved its PDF tools, but Frame has always been PDF-centric.
> Speed of the build seems to have more to do with resources than the app.
> E.g., local desktop vs. network server, processing speed, how full the
> drive is. Splitting and merging PDFs seems like a difficult workflow but
> if it buys speed, it's a good idea.
> Steve
> On Thursday, August 13, 2015 9:07 AM, John Posada wrote:
> Is it that difficult and requires such kid gloves? I have 8 books over
> 2000 pages each, with 2 of them over 4000 in FM and FM doesnt bat an eye on
> PDF output and takes less than 15 minutes from TOC to print que. I was
> considering running a beta project in Flare but this conversation has made
> me rethink it.
*Shawn Connelly*
Technical writer
Learn more about Adobe Technical Communication Suite (2015 Release) |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Re: Large Flare projects (2,000+ pages): From: Matt Danda
Re: Large Flare projects (2,000+ pages): From: Andrew Harvie
Re: Large Flare projects (2,000+ pages): From: John Posada
RE: Large Flare projects (2,000+ pages): From: Janoff, Steven

Previous by Author: RE: manual vs white paper
Next by Author: Re: "Software Technical Writing is a Dying Career"
Previous by Thread: Re: Large Flare projects (2,000+ pages)
Next by Thread: RE: Large Flare projects (2,000+ pages)

What this post helpful? Share it with friends and colleagues:

Sponsored Ads