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

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

Arbortext 6.0 M020 Speed Issues

SarahPrice
10-Marble

Arbortext 6.0 M020 Speed Issues

We have just upgraded to Arbortext 6.0 M020 are having multiple speed issues. Whenever we try to print preview, publish or print a document with graphics it slows down to a snails pace and will lock up the workstation. We have some people running Print Composer and some on PE Server, same issues with speed. We have been in contact with PTC and made several configuration changes to PE to accomodate large document processing however speed is still an issue. We havemaxed out thememoryon all workstations. Still having problems. We are contemplating backing back down to 5.4 since this is a major set back in our production process. Has anyone else experienced these types of problems?


15 REPLIES 15

Hi Sarah,


Have you thought about going for M030?


M040 is due at the end of the month too.


Pete

We are getting ready to evaluate the next release in hopes that some of this has been resolves.



Upgrades for us are extremely painful. It took about 8 months to redo FOSI stylesheets and correct ACL scripts to work with 6.0 M020.


Sarah,

I am curious about the FOSI changes that were necessary. Do you have time to share a little?

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



We have a lot data formatted using algroups. All of the indents had to be adjusted because of data wrapping. Specifically in pseudo tables I went back into the old version to see how many characters a tag would except before wrapping and I found that the data never wrapped it just ran over into the next column. So that leads me to believe that this was broke in the previous version but fixed in this version.




Suzanne,
We also noticed that in 6.0 the logic in the FOSI seemed to behave differently. I can't remember specifics right now (we are still using 5.2) but I think I remember that we have some FOSI <att>s that check for the #NONE content of a text variable. In 5.2 if the text variable did not exist it was interpreted as content=#NONE. In 6.0 if the variable did not exist it was interpreted as having some sort of value which was not the same as #NONE so the <att> was returning a FALSE value. I am inferring this conclusion from the behavior and have not spent much more time analyzing it.
Like I said, I am a bit fuzzy on the specifics but I think I have expressed it as accurately as I can.

We also noticed that 6.0 seems to interpret keeps differently. We have some pages with two consecutive tables with the first table ending near the bottom of a page. In 5.2 the second table begins near the bottom of the page and prints 2 or 3 rows before breaking to the next page.
In 6.0 the second table will not start near the bottom of the page. The page will always break, with the second table beginning at the top of the next page.
We tried changing keeps values and adding and deleting keeps (together, with next, with previous) and nothing would stop the page breaking before the second table.

I'm pretty sure that the answer to this is "no", but I am going to ask anyway:
Does anyone know if there is a way to compare the numerical values of two variables (i.e. text variables) with each other in FOSI?

Such as if variable A.txt is greater than variable B.txt, then do something special.

Sort of like this:
<specval attname="A.txt" attloc="#FOSI" attval="#GT#B.txt">

I know that this doesn't work, and I sure can't figure out a way to do it. I need somebody smarter than me ( a large population ) to figure this out, or maybe it's not possible.

I've noticed some strangeness as well using 6.0M020:

* Tagged PDF difficulties

* Keeps issues (similar to what folks have been reporting)

* Repeating table titles causing tables to start a new page (so
title sits alone)



PTC support is very helpful in resolving these types of issues. I have
been logging support cases and encourage others to do the same so that
the software may improve.



Cheers,

Jason





Jason Aiken

Sr. Consultant

TerraXML, Inc.

I have logged several support cases with PTC as well and they have been very responsive. Although I haven't had any response as of yet to the speed issues. Documents with graphics I have found take up to 5 times as longer to print preview or publish.


I am doing something similar by triggering formatting rules for e-i-c where the root element att value is equal to the child's att value, by way of counters. This should be possible (or at least probable).

Set up a couple of uninitialized Arabic counters.

Once you get each variable value, set each counter with them like this:

<att>
<fillval attname="revlevel" fillcat="enumerat" fillchar="increm">
<charsubset>
<enumerat enumid="current-rev" setvalue="2"></charsubset>
</att>

Then you should be able to test against it like this:

<att>
<specval attname="revlevel" attval="#EQ#current-rev">
<charsubset>
<neat-stuff>
</charsubset>
</att>

One odd thing I've noticed, that the documentation seemed a little misleading on (I noticed it in your example), was that I didn't need to set the attloc to #FOSI. IIRC (which I might not, it was a few years ago when I coded this), I think my rule kept failing until I removed the #FOSI, and I think this was included in one of the documentation examples, so it took me a while to get this working.

Hope that helps...

-Jason

This can be done in the FOSI with counters.

<counter initial="0" style="arabic" enumid="Act">
<counter initial="0" style="arabic" enumid="Bct">

...
<att>
<specval attname="Act" attloc="#FOSI" attval="#EQ#Bct">
<charsubset>...</charsubset>
</att>
</e-i-c>


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


Strings also work (in 6.0):

<counter initial="0" style="arabic" enumid="Act">
<counter initial="0" style="arabic" enumid="Bct">

<stringdecl textid="Act.txt" literal="">
<stringdecl textid="Bct.txt" literal="">

...
<e-i-c gi="...">
<charlist inherit="1" charsubsetref="block">
<enumerat increm="1" enumid="Act">
<savetext textid="Act.txt" conrule="Act">
<savetext textid="Bct.txt" conrule="Bct">
...
<e-i-c gi="...">
...
<att>
<specval attname="Act.txt" attloc="#FOSI" attval="#GT#Bct.txt">
<charsubset>...</charsubset>
...





>----------

Further testing confirmed my suspicion that comparing strings is not the same as comparing counters. In the following, which is based on my previous examples, the specval comparing strings incorrectly succeeds, while the specval comparing counters correctly fails.

<enumerat increm="200" enumid="Act">
<enumerat increm="1000" enumid="Bct">
<savetext textid="Act.txt" conrule="Act">
<savetext textid="Bct.txt" conrule="Bct">

...
<att>
<specval attname="Act.txt" attloc="#FOSI" attval="#GT#Bct.txt">
<charsubset>...</charsubset>
</att>

<att><specval attname="Act" attloc="#FOSI" attval="#GT#Bct">
<charsubset>...</charsubset>
</att>


Suzanne



Thanks to everyone for their input. My condolences to those with performance and keeps issues -- there's little or nothing you can do in the FOSI to fix things.

Suzanne


We noticed that behaviour when one of our customers upgraded to 6.0.


We were to lucky to have only a few <att> to modify.



As for ACL, from 4.2 to 5.4, each version brought a net increase in speed. I hope 6.0 will continue that trend.



Pierre Chateil
LCI TechPub Sud-ouest
France



In Reply to Ed Benton:


Suzanne,
We also noticed that in 6.0 the logic in the FOSI seemed to behave differently. I can't remember specifics right now (we are still using 5.2) but I think I remember that we have some FOSI <att>s that check for the #NONE content of a text variable. In 5.2 if the text variable did not exist it was interpreted as content=#NONE. In 6.0 if the variable did not exist it was interpreted as having some sort of value which was not the same as #NONE so the <att> was returning a FALSE value. I am inferring this conclusion from the behavior and have not spent much more time analyzing it.
Like I said, I am a bit fuzzy on the specifics but I think I have expressed it as accurately as I can.

Announcements

Top Tags