Bug 96616 - FILESAVE: Generating a report as "Microsoft Word 2007-2013 XML" creates .odt with .docx extension
Summary: FILESAVE: Generating a report as "Microsoft Word 2007-2013 XML" creates .odt ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.4.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Reports Options-Dialog-Load-Save
  Show dependency treegraph
 
Reported: 2015-12-20 11:22 UTC by Sparrowbe
Modified: 2022-12-25 03:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
a database and created reports (17.03 KB, application/x-zip-compressed)
2015-12-22 18:38 UTC, Sparrowbe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sparrowbe 2015-12-20 11:22:14 UTC
The scenario:
- in Base open a .odb file that contains table(s) with content and report(s)
- open Tools/Options: Load/Save -> General
-- change field "Always save as" from "Open Document" to "Microsoft Word 2007-2013 XML" and save the Options window
- generate new report by double clicking on it

Actual result:
new file in created in the default location with .docx extension but it has Open Document's content, so it is unreadable by MS Word.
Comment 1 raal 2015-12-21 14:25:20 UTC
Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
Thank you
Comment 2 Sparrowbe 2015-12-22 18:38:38 UTC
Created attachment 121504 [details]
a database and created reports

Thank you for fast response.
Here are some files that may give a better view of the problem: a very small database with one table and simple report generator plus three report files (one created as "ODF text document", second as "Microsoft Word 2007-2013" and the last one as "Microsoft Word 97-2003") - all of them with the same content but different extension given by the LO itself.

Thanks,
Tom
Comment 3 Alex Thurgood 2015-12-23 16:54:48 UTC
This would be an error - LibreOffice doesn't currently support creation of reports as Microsoft XML, so the switch to default to such formats should perhaps include a warning that it will not be applicable to database reports.

That said, I'm not best placed to decide whether we should offer that possibility anyway. Personally, I don't see as a particular advantage, the whole point of the report writer is to produce ODF compliant documents from a linked database, but I can see the argument of wanting to be able to produce docx reports if the UI appears, via an application default setting, to offer that possibility. I also don't know how well our reports with various components (e.g. charts) currently export to docx (via the Save as menu), I would assume not very well, so this would open up a whole can of worms on that side. 

Confirming with regard to the application switch that doesn't offer what is written on the box, but opening up for debate as to whether it should.
Comment 4 Lionel Elie Mamane 2015-12-23 18:34:24 UTC
Just to be clear, if one does "file / save as" from the generated report, and saves *there* as "Microsoft Word 2007-2013 XML", then it is correctly saved as .docx, right?

I don't understand this "Tools/Options: Load/Save -> General / Always save as"... "Clearly" only Writer obeys that... I can't imagine Calc or Impress following that setting. But nothing in the setting says it is for Writer only. IMHO, that's a UI problem.
Comment 5 Alex Thurgood 2015-12-24 09:09:15 UTC
(In reply to Lionel Elie Mamane from comment #4)

> Just to be clear, if one does "file / save as" from the generated report,
> and saves *there* as "Microsoft Word 2007-2013 XML", then it is correctly
> saved as .docx, right?

Yes, I tried this yesterday and could open a normal report (i.e. containing tabular formatted report data) in Word 15.17.1 on OSX.


> 
> I don't understand this "Tools/Options: Load/Save -> General / Always save
> as"... "Clearly" only Writer obeys that... I can't imagine Calc or Impress
> following that setting. But nothing in the setting says it is for Writer
> only. IMHO, that's a UI problem.


Some large business deployments, e.g. corporations and administrations use this option as a default to "trick" users into thinking that they're working with a MS-Word clone, or because they have a policy of always saving to docx, but as far as I understood, yes, this only applies to word processing documents.

And personally I agree, it is more of a UI problem, but perhaps there is more to it than I know about. Maybe one of the devs more aware of what this option does can shed light on it.
Comment 6 Sparrowbe 2015-12-24 13:21:10 UTC
It looks like I found quite nice inconsistency :)

And yes, I got confused by the "Load/Save" section because there are separate sections like "LibreOffice Writer" or "LibreOffice Base" available only in Options menu opened from corresponding program. So the first guess is that those parameters are common for the whole suite (and they are - to some extent).

The only reason for changing that "Always save as" field, is dealing with huge report (>10 fields per record, one record per A5 page, about 2000 records) that freezes Writer for minutes (or even hours on some machines) when loading the document. The only option discovered so far is to save it as .doc(x) as MS Word deals with such big table with no delay. So I still consider reporting at least an enhancement against Writer's performance for this issue.

I understand your doubts about possible complaints related to compatibility, but I also have hard task to explain the final user of my database why she has to drink at least 3 coffees or teas before the generated report may be eventually printed.
Comment 7 Terrence Enger 2015-12-24 14:55:39 UTC
(In reply to Sparrowbe from comment #6)
> dealing with
> huge report (>10 fields per record, one record per A5 page, about 2000
> records) that freezes Writer for minutes (or even hours on some machines)
> when loading the document.

Wow!  It had never occurred to me that one would use LibreOffice to
process a file of that size.  Clearly, we do not handle this well.  I
wonder if *should* handle it.

Let me confess that I am an old-fashioned (and old) guy, accustomed to
creating reports by a loop: { read one record, print one record }.
This new-fangled PC with its concept of loading a whole file at once
leaves me befuddled <grin />.

So I ask ... 
(*) Looking for solutions within whole-file-at-once paradigm: Can we
    make LO work with a document this size?  Is it a reasonable amount
    of work?  Is there much demand?
(*) Is there anything in a report definition that would make it hard
    to process it in one or more sequential passes over the input,
    producing for example .pdf output?  Sparrowbe, would this meet
    your needs?
Comment 8 Sparrowbe 2015-12-25 11:40:29 UTC
Terrence, thank you for your comment on the topic.

My use case is to have kind of logbook of events, with possibility to add new entries either manually (with a nice Form) or by copy-paste from external spreadsheet. Then I have to print the subset of records in a form of a booklet. There is no need to edit the report before printing, so pdf suits my needs as well. However I miss a possibility to export only a slice of a table instead of the whole content (but let's leave this aside).

Regarding the Writer's performance, I created new Bug 96720 as I've investigated the problem more and found some other inconsistency in the content of the Base-generated .odt that may possibly lead to already mentioned freezes - the same file saved directly from the Writer is handled flawlessly.

Kind Regards,
Tom
Comment 9 QA Administrators 2017-01-03 19:55:17 UTC Comment hidden (obsolete, spam)
Comment 10 QA Administrators 2020-12-24 03:53:13 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2022-12-25 03:21:43 UTC
Dear Sparrowbe,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug