Formatting fine under MS Office 365 but not TM 2024

[RJSawyer]

I'm using TextMaker NX Universal - Beta (rev S1110.0427) 32bit.

The attached file looks just fine under Microsoft Office 365, but, as you can see on page 4, the caption "British edition" and on page 6, the caption "Chinese edition" appear far to the left of where they should be (indeed, off the physical page), in TextMaker.

All best wishes.

[Devonboy78]

Definitely a bug in TM2024, the titles 'British Edition' on page 4 and 'Chinese Edition' page 6 display correctly on the picture of the book cover in both Libre Office and Only Office which are both freeware!
Also if you move the titles back out of the margin and into the document area and save the document, when you re-open the document, the corresponding cover picture has disappeared

[Devonboy78]

I have experimented further and if you move either caption, the display is fine BUT if you save the file and re-open it the images of the book covers have disappeared though their place holders are still there. I then tried moving a book cover image slightly to the right, saved the file but when the modified version was opened, all the book cover images were blank.
I tried changing the caption text frame properties so that the anchor was switched from 'When object is moved Move Anchor to nearest paragraph to Keep Anchor at current paragraph' , again the same result, the images of the book covers disappears when the saved file is opened.
I also tried saving a modification with the option 'Do you want to save all necessary compatibility issues to make this document compatible with the latest version of Word?' set to No. Again the images of the book covers all disappeared though place holders still visible.

[RJSawyer]

Thank you, Devonboy78! I hope SoftMaker will fix this!

All best wishes!

[miguel-c]

I was able to reproduce the issue and reported it to the developers. Thanks

[raitis.veksejs]

I got a reply from our developers' team:

"The position of both text boxes says 3,56 cm left of the column, and the question is now where the column starts. As the document is a single column, TM assumes the left page margin. Word thinks it's the position where the text starts after it has moved because the image blocks the regular place.

Basically, there are two methods to solve the problem:

#1: Set the position to 'relative to indent', as seen in the screenshot (restore the old offset value)

#2: Don't rely on the Word method of placing two objects independently, but 'group' them so that you have only one object.

(#2 is the better method)" See the screenshot for reference.

[RJSawyer]

With all due respect for that admirable workaround, the actual solution is for SoftMaker to fix their code. They advertise full compatibility with Microsoft Office, and I've provided an example of where they are failing to live up to that. The file displays and prints flawlessly in other Office alternatives; it is only in TextMaker that it isn't working properly.

[miguel-c]

My colleague Raitis forgot to tell you that we fixed the issue and the fix will be included in the next beta update.

[Woody44]

I got a reply from our developers' team:

"The position of both text boxes says 3,56 cm left of the column, and the question is now where the column starts. As the document is a single column, TM assumes the left page margin. Word thinks it's the position where the text starts after it has moved because the image blocks the regular place.

Basically, there are two methods to solve the problem:

#1: Set the position to 'relative to indent', as seen in the screenshot (restore the old offset value)

#2: Don't rely on the Word method of placing two objects independently, but 'group' them so that you have only one object.

(#2 is the better method)" See the screenshot for reference.

I'm sorry, but the most-used word processing software in the world, by an overwhelmingly HUGE margin, is Microsoft Word. Everyone else promotes their word processor by claiming how compatible it is with Word. To be informed of an obvious incompatibility and to then suggest going through a somewhat laborious procedure to correct what is fundamentally a program flaw by editing the document is not acceptable.

What happens if he makes the changes to the document that you suggest, and then sends it back to a colleague who is using Word? Are the captions then going to display incorrectly in Word? If so, that's not a solution. Even if they display correctly, if the colleague notices the change and restores it to the way he, as the author, thinks it "should" be -- what then?

SoftMaker cannot assume that purchasers of SoftMaker Office will always be working only on documents they create on their own computers, and that are never shared with anyone else. You also cannot assume that an entire office or an entire corporation will switch to SoftMaker Office and never have any interaction with documents generated by Word, or documents that will be sent to colleagues, clients, or customers who use Word. I am an independent consultant. ALL my clients use Microsoft Word, and that means that my software MUST provide flawless compatibility with Word. TextMaker 2021 is better in most respects than LibreOffice Writer for compatibility, but unfortunately it is still not close enough that I can remove Word from my computer.

This bug is another example of why that is true.

Look at the TextMaker page on the SoftMaker web site. What does it say?

"This is what seamless document exchange looks like."

(emphasis added)

Does the behavior reported above honestly meet any conceivable definition of "seamless"?

[Woody44]

My colleague Raitis forgot to tell you that we fixed the issue and the fix will be included in the next beta update.

Thank you.

Do you know when the next update will be?

[miguel-c]

No specific dates yet, but you know betas... they don't last long, so don't worry.

[RJSawyer]

This bug is still not fixed in today's new beta release:

TextMaker NX Universal - Beta (rev S1111.0529) 32bit

[miguel-c]

You are right. It's only partially fixed. There were some problems with the solution implemented, so the developers had to take a step back.
Sorry for the inconvenience.