I spent part of yesterday and today redoing my resume to make it look really nice. Has to be in Docx format for most sites. Printed out copy before saving because I wanted to verify it looked nice printed as well. Went to open file today to fix minor date alignment problem and page 2 is trashed. It has created a bunch of dynamic "Converted" page types. See images. I even went through the pain of direct installing 7.0.x from the official Web site.
Created attachment 167870 [details] Page 1 printed scan of printed page one before save and reload
Created attachment 167871 [details] Page 2 printed scan of printed page two
Created attachment 167872 [details] Last printed page scanned Not that it should matter here, but final page has table in footer to provide color decoration marking end of document.
Created attachment 167873 [details] Actual resume file in docx format Here is the actual file. Please don't create and post fake resumes about me
Created attachment 167874 [details] What page two looks like in re-opened document What Page two looks like when I re-open the document.
Created attachment 167875 [details] machine and os info machine and OS information
The resume in DOCX looks like attachment 167874 [details] General advise: never ever save straight forward into DOCX. As this kind of thing surely not unique. It shows up fine even after, save & reload will reveal if actually something got broken.. Anyhow, it be nice if you have a ODT of the proper layout.. which can be exported to DOCX causing the broken variant.
That wasn't the creation path. This document needs to be DOCX. Ultimately I had to "fix" this by starting from scratch with Word 2016 on a Windows laptop. There was no way shape or form to salvage what LO had created. I do have a DOCX of the file from "earlier in the day" that was only slightly butchered. You will see the lines that were drawn under headings in the frames on the left of the first two pages are randomly drawn. Changing of area color along with font color in the frames seems to have really trashed the world. The second thing that seems to have trashed the world was a one-time page header and one time page footer. I even created unique page styles based on the default page style. One was to have the color header and the other the color footer. Basically following the advice from here to achieve a complete document, not just one page, bounded by begin and end color bars. https://ask.libreoffice.org/en/question/280733/how-to-make-header-and-footer-of-a-page-be-color-bars/ No matter what LO insisted on replicating the header and footer on every page even though they were completely different page styles and that the checkboxes for replication and all that were turned off. The 2001 (typo in the name) document is where things were kinda-sorta-fixable and the last little tweak sent the gopher down the mountain.
Created attachment 167895 [details] Only slightly broken before tweaks that completely trashed The only slightly broken version before the tweaks that completely trashed things.
I can't think of anything that we could do about this bug report. 1.) When discussing export issues, an ODT is required. 2.) Bug reports need to focus on one thing. A large, complex document that has several problems likely is a duplicate report in many ways. So a minimal ODT containing one item that doesn't round-trip properly is required. If that is done and no existing duplicate report is found, it is best to create it as a new bug report anyway instead of adding onto this one. So I'll close this one, since we already have tons of bug reports about textboxes and page styles. P.S. DOCX format doesn't have any concept of page styles, so the stylename is irrelevant and can't be round-tripped.
(In reply to Justin L from comment #10) > I can't think of anything that we could do about this bug report. > 1.) When discussing export issues, an ODT is required. > 2.) Bug reports need to focus on one thing. A large, complex document that > has several problems likely is a duplicate report in many ways. > > So a minimal ODT containing one item that doesn't round-trip properly is > required. If that is done and no existing duplicate report is found, it is > best to create it as a new bug report anyway instead of adding onto this > one. So I'll close this one, since we already have tons of bug reports about > textboxes and page styles. > > P.S. DOCX format doesn't have any concept of page styles, so the stylename > is irrelevant and can't be round-tripped. Well DOCX certainly must have something because I've laid out books using MS Word on Windows 10 because that is what someone "had" to have. Running left and right page headers that were different based on chapter and left/right page position. If LO really is so crippled that __nothing__ can be trouble shot without first creating an ODT, they the product needs to do the offensive thing Gimp has done for the same reason. It most only save in ODT format. Everything else has to be File->Export. Right now LO has a File->Save-As that lets one choose the format. If it can't do it right, then it shouldn't do it. Should only allow Save in ODT and only export to other formats __after__ saving an ODT. You see, this wasn't an export issue. This was File-Save-as issue. What you are telling me is File-Save-as simply doesn't work. It stores something corrupted without informing the user on the screen. Traditionally that is not how Save-as works in any other package. It is how Export works in many different packages. File->Save-as indicates to the user the format is accurately supported internally and what they are actually seeing. File->Export gives no such indication because it does not change the visible file name nor the file actually being edited. You can reduce your bug reports and obtain valid data by fixing the usage flow.
(In reply to roland from comment #11) > Right now LO has a File->Save-As that lets one choose the format. If it > can't do it right, then it shouldn't do it. Should only allow Save in ODT > and only export to other formats __after__ saving an ODT. The DOC/DOCX save quality is somewhere in the middle ground. Pretty OK for simple documents.. but changes with complex documents under circumstances.. Also there is the function mismatch. So LibreOffice ODT support things which DOCX can't do. So these get converted/transported in to something which matches DOCX specifications. Export instead as direct save would be by far more realistic, IMHO. It's not only about 'fully supporting' DOCX format (not the case). But also LibreOffice not having the same function set. So it will never 'fit'/match exactly the DOCX specifications. However there number of different views about that.. So say DOCX export being good enough.. and there is a warning dialog at save (which can be dismissed).. Also there is proposed a way make clear what the incompatibility's are. But pretty complex and likely even an pretty long list. In my world.. DOCX will be imported (silently converted to ODT) and saved as ODT. Only File -> Export to DOCX/ODT/RTF. (Like Apple Pages). And there is a group who like to 'read the manual' approach. You got a tool, which behaves a certain. You have to learn to use it. Even if the tool putting things straight into your face which you shouldn't do at all. Personally bit more of nudging/teaching application. So me +1 'Export' instead of direct save. But this might be less comfortable for some.. and people not familiar with the concept can't find DOCX anymore. Or people disliking not being able to directly save into DOCX (more cumbersome) Or Export being seen as lack of trustworthiness in DOCX/DOC. Kind of 'degradation'. Current approach is to keep people in the illusion the can safely save into DOCX/DOC (without any compromise). And kind of scoffing at those who do and start complaining about something being broken. People should make backups.. people shouldn't save directly into DOCX etc.. Solutions would be.. sidecar (with double save. ODT/DOCX). Or Export. But of course matter of file management comes into play. Multiple documents on you're system (DOCX/ODT).. Which one is the one (especially if DOCX is shared with Word users.. and send back etc). So at minimum a setting must be in place to restore the 'current' behavior. However this should be deliberate choice less advised (to be used at own risk)
(In reply to Telesto from comment #12) > (In reply to roland from comment #11) > > Right now LO has a File->Save-As that lets one choose the format. If it > > can't do it right, then it shouldn't do it. Should only allow Save in ODT > > and only export to other formats __after__ saving an ODT. > > Or people disliking not being able to > directly save into DOCX (more cumbersome) Or Export being seen as lack of > trustworthiness in DOCX/DOC. Kind of 'degradation'. Or just owning up to the fact it no-worky. The biggest problem is the unseen corruption. The file doesn't go out and then come back in in a different tab so one could see just how jacked up things were. For small files this would be okay. For 800+ page books like some of mine that might be an issue for a few machines. Certainly not the ones I write on. The smallest one has 8Gig with most having 16-24Gig of RAM. Perhaps the out and back in would the the "middle ground?" One could at least "see" how jacked up things got while there was still an internal ODT version that could be saved as ODT. Not really a "solution" but better than the nothing you have after being lead down the primrose path of Save-As without any indication of a problem, then exiting. The out and back might also be a useful tool for developers as they can try various things and see right away when something gets jacked up.
A DOCX preview certainly a nice function. Currently you have to Save an ODT as DOCX followed by File-Reload. The badness only shows up after reload.. so you can save 20x to DOCX while editing.. without knowing the result being screwed. As long you're editing mode - and LibO doesn't crash - you're still able to save ODT properly A preview would make it possible to see how LibreOffice would render to DOCX. Not warranty what will happen on MSO side. Import and export code are separate things. Export wrong resulting in import wrong.. Or Import good at LibO but broken at MSO. Or Export is OK (LibO/MSO), but only import at LibreOffice wrong.
@UX Please see comment 13 - the preview DOCX save/export might be something to consider. Maybe even useful for automatic testing
(In reply to Telesto from comment #15) > @UX > Please see comment 13 - the preview DOCX save/export might be something to > consider. Maybe even useful for automatic testing No, I'm not volunteering to code it, but speaking as someone who has done a lot of development over the past three decades, I would think the out-and-back for non-odt format would be the easiest thing. You would just be gluing together things already in place. Yes, you could have a difficult time telling whether out or in was what went off the rails, but at least one would have a heads up about the potential problem.
(In reply to roland from comment #16) > No, I'm not volunteering to code it, but speaking as someone who has done a > lot of development over .. Looks like you're arguing in advance :P. Sounds like you're kind of expecting - not totally unsurprisingly (for me) - a certain kind of feedback..
(In reply to Telesto from comment #15) > ... the preview DOCX save/export might be something to consider. No, we aim for pixel-perfect cross-application and -plattform compatibility. Numerous of tests are run every build to ensure this. At least for the previously known issues.
Well, I hate to break it to you, but your aim isn't even close to hitting the target. Don't even get me started on the picture support. If the __only__ way your developers can debug anything is starting with an ODT then the architecture of OO is completely wrong. It needs to follow the architecture of Gimp. Only support a single native file format and make the user export to others so the user knows it is a crap shoot. Look back through this thread. I "trusted" what you said to be true. That's what your current architecture implies. The output wasn't even within hand grenade distance of being correct. When I provided the .docx I was asked for the original ODT. There was no original ODT. The architecture of the application did not force that and there was not massive warning dialog saying I need to also save in ODT if I want to have any hope of someone fixing the inevitable issues. I ended up having to boot a laptop with Windows 10 on it and use MS Word to create a new resume because OO simply couldn't do it.
(In reply to roland from comment #19) The architecture of the > application did not force that and there was not massive warning dialog > saying I need to also save in ODT if I want to have any hope of someone > fixing the inevitable issues. This multi-dimensional topic. If the original file being pure MSO, this obvious valid case.. If DOCX generated by LibreOffice, well result can come from Export code (not properly written), or import code (not properly handled) In case of MSO file it is also possible not being imported properly and not exported at all.. ODT is obviously easier to argue how it should look. And makes far easier where it did go wrong. The broken file shows only something did go wrong, but gives no clue where to look. - Different matter is obviously how reliable DOCX export (and import) is. I personally - in current state - don't trust it. But well i'm biased.. As I'm seeing bug reports floating by.. and while doing some ODT/DOCX conversion tests aside (take a random bug doc, export it to DOCX) Even if it looks 'good' on screen (import/export) it still not 100% it will act properly. Currently tracking Caption frame & image detaching.. Specific to DOCX files (FWIW: regression did work a long time ago] And if you saved it into DOCX, you can't get the old - proper - behavior back.. So the DOC/DOCX import export and support always kind of tricky, IMHO. Target is of course 95% capability. And there is progress, but enough to go wrong somewhere.. If becoming more exotic
(In reply to Telesto from comment #20) > (In reply to roland from comment #19) > The architecture of the > > application did not force that and there was not massive warning dialog > > saying I need to also save in ODT if I want to have any hope of someone > > fixing the inevitable issues. > > This multi-dimensional topic. If the original file being pure MSO, this > obvious valid case.. > It's not a multi-dimensional problem, it is architectural. If internally LO can only handle ODT, then it needs to save ODT and have all else be an export just like Gimp. The Gimp project went down this same path years ago. They couldn't get other formats quite right. (95% is still not quite right). The solution was an architectural change. It would only save and load whatever special format it used. Everything else was an export/import. By moving the other file types to an Export menu instead of Save-as, they removed the implicit believe that "things just worked." They also increased the likelihood the original file needed for debugging still existed. Product got better.
(In reply to roland from comment #21) > By moving the other file types to an Export menu instead of Save-as, they > removed the implicit believe that "things just worked." They also increased > the likelihood the original file needed for debugging still existed. Product > got better. I'm on your side.. but well.. convincing the people who can actual make this decisions will be extremely hard.. And I'm rather an expert in rejected proposals :P A group will see it as respecting their hard work on docx/doc import/export. A group will scream it reflecting bad on LibreOffice (and competition matters). Not capable to handle DOCX.. [prefer to pretend A group disliking changes in principle.. A group find it convoluting workflow an file management (extra duplicates.. the or simply take the risk; and ignore the save to ODT warning] A group will say well this can happen, but group affected is limited A group will say LibreOffice isn't MSO so DOCX/DOC flaws being inherent. And people should simply know A group will tell you, we are doing it this way since ages - 10 years. So must be that good A group will point to all documentation which needs to be updated A group will point bad for marketing A group will say well, we enough work already.. no time for this.. A group will point to the 'one time' dialog with a warning [must be enough right] A group will complain about export being annoying.. A group will point to broken macro's or whatever.. point to Save As A group will manage to start a topic on all fill formats.. (say RTF or TXT). And because we probably can't get to agreement on one of those, throw out the whole idea Obvious invented a few of those above.. and not sure how big those groups are.. but well I brought this up somewhere in bug tracker or e-mail list, but got not much response.. I'm a kind of idea's how to make it more compelling. Certain objections surely hold some merit. And it's not that there are many complains in the bug tracker.. But how representative that is.. Based on my experience I wouldn't export directly into DOCX without ODT copy. Because I'm never sure what I would get.. Which only reveals itself after file-reload
@Another addition.. only for 'informing'. Not affiliated; no representative. Only airing my contemporary view * A group will see it as losing face.. [which is true, but current face is based pretentions. Pretending DOCX being good, something which is desired but not (totally true). And pushing is based on arrogance.. * A group sees LibreOffice as tool, not having an educative/teaching function. So UI may be aesthetically horror. Un-intuitive etc. Which reads as build by developer for developer. Developers 'get' that optimizing something for 'end-user' time consuming business which doesn't add anything technically. The tool is in still the same, but only presentation (and use cases). And user friendliness means limitations of the full potential. And up-set users who are limited by some user-friendly front-end. While there technically no restriction present. Always thinking about command-line tools. The playing ground of developers. However there a switches present you shouldn't use or not in certain combinations. However the command-line won't tell you. So cut switch in place which don't work or don't have the desired result.. Or are broken for whatever reason. But well developers are used to that and like the flexibility of nicely tool limited in scope. As the want to use (abuse) the tool in the way the desire and full power. * A group will complain about the user confusion it will cause in short term. I could always save to DOCX/DOC -- Putting DOCX/DOC under export is kind of teaching.. Even the current 'warning dialog'. But that's was likely some compromise. Also note that there are 'export' and 'export. Export in Writer means 'exotic formats' (PNG) and/or files which can't be edited anymore (png/epub) Export what we are talking about is, moving it out of 'Save as' and 'Save'. Which present in macOS Pages and Gimp. -- A compromise would be 'default' export. With some switch to restore the old behavior. There is also the topic of 'splitting' the save as list into say sections. Which could have heading compatibility save.. but well doesn't cover direct Save
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.
Created attachment 168837 [details] How Diamond backups look This is how backups look in my current fork of Diamond. They are hung off the View menu. If you really want to dig into them the repo is here. https://github.com/RolandHughes/diamond There is even RTF formatted dev_doc with step by step instructions for creating build environments.
@Cor Any opinion on the matter (Comment 0/ Comment 11/ Comment 19/ comment 24) I'm agreeing with Roland, but I assume this having a history .. And there are multiple views/opinions on this. The meritocratic approach would effectively result no change because there is no harmonic (common) opinion. So keep the current status quo. Obviously there multiple questions. * Is it problem problem saving to DOCX ruining files? * If so what to do about it. Also needs to kept in consideration that full compatibility won't be reached.. * MSO keeps changing format * MSO internals of LibreOffice and MSO not the same (functionality or behavior). Say to character anchoring as default (LibO). versus to character anchoring. Page breaks being different Highlighting color madness Textbox/frames So always be emulating.. mimicking.. converting.. This is done 10 years back, and will be the case 10 years in the future.. I could also turn this in a promoting the ODT usage narrative :P. Even after acknowledging this being an issue, the question would be how the handle it. Tend a bit to 'export to DOCX/DOC' instead to direct save (gimp/ macOS Pages model), but contemporary view.. not putting my bets on a single solution :P But would like to now your view.. if there should be changed something surely topic of at minimum ESC. But I assume the eco-system partners holding a view on this too :P. I even could consider a distinction between TDF LibreOffice and eco-partners. LibreOffice disallowing direct save.. TDF as promoter of open source. Where as eco-partners allowing this because of commercial interest.. say based on the 'Enterprise/Community build switch'. But I'm likely playing with oil and fire even proposing or considering this. As this being the topic feared the most by community members.. and allowing this of obviously opening doors for more deviations.. [less features, crippled features etc]
This bug IsNoGood from the start, as it usually happens when a user starts with I and writes a user story ("I had to write a resume..") instead of reporting a single issue, after having searched existing bugs and possibly tested with master version. IIUC problem is opening of page 2, in addition that user didn't first save as ODT so it's LO created DOCX (which luckily looks OK in MSO). I confirm page 2 issue in LO 7.0.latest but not in 7.1.latest so WFM. 7.1 Linux: bebf0021d4310c84089defc109b9990b7fc4502f is the first good commit Date: Fri May 28 11:44:27 2021 +0200 source 8d7b4998c7443be91a09f46a3cb5e6fad9b035bd prev 2a0d5643234cd0989f91589695694c809d82e344 author Miklos Vajna <vmiklos@collabora.com> 2021-05-26 committer Xisco Fauli <xiscofauli@libreoffice.org> 2021-05-28 tdf#139915 DOCX import: fix anchored obj position with to-char and TEXT_LINE I'll mark a duplicate. *** This bug has been marked as a duplicate of bug 139915 ***
This bug was good from the start. It is ___NOT___ a Duplicate of 139915. I have over 30 years in software development and write an award winning technical book series. People do not create "User Stories" because AGILE is a criminally fraudulent software development methodology so far from Software Engineering it cannot even mail a letter to Software Engineering. When filing a bug report the steps that created the issue have to be provided in a reproducible manner. They were. The actual file was even provide. It was then that the extent to which DOCX support is broken in LO became exposed. 139915 is NOT a duplicate of this. The gist of this problem is that <b>LO cannot reliably save in DOCX</b> and the triage/support team cannot diagnose anything that isn't saved ODT. The ensuing discussions were how to have LO first save ODT then save DOCX and perform some kind of re-load so people could see just how mangled the DOCX document was. That's where this left off. It wasn't one itty bitty little problem but an entire slew. The <i>process</i> of saving in non-ODT doesn't work __and__ it doesn't create what support claims to need to diagnose. It's closed when the <i>process</i> of saving to a non-ODT format also creates the only format LO actually handles so that support has what they need to fix other issues.
Roland, whatever this bug is, it doesn't make sense anymore with your comments. You obviously didn't read https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status to know that Reopened is wrong status. You started with a concrete problem that is WFM and a duplicate. You comment so much without contribution that you didn't notice an effort to find exactly where. Then you switched to other talk, about saving in ODT. That's NOT this issue. DO NOT reopen it anymore.
Save as DOCX will stay as it is. And many thrown in comments from reporter do not make sense. Having a backup copy of ODT is worth considering but not here.
I did read it and this is not fixed! I read everything. You did NOT fix this and it is NOT "resolved." The concrete problem is caused by the problem you claim is not a contribution. LibreOffice does not save an ODT copy when saving as DOCX and support cannot fix squat without it. Do not close this until it is actually fixed.
Roland, please finally STOP spamming here and changing status. I'm from QA team and it's a decision. I still added main QA engineer and only he can open if needed.