Trying to Diagnose document error

[DavidRGreen]

Do you want to: Ask a how-to question
OS version: Win 10 Pro
App version: 7.4.0.163 (x64 exe)
Downloaded from: ONLYOFFICE website

A document that I had last worked on version 7.3 now “dies” when the ToC is updated. I’ve had to delete the ToC to continue working on via OO.
Inserting a new ToC results in the same error.

Despite the message text “Save as…” does not work.

I found OO’s logs, but the only readable text is “leveldb.BytewiseComparator” in a MANIFEST file which from my perspective is not helpful, at least to me.

Opening the same document with MS Word does not indicate any issue, in either creating or updating the ToC.

Are there any switches to turn on more reporting so that I can attempt to diagnose what is happening with OO and and the ToC?

[DavidRGreen]

I managed to “repair” my document…

1. Opened it Libre Writer
2. Saved it to Libre’s native format
3. Recycled Libre Writer
4. Opened the Libre version of the document
5. Inserted the ToC, and saved in .docx format

Now the document has a ToC that is updatable in OO via “Update field” again.
If there is a debugging / logging option available, it might still be good to know, as, although I have repaired the document, I still have no idea what was causing the error during the ToC build.

[Alexandre]

Hello @DavidRGreen
As far as I understand, you’re describing the issue with table of contents. Would you mind providing test file and detailed description of scenario, so we can reproduce it. We would like to take a closer look at it.

[DavidRGreen]

Hi @Alexandre
The full version is hefty at 9MB.
But I found that I could delete most of it and it still illustrates the problem
https://drive.google.com/drive/folders/1OXIAIxEgUtr_6Hoyyi8_LqJemxV7m2DL?usp=sharing
This folder has the file;
USM Consumer Testing and Issues (trunc).docx which is under 300KB

Note that as per my previous post, I have fixed the document that I am working on.

The error occurs when I right-click / Update field on the Table of Contents.
And I have no idea what actually caused the issue to occur, so I can’t replicate that. Thus the original request to see if there was some sort of logging to point out the point of failure.

[Alexandre]

Hello @DavidRGreen

@DavidRGreen

This folder has the file;
USM Consumer Testing and Issues (trunc).docx which is under 300KB

So the issue scenario is following:

1. Open mentioned file
2. References >Update entire table.

Please let me know if I missed something. So far, the issue is reproducible with mentioned file, but I need your confirmation that test scenario is correct to continue the investigation.

[DavidRGreen]

Yes @Alexandre, excepting that I usually do it via the right-click context menu item.

[Alexandre]

Thank you, we are checking the situation.

[Alexandre]

Hello @DavidRGreen
I want to thank you for provided file. The situation looks strange, we have added a bug to internal tracksystem and we have started working on it.
Thank you for valuable data!

[DavidRGreen]

Ideally, capturing versions of the document before and after the error would facilitate working things out, but that is not possible.

I tried a comparison of the document.xml file between the faulty document and the repaired document, but not knowing the implications of the changes, it is difficult to identify a problem.

The Table of Contents specification had switches “z” and “u” removed during repair. I looked up their function, but not sure why they were there, but removing them did not effect any change.

<w:instrText xml:space="preserve"> TOC \o &quot;1-4&quot; \h \z \u </w:instrText>
<w:instrText xml:space="preserve"> TOC \o &quot;1-4&quot; \h</w:instrText>

I noticed changes in the id values of bookmark tags, but the ToC appears to use the name values, so nothing there either.

<w:bookmarkStart w:id="600" w:name="_Toc2"/>
<w:bookmarkStart w:id="1" w:name="_Toc2"/>

[Alexandre]

Thank you for pointing us to this situation. We are going to release a fix for mentioned situation with Document server v.7.4.1. I hope we release this version in a few weeks.

[DavidRGreen]

Thanks for the update @Alexandre, although I am surprised that this is a bug, I just expected to be labelled as an anomalous write error causing corruption.

[Alexandre]

Unfortunately, it was a bug. But we are planning to release a fix for it shortly (in the next version of the app).
Thank you one more time for pointing to this situation!

[Alexandre]

Hello @DavidRGreen
We have released v.7.4.1. This version contains a fix for described situation.
Thank you for valuable data!

[DavidRGreen]

Update to 7.4.1 completed… eventually.
The update link from the Help/About page attempted twice, but failed to run the installer after download. So I did it outside the application.

[Alexandre]

Sorry about that. We have found an issue with update scenario. So it’s better to download a fresh exe file from our website.

[DavidRGreen]

I suspect most will pick that route when the internal process is being temperamental
I noticed that the failed update attempts left behind the folder “DesktopEditorsUpdates”

which reminds me, I have to replace new.docx which the installer over-wrote, so that the spelling check for new documents is the correct version of English.

I think there’s a ticket outstanding for some sort of localisation setting for OO, defaulting to US English is just not the sort of thing I want to do. It’s all wrong

[Alexandre]

I believe users will not face the update issue in the future releases. Please accept our apologies for any inconvenience.

I think there’s a ticket outstanding for some sort of localisation setting for OO, defaulting to US English is just not the sort of thing I want to do.

I’m not sure that I’m following. Please describe it as detailed as possible, so we will be able to check out this scenario (or point me to the thread where we discussed it already).

[DavidRGreen]

Hi @Alexandre,
I tried looking for what I had seen, but nothing seemed to click. Bit like looking for a needle in a bunch of needles.

Anyway, when there is an install of OO, my document templates revert back to en-US. I am en-AU, and there is no en-AU template directory.
In an ideal world, having an en-AU directory with Australian English as the default would be the best. But failing that, en-GB works, as we in the great brown land down-under, use the Queen’s English, officially. Oops, that’s the King’s English now…

en-US is probably the fallback setting, as I would suspect that if OO is querying the OS for regional settings, it doesn’t have a en-AU template set to use.

Even if an enhancement went in to add an en-AU template set, that would make me happy, but to cover all situations may well be a large undertaking.

For instance, OO also doesn’t have a fr-LU template set. Albeit, those people use Flemish, the Dutch variation on French, but they would probably prefer fr-FR to en-US. Probably a bad example as there is only one fr template set, so it probably defaults to fr-FR anyway. But you get the idea.
There may be some Canadians who would prefer en-GB to en-US

Anyway, a useful enhancement would be, in my opinion, a setting to define the most desirable template locale. And in lieu of en-AU, I would set it to en-GB.

[Alexandre]

Hello @DavidRGreen

@DavidRGreen

I am en-AU, and there is no en-AU template directory.

As far as I understand, the update process re-writes your custom en-AU templates. Let’s focus on your case. Do I understand it right that the final goal of your suggestion is adding en-AU templates (Windows: Program Files\ONLYOFFICE\DesktopEditors\converter\empty) in your case?

[DavidRGreen]

Hi @Alexandre

The folder “en-AU” is present, but only because I created it and saved the respective “new” files there to see if OO would pick them up and use them.
… it didn’t.
But I never removed the directory and just used it as a holding area to en-AU templates that I could copy into the en-US folder so they would be used.

A previous issue, where the built-in installer failed to complete the installation, left behind an install image at;
C:\Program Files\ONLYOFFICE\DesktopEditorsUpdates\DesktopEditors

those are the only English language folders created.

My current install, still has my “home brew” path;

its date precedes the install date by quite a bit, so I can see it had not been over-written by a more recent installation.

I could remove my “home brew” en-AU folder, and re-run the installer, but as the installer rewrites the en-US folder removing the updates I put there, I would not expect the installer to create a new en-AU folder.