Package: odfit
Produces textual information based on the contents of
OpenDocument Format files and other archives.The information produced includes metadata like
the names, uncompressed size, and modification times of archive members.A checksum is calculated, and basic filetype detection performed on each.For each member determined to contain UTF-8 text,
the lines in the file are output.odfitis similar in purpose but different in operation,
and in its level of detail,
to tools likeodt2txtwhich output a text-mode
rendering of the archive as a document.This means that it presents a much more complete set of data,
including embedded macros, formatting, and other details.Information on binary files is limited to metadata
and hashes, including a SHA1 checksum.XML files will be pretty-printed
so as to make their contents more readilydiff-able.SETUPTheodfitscript can make do with
the standard library’s complement of modules.It will attempt to make use of thelxmlpackage
for XML pretty-printing,
but will fall back to standard library modules if necessary.So it should be possible to useodfitwith any Python 2.6 or later,
without requiring installation.This means that the executable module fileodfit.pycan be distributed with source repos with some reliability.Pythons older than 2.6 may also work,
but the script has not been tested with them.Iflxmlis available, XML processing will be faster (> 3x)
and more robust when dealing with incorrect or incomplete XML.In addition to running the scriptodfit.pydirectly,
the module can be installed from source
or viaPyPI.
This will cause an equivalent script to be installed system-wide,
enabling the commandodfiton the system path.USAGEodfitis a command-line tool.To get a listing of the members of an archive, run e.g.$ odfit some_file.odtFor a typical OpenOffice document, this will produce many lines of data.odfitis mostly intended for use with version control systems likegit,
in order to identify changes between versions of OpenDocument Format files.For example, with git 1.6.1 or later,
setting up a repo to useodfitto generategit difflistings
can be accomplished byadding lines to.git/configor equivalent
to set thetextconvoption for theodfdriver name:[diff "odf"]
    textconv=odfit -Dassociating the various ODF filetypes with theodfdriver name
by adding lines like the following
to a.gitattributesfile in the repo working tree
or in.git/info/attributes:*.odt diff=odf
*.ods diff=odf
*.odp diff=odf
*.odb diff=odfThe-Doption toodfdumpinstructs it
to omit the timestamp of each archive member.
OpenOffice seems to reset this timestamp for all members
whenever it saves a new version of a document.
Because of this, this piece of data is not meaningful
and shouldn’t normally be displayed as part of a diff.
For this reason, I expect that-Dshould normally be passed
when generating a dump for the purposes of diffing.More info (based on usingodt2txtinstead ofodfit)
is available from thegit wiki.odfitis also suitable for use with other pkzip-formatted archives.
See the note aboutfiletype detectioninBUGS, ISSUES, and WARNINGS.OUTPUT FORMATMetadata HeaderOutput for each contained file will consist of a series of header lines,
each prefixed with the member filename and a colon followed by two spaces.
For example:path/to/member/file:  date_time: 2010-10-12T21:32:24
path/to/member/file:  file_size: 42
path/to/member/file:  CRC: 4144865272Each line contains a name/value pair delimited by an additional colon and space.The metadata included in the header is that stored in the archive file itself,
plus the exception of thesha1element,
which is calculated byodfitfrom the archive member’s data.Not all member attributes are dumped.
The attributes which are dumped if nonempty for a given archive member are:timestamp:date_timecommentextrafile_sizeCRC-32 checksum:CRCThe timestamp will only be output if the-Doption
has not been passed on the command line.After these attributes, two more header lines will be output,
containing the member’s SHA-1 hash and the detected filetype.
The detected filetype will be eitherbinary,utf-8(which subsumes ASCII), orunknown.Content sectionAfter the header, printable files (those whose filetype isutf-8)
will have their content dumped.The output for the content section
is similar to that used for the header section.Rather than name/value pairs, lines of the file are output.The delimiter between filename and content is two colons and a space.For example:path/to/member/file:: The first line of the file
path/to/member/file:: The second line of the file
path/to/member/file:: The third line of the fileA file is assumed to be printable if it is not detected as binary.
Seefiletype detectionfor more information.XML FilesThe content of files whose names end in.xmlwill be passed through an XML tidying routine before being dumped.This is intended to make the output morediff-able
by splitting long lines containing multiple elements.The presence of files containing poorly-formed XML
may result in errors because of this.
This should not be a problem for documents created with OpenOffice.BUGS, ISSUES, and WARNINGSBinaryfiletype detectionuses the same stupid algorithm asgit diff:
scanning for nulls within the first 8000 bytes of the file.
This works well enough with ASCII or UTF-8 text,
but will falsely detect as binary files in encodings such as UTF-16.There are no plans to guarantee consistency between versions.
So a dump created with an older version  ofodfitshouldn’t be compared with a dump created with a newer version.
Even with the same version ofodfit, dumps of the same document
may differ because of different dependencies:odfitwill use different XML packages depending on
what is locally installed, and the pretty-printed output of XML files
will vary depending on the XML package used.
Thelxmlpackage will be used if it is locally available.The output format is intended only for reading and comparison purposes.
It is not intended to be a reversable translation of the original,
even for archives which contain only text files.
In particular, filenames containing ‘:’ characters
are not properly escaped.
There will be additional ambiguities in dumps from files
containing members with identical filenames.I haven’t yet checked to see if the order of members
of an odf file is stable.odfitcurrently does not sort the members before outputting them:
member output is done in archive file order.
This means that comparison of dumps of equivalent documents
may end up showing significant differences.There are many performance optimizations which could be put in place,
particularly if the script were to be reworked as a diff routine.
Having knowledge of both of the compared documents would allowodfitto, for example, only output XML for files which have changed.
It’s also very unlikely that a SHA-1 comparison
will detect changes that a CRC-32 comparison does not.odfitis not tested with Python versions other than 2.6.
This means that there’s little guarantee
that it will work on any particular system,
since 2.5 and even 2.4 are not uncommon in the field.LICENSEodfitis copyright 2010 by Ted Tibbetts
and is licensed under the FreeBSD license.See the file COPYING for details.