We have been using Arbortext as a publishing tool for almost a year now. So far we have not had too many issues we haven't been able to overcome. Typically our documents are between 50 - 200 rendered pages and contain images, lists, cross references, and often many tables.
From time to time, I get complaints from users indicating that after rendering documents multiple times, they get segment violations and Arbortext closes. The work around is to restart and keep going.
It seems that the more complex the tables get (cell spanning) the more likely we have issues. For fun, I took a document and copied the content many times over to see what would happen when we have a larger document - the result is Arbortext will just crash about 330 pages or so into rendering. From a system perspective, I can see memory usage climb (x32 version here) to just over 1.1 GB before the crash. The error I commonly see is editor.exe: segment violation (signal 11).
My question is this, how do others handle these issues and are there other settings under the covers that will allow Arbortext more memory or to process larger files? I am a bit nervous that someday soon we may run into a 600 page document that cannot be handled.
I looked into some of the stylesheet profiling tools - but again with the error message I am seeing - it doesn't tell me what is really happeneing. For reference we are using the APP engine and have a custom schema/stylesheet.
Any advise is welcome.
The first port of call should be switching to the 64-bit version of Arbortext (available with the 6.0 version but not with 5.4 or earlier). That will give you an easy way to test if the 32-bit limits are the main problem (32-bit processes under Windows are usually limited to 2GB RAM usage).
If that doesn't help then you may need to tweak or rewrite your stylesheet. There are not really any useful performance tweaks for print composition. We find that the main problem is the APP code generated by Arbortext Styler is not very optimised. Our company GPSL is a specialist provider of Arbortext and APP solutions and we have built many native APP stylesheets (aka templates) which are able to process jobs well into the thousands of pages.
In fact I was just testing a 3700 page job the other day. It composes in under 2 minutes and uses approximately 250MB of RAM, which indicates what APP is capable of. There is another customer I remember whose jobs often contained tables spanning 200-300 pages and while performance was slower it did work without crashing.
Thanks for the prompt reply. I'll give the 64bit edition a try and see if we are just talking about a memory issue or something else. I'll post back once I have tried that.
We are also facing this issue quite oftenly. Plase explain us how you resolved and it would be so helpful for us?
I have found the following alert on 64bit Arbortext Editor 6 of my customer company.
Please let me know how to increase memory of TeX (pubtex) processing.
# For typical TeX, add "main_memory=4000000" into texmf.cnf.
We have not yet solved the issues with large documents and tables etc. My vendor is looking into it - but as this has not yet impacted us negatively this is a lower priority for us. We will be looking into this further in the coming months as I know it will become more of an issue.
I will post back if I do figure anything out.
I have the same issue with segment violations. The solution I found was to increase the virtual memory of the disk used to generate PDF. I still have some segment violations but it is occuring less often.
I am using a Windows 32-bits and I will use a 64-bits sooner or later, so I will see if it makes a difference.
We are experiencing this same issue when creating a PDF with one particular ditamap, and it too is full of tables. We are using Arbortext Editor 6.0 with Styler (64-bit). Are there any table best practices that we can use to help resolve this problem and remove the error? This problem is not resolved by shutting down or restarting. We get the same error, every day, with the same one ditamap file. Just wondering if anyone has any ideas other than recreating a new ditamap. Thanks!