Apache OpenOffice Community Forum

This is the continuation of this question about parallel columns, which got to be too long, and I found big errors --
http://user.services.openoffice.org/en/ ... f=7&t=2346

Basically I was trying to display big files in parallel columns, for text comparison. Everyone said I could use tables to do this, and many criticized me, saying that this was "obvious" and they did not see any problem, why did I resist using tables? Well, here is the reason. Member acknak kindly torture tested Writer with a huge example -- a file 816 pages long. As I tried to add some small "gutter" columns between the text and reformat all columns, I found it impossible to complete without error, leaving it for hours. I assumed the file was simply too big to handle.

So I sized the file acknak provided down to less than 100 pages. Same problem, except instead of taking hours, it only took several minutes to seize Writer 2.3.1. I could add 2 gutter columns of 0.3" each without much problem, but Writer does an atrocious job of compensating for the major text columns (it doesn't). They remain too small. When I tried to resize any of the 3 original text columns, Writer eventually failed, and never completed, after 1-2 hours.

Obviously this feature has never been debugged correctly, a common problem with "group authored" software. If you don't believe me, try it, I tried to attach the file here, but the error is "The file is too big, maximum allowed size is 128 KB." Please tell me how to upload or post a 234KB file and I will do it for you to work on. Try to add 2 gutter columns of 0.3" between each text column, see the resulting bad display. Then try to resize each text column to 2.11" which would make up a full page, if you calculate it. You will see that Writer freezes and never completes.

I am working on an XP 2500 system with 1 GB RAM. That should be more than fast enough for this program, if it did not have this undebugged flaw in it. The result is, Writer 2.3.1 is incapable of resizing columns correctly to attempt to simulate a "parallel column" text layout, of the kind everyyone needs when comparing big texts.

Unless someone can come up with a working solution, Writer 2.3.1 is unable to handle parallel texts correctly.

This is obviously a SERIOUS flaw in the software. The whole point of using tables was to get around the fact that Writer cannot handle "parallel columns" (see the other discussion for my explanation of what they are). Now it seems that the whole premise "tables is all you need to simulate parallel columns" is flawed. Please help if you know how.

I'm giving it a try now, we'll see how it goes.

I could be biased, but it seems to me that OOo simply works better on Linux than it does on Windows. I honestly don't know why that should be, but I seem to hear more reports of crashes and mysterious problems on Windows. Of course there are far more Windows users, so that may account for it.

I think Unix/Linux is the primary platform for the Sun developers, and it may be that the compilers and other tools are somewhat more robust. That's just my guess; I'm not trying to start an OS war.

If I were contemplating such a project, I would be very skeptical about using something like OOo for it. OOo simply cannot handle some common (but complex) layouts that are used in scholarly or reference works. I don't know what tools people do use, but I have no doubt that it isn't any of the common "office suite" word processors.

If I were to try it with OOo Writer, one strategy that should be safest is to work in the smallest chunks possible.

OOo has good facilities for combining smaller documents into one larger document. You could work on one chapter at a time, which would drastically improve the performance and reliability.

In any case, this is a complex project and it will require a fairly high level of familiarity with the software, and some trial and error to find the best approach.

I just got the document loaded and added two columns. OOo is still working on doing that--I'll let you know what happens.

Ok, it's done. I opened up the full u3.odt document, added two gutter columns and saved it again. It took about 45 minutes in total, and that included some backtracking on my part. My final column layout was 2.20", 0.08", 2.20", 0.07", 2.20" for a total of 6.75".

The gutter columns were much wider to start with, as OOo tries to adjust all the columns if you insert new ones. So it has to re-paginate the whole thing, then re-do the same job when you shrink the columns down again. Unfortunately, I don't see any way to avoid that.

I used the Table > Table Properties > Columns dialog to set the widths, rather than trying to drag the table outlines.

I would also note that this is not the way a real document would work. You would normally adjust the page layout and column widths up front, when there is at most a few pages worth of text in the table. You wouldn't wait until you have 600 pages and then try to add new columns.

I uploaded the modified document to the same location as before: u3.odt (1.9 Mb).

I'm not sure what exactly to conclude from this, except that it can be done. Why you encountered such problems, I don't know.

acknak wrote:Unfortunately, I don't see any way to avoid that.

Just insert a new table, adjust the column widths, then cut and paste the text again.

Good point!

acknak -- are you running this on linux? I certainly agree with your statement --
"I think Unix/Linux is the primary platform for the Sun developers, and it may be that the compilers and other tools are somewhat more robust."

