LibreOffice likes to produce a certain amount of bogosity in it's files.
If you create a blank writer document and save it you see:
unzip -l /tmp/empty.odt
Length Date Time Name
--------- ---------- ----- ----
39 2013-02-11 21:48 mimetype
906 2013-02-11 21:48 meta.xml
9863 2013-02-11 21:48 settings.xml
3241 2013-02-11 21:48 content.xml
728 2013-02-11 21:48 Thumbnails/thumbnail.png
899 2013-02-11 21:48 manifest.rdf
0 2013-02-11 21:48 Configurations2/images/Bitmaps/
0 2013-02-11 21:48 Configurations2/popupmenu/
0 2013-02-11 21:48 Configurations2/toolpanel/
0 2013-02-11 21:48 Configurations2/statusbar/
0 2013-02-11 21:48 Configurations2/progressbar/
0 2013-02-11 21:48 Configurations2/toolbar/
0 2013-02-11 21:48 Configurations2/menubar/
0 2013-02-11 21:48 Configurations2/accelerator/current.xml
0 2013-02-11 21:48 Configurations2/floater/
11252 2013-02-11 21:48 styles.xml
1086 2013-02-11 21:48 META-INF/manifest.xml
28014 17 files
Having a load of empty 'Configurations2/' directories - that - might (but don't) hold something useful is a bit sad / pointless.
It would be nice to remove (or not create) those directories unless they are needed. This probably has something twisted to do with the framework/ code hereabouts:
framework/inc/uiconfiguration/moduleuiconfigurationmanager.hxx: class ModuleUIConfigurationManager
with this sort of thing:
framework/inc/uielement/uielementtypenames.hxx:#define UIELEMENTTYPE_FLOATINGWINDOW_NAME "floater"
One gotcha to bear in mind is that the package2 (etc.) APIs we use to create and store streams are -horribly- awful; and creating sub-directories is really deeply unpleasant in packages. The lifecycle / 'commit' calling etc. on the interfaces is really poor - which perhaps is the reason why it is as bad as it is. Nevertheless if we can detect and avoid creating at least the sub-directories of Configurations2 we're winning I feel :-)
The folder should hold the configuration, which is saved inside the document. That should be possible, but has errors in older versions and seems to be broken totally now. For details see https://issues.apache.org/ooo/show_bug.cgi?id=98123
The discussion with Carsten Driesner, which is mentioned in the OO.o bug, is in http://firstname.lastname@example.org&q=subject:%22[de-users]+Verkn%C3%BCpfung+Short+Cut+mit+Makro%22. But unfortunately it is in German.
Created attachment 75808 [details]
Template with toolbar inside
To give you an example, where the Configuration2 folder contains something useful, I attach a template. It is a template for writing French documents. It contains a toolbar to insert the special French characters using macros. A document which is generated from this template, has the toolbar in Configuration2 folder too. So you can easily test, whether your solution to avoid the empty folder will not destroy the ability to store a toolbar inside a document.
Hi Regina - thanks for your input ! :-)
I have no doubt that it is possible for these directories to hold something useful :-) surely they can.
However - when there is no keyboard customisation / configuration etc. (and I'm certain we havn't configured any keybindings / floaters etc. in this doc) - then we should not be creating empty directories that serve no useful purpose in the ODF file.
But of course, it'd be interesting to fixup those other problems too - thanks for the pointers ! :-)
I read and tested Alex's patch here:
And it appears to be a lot better - though we still end up with this empty directory:
0 Stored 0 0% 2013-04-24 08:31 00000000 Configurations2/images/Bitmaps/
0 Defl:N 2 0% 2013-04-24 08:31 00000000 Configurations2/accelerator/current.xml
But encouragingly we get the accelerators serialized as expected. I guess for a document opened read/write it is not needed to create those storages until the data is written; but ...
Any more explanation of the code change - much appreciated ...
First, sorry for such a late response.
The idea is that the storage elements are opened again in the UIConfigurationManager::storeToStorage method (same file), so, basically, if there is a need to store anything, they will be reopened as writeable.
As you pointed out, my current patch does not purge these directories in files that already contain them, but are empty.
I've found this documentation of the XStorage interface , but I am not quite sure how to go about determining if the storage element is empty. There surely is something I am missing. It would be very helpful if someone could point me in the right direction.
Ok - you convinced me :-) good work - I pushed it.
To further improve this to delete empty directories you'd want to queryInterface on the XStorage for:
and call getElementNames - clearly if there are none - it is empty; and then do some removeElement on the XStorage interface to clean them out :-)
Of course, that'd need some testing; and particularly with the flat-ODF filters: not sure how they work in this regard (prolly fine but... save as '.fodt' or '.fods' etc.).
Anyhow thanks for the nice fix ! and sorry for the slow review cycle.
commit da06166015689eca260c702602bef4cea58afbd3 caused a regression, it is not possible to save new custom toolbars and it is not possible to modify existing custom toolbars any longer. See bug 69500. Benefits of this commit do not outweigh the harm it causes, so it's better to revert it.
As we re-fix this, we should clearly add a regression test for saving a toolbar =) Alex - any thoughts ?
Beyond the matter whether it is nice or not, 0 byte-sized files mean a blocking problem at applying digital signature technology according to the related standards.
The ODF v1.2 says, that "Document signatures shall contain a <ds:Reference> element for each file within the package [...]". For interoperability reasons it is also highly recommended to use "ASiC-E with XAdES/CAdES" format of ETSI TS 102 918 standard which requires the signature to cover all the elements of the package. But in case of having 0 byte-sized files in the files-to-be-hashed-and-signed set, a strict CEN CWA 14170 requirement can not be met which says, that it is a threat, if a "signature is generated to a 'null' document".
Possible solutions for this issue are: e.g. simply deleting 0 byte-sized files from the package, or inserting some "dont-care" content into them such as XML comments, or an XML root element.
I have made a search for the zero byte files with the attached script. The result: Formulas with modified style has got zero current.xml files, too, and LibreOffice uses a zero file to store default dialog language. See the following files in the attached test document:
Created attachment 95917 [details]
test file saved in LibreOffice master with extra zero byte files
check with unzip -v
Created attachment 95918 [details]
Bash script to test odts for zero byte files
This is for a quick test using locate to test all ODTs of the system. The script lists the invalid test files of xmlsecurity and qa, too:
1 /home/laci/git/libo/sfx2/qa/complex/sfx2/testdocuments/CUSTOM.odt: mimetype
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo2_x_doc1.odt: Pictures/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo2_x_macro1.odt: Basic/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo2_x_macro2.odt: Basic/Standard/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo2_x_macro3.odt: Basic/New Folder/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo2_x_macro4.odt: Basic/Standard/New Folder/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo3_2_doc1.odt: META-INF/New Text Document.txt
1 /home/laci/git/libo/xmlsecurity/test_docs/documents/invalid_ooo_3_2_doc2.odt: New Text Document.txt
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)