Download it now!
Bug 133661 - New document created using Explorer New context menu (ShellNew) must match LibreOffice's new document settings
Summary: New document created using Explorer New context menu (ShellNew) must match Li...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords: easyHack
: 133678 133689 135853 (view as bug list)
Depends on:
Blocks: Desktop-Integration
  Show dependency treegraph
 
Reported: 2020-06-04 07:54 UTC by Mike Kaganski
Modified: 2020-08-25 06:43 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A *very* empty ODT, suitable for solution #1 (693 bytes, application/vnd.oasis.opendocument.text)
2020-08-18 06:44 UTC, Mike Kaganski
Details
A *very* empty ODT, suitable for solution #1 (642 bytes, application/vnd.oasis.opendocument.text)
2020-08-18 07:39 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-06-04 07:54:44 UTC
Currently we use a fixed "templates" (actually documents) in instdir/share/template/shellnew to create new documents using shell's "New" context menu on Windows - it takes the path to the source document from registry (FileName value in e.g. HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew) and copies it to the destination.

Some problems with this approach are:

1. The templates are in instdir, which is not modifiable by user without admin rights;
2. If user modifies the path to the templates, it is re-written at each LO update (bug 94857);
3. The template is a document with all the usual properties (styles, formats, languages, creation dates, editing times, ...) that don't match the settings defined in LibreOffice for new documents (default fonts or custom templates, locale-dependent options like default page format, localized style names etc.) (bug 35912, bug 48344, bug 90286, bug 91172, bug 120141, bug 122190).

There are some possible ways to improve the situation:

1. Try to improve the templates themselves. E.g., find out what might be removed from the ODF package to still be a valid ODF, yet not include the information that must be set to default when opened in LibreOffice. That might be possible for some properties; yet for sure, that wouldn't be possible for all of them, and in any case, it won't allow to reset to settings of *default custom template* configured by user.
2. Add a special setting into app-specific settings in settings.xml, which would tell LibreOffice to reset everything to defaults on open (and drop the setting, naturally). Possibly the best option.
3. Implement tdf#124877 (a command-line argument to create new empty documents), and use it in the ShellNew's Command value [1]. That would mean that when user clicks the context menu, LibreOffice process starts, loads the required module (e.g. Writer) to create the document, saves it to the specified location, and exits. Too much overhead IMO.
4. Implement tdf#123476 (consider file extension when opening 0-byte files to create new files of proper type), and use it not only for MS Office document types (compatibility hack), but also for ODF extensions. Would be non-standard, but *presumably* OK since intended for immediate opening with LibreOffice, which would convert that into proper documents on save.

I suppose that any of those approaches would not only fix problem #3, but also eliminate the *need* to modify templates (problem #1) or configure non-standard paths in ShellNew, thus obsoleting bug 94857 (problem #2).

[1] https://docs.microsoft.com/en-us/windows/win32/shell/context
Comment 1 V Stuart Foote 2020-06-04 12:29:02 UTC
+1
Comment 2 V Stuart Foote 2020-06-04 18:40:43 UTC
*** Bug 133678 has been marked as a duplicate of this bug. ***
Comment 3 christos 2020-07-13 10:33:59 UTC
*** Bug 133689 has been marked as a duplicate of this bug. ***
Comment 4 Mike Kaganski 2020-08-18 06:07:56 UTC
*** Bug 135853 has been marked as a duplicate of this bug. ***
Comment 5 Mike Kaganski 2020-08-18 06:44:11 UTC Comment hidden (obsolete)
Comment 6 Mike Kaganski 2020-08-18 07:39:37 UTC
Created attachment 164399 [details]
A *very* empty ODT, suitable for solution #1

A better empty ODT. It was created from the respective sources using this python code:

> from zipfile import ZipFile, ZIP_STORED, ZIP_DEFLATED
> 
> with ZipFile('path/to/empty.odt', 'w') as myzip:
>   myzip.write('path/to/mimetype', 'mimetype', ZIP_STORED)
>   myzip.write('path/to/META-INF/manifest.xml', 'META-INF/manifest.xml', ZIP_DEFLATED)
>   myzip.write('path/to/content.xml', 'content.xml', ZIP_DEFLATED)

And the result passes https://odfvalidator.org.
The other ODF documents (ODS, ...) are left as easyhack.
Comment 7 Mike Kaganski 2020-08-18 09:07:11 UTC
https://gerrit.libreoffice.org/c/core/+/100899 is the sample change for soffice.odt. Marking this easyhack, so that people could work on other template documents.
Comment 8 Commit Notification 2020-08-18 10:05:15 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3a7a06067e545670ef64367ef602469f507a3df7

tdf#133661: make soffice.odt a bare minimal ODT, with no data at all

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2020-08-25 06:03:00 UTC
Ezinne Nnamani committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ba0f4652b6743b3de6d692f87f688238a0eee9ce

tdf#133661 Modified soffice.odp/ods/odg files to empty bare minimal ODF files

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.