I know better than anyone the problems on windows -- have to deal with them all the time. I did everything exactly the same as you did, but I didn't save after adding the gutters. I immediately at that point right clicked on the left column and sized it back up to 2.11" -- and that is when it froze. So I shut down, restarted, and did it all over again, but tried to resize the right column instead. Froze solid again. Not when adding the gutter columns, only resizing the main text columns.

Bhikkhu -- are you also running linux? Could explain it, unix is a much more stable platform than windows for recovery. Also, remember, I did this after cutting your file, acknak, down to just under 100 pages. Baffling ......

I could not open the file under discussion, possibly not enough machine, possibly not enough patience. What about breaking the document into smaller sub-documents of one master document? Will that help?

NTP

I can open it, but any action I try to take on it runs the CPU usage up to 100%, with soffice.bin taking from 80 to 99 percent itself. I wanted to see if I could duplicate scrathcyboy's crashes, so this makes me believe it could very well have to do with Windows memory management somehow. I had to kill the process.

I then created a new document with a 3-column table (intending to use spacing to content to create whitespace, instead of extra columns) and populated the first column with "Specimens of Greek Tragedy — Aeschylus and Sophocles" from Project Gutenberg, which, minus the front and back matter and the several pages of Project Gutenberg marketspeak, is 216 pages of a narrow poem format (which I thought might fit well in a table column and be short enough of a text to approximate a book chapter)---but the same thing happened. Actually, Writer is hanging at 96% rendering the document, so I'll go to my meeting and come back in an hour, and see if it's finished yet. But it appears that OOo on Windows (at least WinXP) is not able to gracefully handle a single table row that spans hundreds of pages.

RevNomad -- Yes, I tried to upload my 280KB reduction of the file down to less than 100 pages, it was much more manageable. But I cannot upload it, the file limit on this BBS is less than half that.

Foxcole, rest assured, exactly the same thing happened on my <100 page file, cpu usage immediately went to 99% and wavered between 95-99% constantly, even for hours. Only on the resize of a text cell, not on adding the gutters.

"But it appears that OOo on Windows (at least WinXP) is not able to gracefully handle a single table row that spans hundreds of pages."

That was EXACTLY my conclusion. Of course, we shouldn't be surprised (a) that windows multi-thread handling is not as good as the lin-unix implementation, or (b) that the product is not as completely debugged on Win as on Linux.

So I guess David from the previous thread was right, when he replied to acknak, paraphrasing his words "it remains to be seen if the table layout is stable over that many pages." I guess we have our answer, no??

Thanks again to all who have stuck with this thread. It is hopefully at least a learning experience for you all, which you can later hit up OO developers to fix, if you are so inclined. I have had to give up on Writer for this project.

However, all is not lost. I've tried every other modern wordprocessor imaginable, and none do these parallel columns with ease -- Writer is in the same class as WPerf -- buggy and unstable. BUT !! I remembered that several years ago, I wrote a 500 page book with what may now be considered an "outdated" word processor. It was lotus WordPro, and I recall it was very smooth and extremely stable for long documents. Trouble is, it only ran on Win98, not on XP. So I fired up a 98SE system, installed it, and lo and behold, there is the parallel column choice just sitting there to be grabbed !! So I grabbed it, and was AMAZED !! at how many features, microjustification, buffer margins and all sorts of goodies were available in the program. It truly outshines EVERYTHING else I have used for this task. Also the formatted output is beautiful, and since I already know it is stable for long documents, I will assume that it has been debugged by IBM adequately for parallel columns (they used this program to write tons of documentation).

Therefore, that is the ONLY solution, and that is what I am going with. If I have to run 98SE to run it, so be it. I think it works OK on XP, but they want a fortune for the XP updated version, and I simply cannot afford IBM's kind of money. So, again -- thanks to everyone who stuck with it - even you focxcole - you are all GREAT, GREAT GREAT!!

I had a chance to try this on an XP system today: it's a P3-800 with 512M RAM.

It works. I can load the document, edit it, and the rest of the system is usable as well--after the document is completely loaded in Writer, which took about 40 minutes. The Windows task manager shows soffice.bin taking about 39Mb of memory with the document loaded.

I don't know what might account for the different results. This is an older Dell machine, so the hardware should be pretty solid. It's only lightly used, so very little "Internet crap" installed. It runs no antivirus or security software; we depend on the firewall. XP is kept updated.

I'm not trying to argue anything--if it doesn't work for you, it doesn't work. But it's not a bug in OOo or XP.