SoftMaker.com

Is TextMaker going to get support for writing documents in Strict OpenXML form (as MS Office 2013 has now)? I had been hoping MS would implement this in their suite since MS 2007, but it has taken until now to finally be implemented.

As you will know, the challenge has been for other office suites (such as SoftMaker's) to develop and maintain compatibility with the Transitional OpenXML format as used in MSO 2007 and 2010. As the article linked to below explains:



Now with MSO 2013 supporting writing in Strict OpenXML, there is the opportunity for strong compatibility with other suites, so that documents can be exchanged very aptly and securely. So it is my hope that SoftMaker will also implement full Strict OpenXML support.


Strict OpenXML article: http://www.theregister.co.uk/2012/08/15/office_2013_strict_open_xml/

_________________
SoftMaker Office Pro 2012 Rev. 679 User

See my post, Is TextMaker XML-Friendly, from February 2, 2012...
http://www.softmaker.com/forum/viewtopic.php?f=185&t=9992

Support for Strict OpenXML is on the agenda for future versions but not implemented yet.

_________________
Sven Leßmann
SoftMaker Software GmbH

Future versions meaning SMOffice 2013/2014? Or service pack update of 2012?

tgindy's points are solid, and it would serve SoftMaker greatly to become a forerunner in handling all these formats. I'm glad with what we currently have in SMO2012 as far as compatibility with the major formats, but even though the filters in place are good (and better than most other office suites) SM could be much more progressive.

Personally I find it far less important to have an Android SM suite than to have wider format support. Android is a fad thing right now, yes, but not even 10% of Android apps are optimized for tablet form, and even then the current tablets are not efficient to be used for serious office application. So I would think progressive format support is much more important than providing entire suites to something as impractical as Android platform as it is now. Even on Google Nexus 10, what good is SMO right now? Yet on serious OS the suite is really kind of limited where it comes to formats. Just something to think about you know

Strict Open XML support is one, epub editing is another, etc. Foxit Editor now has support for exporting to ePub, to give an example. Perhaps SM could produce an updated version of the .tmd format as well, like .tmdx or something that would use Strict Open XML as basis. It would make for smaller documents too.

If it were up to me (and I know I'm not considering market share, economic strategies, etc.) widening format support would be the NUMBER ONE field of development for SMO. But I know it's not up to me But if you want to widen user base, think how seductive it would be if SMO could basically handle any format easily. On top of that the suite is portable. Right now I will use Calibre to convert some documents to mobi and epub so I can read it on my Android tablet. Calibre is free and it can do all that. Don't become like the big and slow Microsoft Office giant that took 7 years to wake up to Strict Open XML support, a format they themselves developed!

_________________
SoftMaker Office Pro 2012 Rev. 679 User

Chacun à son goût, as the French would say. While the Android version may not be important to you, it is our number-one selling application at the moment. And, yes, it is even tablet-optimized (it detects the screen size on startup and then behaves differently on tablets than on smartphones).

The first step for us to change SoftMaker Office so that Strict OpenXML documents can be opened and rendered correctly. Right now, they open but all the sizes and dimensions are wrong, as Microsoft has changed the units of measurements from 1/20 of an inch to typographical points. These change will probably part of a future service pack.

After that, the question is what the user gains from Strict OpenXML support. In Microsoft Office 2013 it is just one file format of many and not the default format. Microsoft integrated it so that they could finally claim standards conformance. In the words of a Microsoft blogger (paraphrased): If you value correct and repeatable rendering of your documents, use Transitional OpenXML. If not, then Strict OpenXML will work for you, too. This is not encouraging.

My question is: What would SoftMaker Office gain from being able to write Strict OpenXML files? Just a checkmark item on a feature list, or is there a tangible benefit?

ePUB support is a completely different game. We are already working on an ePUB export filter for a future version.

_________________
Martin Kotulla
SoftMaker Software GmbH

I welcome the Android version, but not more so than widening format support of SMO on platforms that are actually practical Maybe I was just a bit hurt when I saw my gradients used for the SM icons on the android version page and no on passed me a copy out of courtesy But seriously, my point was not as much about sales numbers (although I can understand that) but more about what is a serious platform to perform work on, which Android is not at all (yet). But then you might say it may soon become, and then I might have to grudgingly agree with you to an extent Don't get me wrong though, I own an Android tablet as well but it is about as practical to do any work with as it is to use Windows 8 if you are a desktop power user


Well that is encouraging to hear then. But does that only apply to open/read or would it allow saving as well?


Isn't the comment about 'correct and repeatable rendering' a bit of misnomer, in that what it is referring to is really using the document in different suites, and suites which are known not to offer support for saving in Strict OpenXML? Or are you (or the blogger) trying to say that the saving of Strict OpenXML documents in Office 2013 is not consistent in Office 2013 itself? I don't think so. Personally, I would not be looking into rendering Strict OpenXML documents in Office 2010 or 2007, I would open (and save, obviously) them with the suite that supports writing Strict OpenXML. My wish was just that SMO 2012 would gain support for this as well. For purposes of interchangeability and backward compatibility, yes, it is important to retain the legacy compatibility, but Office 2013 offers this as well. So we are not talking about SMO dropping support, but rather gaining support for a format. So unless you are saying that you have foreseen that Strict OpenXML documents will not have a future then I don't quite understand what your stance is.

I applaud SoftMaker's filters for working with .doc and .docx documents, as I have said many times before, but if we are talking about reliable interchangeability of documents between SMO and MSO suites, then that blogger you mention above could not say anything more positive about that than he could about Strict vs Transitional OpenXML, because none of it is perfect and reliable when going between suites. As you well know there is only one way to ensure a document/format is opened as one had saved it, and that is to open it with the suite you have saved it with. Going between MSO suites rendering is FAR from reliable. So I think the comment about correct and reliable rendering was taken out of context to prove a point toward 'general' (read: indiscriminate) use. So his point in my view is nothing more than emotive (or at least seems to be conceived of that way) and as such it shouldn't be influencing what SoftMaker is doing regarding Strict OpenXML. If rendering is not reliable between the various MSO suites with regard to, for example, .doc and .docx, then isn't it a mute point to say that Strict OpenXML as saved by MSO 2013 is not reliably rendered when opened by SMO 2007? All that blogger was then saying is that Strict OpenXML format is NO EXCEPTION to issues with reliable rendering, which, yes, is a mute point.

So please excuse my French when I say that my 'goût' clearly goes toward implementation of Strict OpenXML

_________________
SoftMaker Office Pro 2012 Rev. 679 User

By the way, I opened some .docx's saved in MSO 2013 non-compatibility mode and opened them in SMO2012 TextMaker and they were displayed rather nicely. Now just to add that write support

_________________
SoftMaker Office Pro 2012 Rev. 679 User

One more thing about Strict Open XML:

Didn't Microsoft spearhead Strict Open XML TOWARD interoperability with other office suites (reliably)? So would this then not be THE format that would be most useful to SoftMaker Office -- and especially in the long run? I understand that testing would need to be done, but not only would the addition of Strict Open XML 'save' be only a matter of time for SMO (surely), would it also not give the benefit of better interoperability when saving between MSO2013 and SMO?

According to the articles I've read, when other office suites don't have to support legacy features (and thus recreate backward compatibility -- hence SMO's well-developed filters) and can also write Strict Open XML the documents thus created would be much more reliably rendered. So unless this has been disproved solidly it would be my assumption this feature would be on the top of the to-do list.

The only reason I ask these questions as a customer is that I would like to be able to avoid using MSO 2013 and use SMO instead. So I am curious to know what SoftMaker's stance on this will be. Thank you.

_________________
SoftMaker Office Pro 2012 Rev. 679 User

At this point, we are just adding read support for Strict Open XML. It should be part of either the next service pack or the one after that. Reading Strict Open XML doesn't look too difficult, they just changed a few XML tags (for no apparent reason). Writing is another issue. We have not explored this at all yet, but it is probably a more severe change, because "strict" implies that one might be allowed to write much fewer XML tags than before. So, I don't think this will still be part of SoftMaker Office 2012.

I am not sure what you are reading into Strict Open XML. Basically, this is just revenge on Microsoft from the standards committee. "So you released an office suite based on a standard that wasn't approved yet, AND even then you failed to implement it correctly. Here, we just throw in some changes to make you pay for it". At least that's my reading, because I could not find any other reason for changing the XML tags for left/right indent from "left" and "right" to "start" and "end"...

If you look at the market, there are two office suites that read and write Office Open XML really well: Microsoft Office (duh!) and SoftMaker Office. The rest? LibreOffice and OpenOffice don't even implement the current formats DOCX/XLSX/PPTX in any usable way. Do you expect them to jump on the Strict bandwagon when they even haven't done their homework in the last five years?

And when you have a Transitional Open XML file and your office suite chooses to ignore the legacy features (yes, we ignore some, too), you get pretty much the same result as from a Strict Open XML file. So, where's the gain?

By the way, have you had a chance to look at Microsoft Word 2013? If one assumes that file formats are listed in order of importance, you will see how much of that Microsoft places upon Strict Open XML - see the attached screenshot...

Incidentally, we did not use your vector icons. When our designers created the icons years ago, they already did so in vector format. For Android, we just regenerated higher-resolution bitmaps from them. If we had used your icons, we would have asked for approval.

_________________
Martin Kotulla
SoftMaker Software GmbH

From the few tests I've done saving in Strict Open XML SMO rendered them quite well already, although the test docs were quite simple.


I guess much of what we are touching on here is a result of history rather than choice (and MSO market penetration, of course), in that if MSO 2007 had come out with Strict Open XML write support, SMO 2010 would have already had support for it. Now that the gains are considered minimal to implement it now (since Trans Open XML support has been reverse engineered so well by SM), the reluctance is understandable to a degree. But then it does seem somewhat that the decision not to support Strict Open XML write is rather circumstantial, rather than principled. For one might very effectively argue that Microsoft was trailing when it did NOT implement Strict Open XML write support for the last 7 years and that this was regrettable. But then since it is regrettable, now we don't support it even though we say it was regrettable. So it seems somewhat of a circular reasoning. But, I do understand it takes resources and man power to implement something of this magnitude now.

One thing I do really wonder about, and I think a fruitful endeavor on SoftMaker's part to research this, is how reliable (or how much more reliable, if at all) it is to interchange documents saved in Strict Open XML as saved by MSO 2013 and by (a developer's test of) SMO supporting Strict saves. (Especially since MSO 2013 now seems to save in Strict mode by default (the selection box for compatibility mode was NOT marked by default when I first saved a document in Word 2013). So it would seem MS is making Strict the default save mode which will no doubt promote it to an extent.)


Of course not, I rely on progressive and practical suites like SoftMaker Office to do that for me


My interest was going toward the possibility of more reliable interchanging of documents between suites; in other words, to take the "pretty much the same" element out of it and produce exact and identical results when saved by MSO vs SMO. This is what I'm interested to learn concerning implementation of Strict Open XML saves and thought if any suite would have the interest and progressiveness, it would be SMO. Hence I come to you

Since from what you are saying there are no hard facts to either debunk or prove enhanced reliability and interchangeability between suites (as Strict save is not implemented in SMO), then this is exactly what my query is focused on. If something is not known, then the only way to find out would be to test it. I'd really be interested to know the results of that. But, in the end, you are the experts and have better oversight of all things involved.


It appears, upon closer inspection, that you are correct. Sorry I had taken great effort to get a bit more defined gradient in those icons -- but when I went back and checked mine I did notice mine were more pronounced. Can't seem to do anything right for SoftMaker, not even promoting MSO's new default save format

_________________
SoftMaker Office Pro 2012 Rev. 679 User

But there wouldn't have been a point in supporting Strict Open XML in the last seven years because a) there wouldn't have been any other office which supported it, b) Microsoft would have found a way to re-interpret the specs so as to make our Strict Open XML with their Strict Open XML (look up what they did with function name support in Excel in relation to OpenDocument, and c) the standard changed significantly between rev1, rev2, and rev3.


Now this is news to me. Our copy of Word 2013 defaults to Transitional Open XML, and it never asked us which default file format we preferred. Are you sure about this?


Good. We are on thie same train with this one...


Here our opinions differ. I don't think that even higher compatibility is going to happen through Strict Open XML but through continuing to enhance our current filters and adding more MS features in the applications in general.


Well, we are still investigating all this. This is not made any easier by the fact that there seems to be no Strict vs. Transitional comparison page anywhere to be found. Thumbing through 6000 pages of densely packed information twice (Transitional vs. Strict) to find the differences is not a fun job.


No, this is useful information and reminded us about doing something in regard to Strict Open XML. And you already got us to start updating at least the import filters for Strict Open XML.

_________________
Martin Kotulla
SoftMaker Software GmbH

Points taken. I am glad to see you are on it.


Yes, quite sure. In fact, at first I was trying to find any setting or option to make Strict Open XML saves with, only to find that compatibility mode setting ensures this, which was, as I recall quite succinctly, on by default in Word (compatibility with older suites was not enabled/marked in the 'save as' window). I'm about to reinstall Windows and while doing so will install Office 2013 again and make sure this is the case and report back.





OK, well I am curious to see if there are any gains on the compatibility front then, especially since Microsoft's language in describing Strict Open XML would seem to imply it is geared toward better compatibility with other suites adopting it. But yes, current (and I'm sure future) compatibility on SMO's part is very good already.


I'm completely with you there. I found it extremely hard to find any substantial information about Strict Open XML, its features and implementation. The information is extremely scarce, which is baffling given the nature of Microsoft's claims about the format


Well, you are gracious

_________________
SoftMaker Office Pro 2012 Rev. 679 User