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

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Arbortext Editor performance

ptc-953926
1-Newbie

Arbortext Editor performance

Adepters:

Our users are asking if there's anything they can do to improve the performance of Arbortext Editor (5.2, patch M130). Their main complaints are the length of time it takes to open a large document and that copy/paste and undo take a long time. I've told them to disable auto-updates of generated text, but was wondering if anyone has other suggestions?

Thanks,
Dave
11 REPLIES 11

I suggest to my writers to collapse any part of the file such as a 
chapter or table not being edited.



On May 29, 2009, at 1:16 PM, "Hintz, David L" 
<-> wrote:

> Adepters:
>
>
>
> Our users are asking if there’s anything they can do to improve the 
> performance of Arbortext Editor (5.2, patch M130).  Their main compl
> aints are the length of time it takes to open a large document and t
> hat copy/paste and undo take a long time.  I’ve told them to disable
>  auto-updates of generated text, but was wondering if anyone has oth
> er suggestions?
>
>
>
> Thanks,
>
> Dave
>
>
>
> ----------

Dave,

Check out help 6613, Improving performance for variables used only in specific regions.

Good luck!
Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"


Thanks, Suzanne! I should have mentioned that we’re using Styler for the authoring interface, so I don’t know if that help is applicable or how it applies to Styler. I was wondering, though, if performance would improve if I exported Styler to a FOSI and distributed that with the DocType? I wonder if anyone has done any tests comparing Styler performance with FOSI performance strictly for authoring?

Dave

I did exactly such research at another job and can confirm that having a screen-only FOSI was better in terms of authoring performance.

Regards,
Jason

If the document is table-heavy, you can suppress the graphic display of
tables for a performance boost.

If the custom folder is located on the network (and you have network issues)
or over VPN, you can support a local custom folder on the author's
workstation that can be manually refreshed (or, perhaps refreshed once a
day, week, or on trigger ... depends on how fancy you want to get).

I agree, a screen FOSI would probably be faster than a screen stylersheet,
especially if you edit it down to only the code relevant for screen display.

I assume we're talking a hand-crafted screen FOSI right? Because,
behind the scenes, a stylersheet is transformed to a FOSI anyway for
screen display...

-G

Quoting Paul Nagai <->:

> If the document is table-heavy, you can suppress the graphic display of
> tables for a performance boost.
>
> If the custom folder is located on the network (and you have network issues)
> or over VPN, you can support a local custom folder on the author's
> workstation that can be manually refreshed (or, perhaps refreshed once a
> day, week, or on trigger ... depends on how fancy you want to get).
>
> I agree, a screen FOSI would probably be faster than a screen stylersheet,
> especially if you edit it down to only the code relevant for screen display.
>
> On Fri, May 29, 2009 at 2:44 PM, Jason Aiken
> <jaiken@infotrustgroup.com>wrote:
>
>> I did exactly such research at another job and can confirm that having a
>> screen-only FOSI was better in terms of authoring performance.
>>
>>
>>
>> Regards,
>> Jason
>>
>>
>>
>> *From:* Hintz, David L [

David,

Are your large documents broken up into fragments? We break our
documents into fragments and encourage authors/editors to work at the
fragment level for most work. They only need to open the master
document occasionally to check their work and view the generated text
content.

Another consideration is how authors and editors are connected to the
source files. All our authoring and editing is done on Windows PCs, our
source library is maintained on Solaris servers. We were using
Hummingbird NFS Maestro to NFS mount the server directories on the PCs;
performance was very slow on larger documents. After some testing, we
switched to Samba connections which have been significantly faster.

Cheers,

David

We're using the Contenta CMS, so authors check out individual objects which can be a single topic or an object that is an entire set of topics that compose a book. I'm pretty sure that the performance issues occur when they check out an entire book.

When a CMS object is checked out, it is to the authors local Windows drive. So, there are no network issues involved.

I seem to recall hearing a rumor to this effect. It would be nice if someone from Arbortext could confirm or deny this fact. If a Styler stylesheet is always converted to a FOSI (presumably when a doctype is first opened), then it would seem that the only performance gain by using a FOSI in the first place is this brief conversion step.

Gareth is correct, when Arbortext Editor opens a .style file to use as
the stylesheet for the editing session, it converts it into a FOSI
internally. So you can do this conversion in advance by exporting a FOSI
from a .Style file and save the conversion. But this is usually a small
amount of time at the start of the editing session unless you have a
very large number of stylesheet modules.

John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

What we have done, and I what I suspect Jason has done, is to either craft a
FOSI either from scratch or, more likely, stripped down a Styler SaveAs
FOSI. In either case, extraneous code is removed, presentation is for screen
only ... not the same as for print. (WYSIWYN ... N=need ... to edit the
content) Doing this, it is possible to create a FOSI that is far faster than
the FOSI Styler creates on the fly or on SaveAs.

Top Tags