[Libreoffice-bugs] [Bug 138694] FORMATTING: Docx file looks good on screen and prints but fails to reload

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=138694

--- Comment #24 from roland at logikalsolutions.com ---
The problem is 

1.) that DOCX is broke. Period. The UI provides the illusion that DOCX and DOC
actually work. 
2.) Development claims to need the original ODT so they can test and debug. Not
an unbelievable claim, but the current UI flow won't provide the necessary
input file so the product cannot improve and user won't find out until they try
to load the file for editing again.
3.) As long as the product relies on "expert friendly" users, it will never
improve.

Gimp and most other packages have simply stopped providing "Save-As" options.
They will only directly save in their internally supported file format. Even
after you export to some format, if you haven't saved the internal format, the
buffer is flagged as unsaved and you are prompted to save on exit.

Architecturally the "solutions" to such problems are rather straight forward.

1.) Take the Emacs, and now Diamond, approach of a special "backup directory."
User can set the location and backup depth. Each time the user saves an ODT
version of the file with a mangled name is saved in the backup directory, even
if they save an ODT file. The Emacs mangled names look like this:

'!home!roland!sf_projects!redbug!src!syntaxhighlighter.h.~4~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighter.h.~5~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighter.h.~6~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighterrust.cpp.~1~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighterrust.cpp.~2~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighterrust.h.~1~'
'!home!roland!sf_projects!redbug!src!syntaxhighlighterrust.h.~2~'

full path stored in file name with directory slashes replaced by !. Final
suffix is a backup version number. For Diamond it appears they look like this

''\''!home!roland!sf_projects!redbug!src!util.cpp.b00004'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00005'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00006'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00007'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00008'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00009'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00010'\'''
''\''!home!roland!sf_projects!redbug!src!util.cpp.b00011'\'''

because I must have a bit of a formatting bug. The only real difference is the
version suffix is .b000nn 

The special backup directory approach has the added benefit of providing
backup/versioning to the product.

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/01/diamond-backups.png

This ensures you can always get "original input" for the conversion. Since the
backup will be made on each save the default version limit should be 100-120.
Yes, you have to purge the old ones off and you need a "reset" function for
when the version number exceeds 99999. If one is writing a novel they can
easily save that many times over the course of 1-5 years working on it.

2) Take the Gimp approach. Remove Save-As entirely. Move all non-native formats
to an Export menu. Only count the current file as saved if it has been saved in
native format. Make it annoying/difficult to exit without saving in native
format.

3) Round-a-bout. Leave Save-As in place, ___but___ popup a tiny notice that you
will attempt to reload the document into another buffer/instance so the user
can verify there are no problems before they lose the sacred internal format.

*) The "traditional" OpenSource approach: Leave the bugs rot in the database
until they can be closed as being reported against an unsupported version.

Solutions 1 & 2 make a lot of sense for use in the field. They aren't even
mutually exclusive. You could implement both.

I would have thought solution 3 would already be somewhere in the product, even
if it is hidden, because as a developer, that is how I would want to test. An
automated round trip.

The traditional approach is sooooo annoying.

Until one solves the problem of not having the source ODT, the traditional
approach will most likely be the one taken for all of the existing DOC/DOCX
bugs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210112/360a5f9c/attachment.htm>