OpenOffice-OODoc
view release on metacpan or search on metacpan
of a "Document" object (created with ooDocument), the user should use the Text,
Image, Styles AND Document manual pages. The OpenOffice::OODoc::Document class
inherits all the features provided by the other classes with the exceptions of
OpenOffice::OODoc::File and OpenOffice::OODoc::Meta.
=head2 OpenOffice::OODoc::Meta
This manual page describes all the available methods to be used in order to
control the global properties (or "metadata") of a document. Most of these
properties are those an end-user can get or set through the "File/Properties"
command with the OpenOffice.org desktop software.
=head2 OpenOffice::OODoc::Manifest
This manual page describes the manifest management API, knowing that the
manifest, in an ODF file, contains the list of the file components
(or "members") and the media type (or MIME) of each one. The text content,
the style definitions, the embedded images, etc. are each one stored as a
separate "member".
=head1 GENERAL FUNCTIONS (EXPORTED)
OODoc/Intro.pod view on Meta::CPAN
style => 'Text body'
);
$document->appendTable("My Table", 6, 4);
$document->cellValue("My Table", 2, 1, "New value");
$document->save;
The script above appends a new paragraph, with given text and style, and
a table with 6 lines and 4 columns, to an existing document, then inserts
a value at a given position in the table. It takes much less time than the
opening of the document with your favourite text processor, and can be
executed without any desktop software connection. A program using this
library can run without any OpenOffice.org installation (and, practically,
OODoc has been tested on platforms where OpenOffice.org is not available
yet).
More generally, OpenOffice::OODoc provides a lot of methods (probably most
of them are not useful for you) allowing create/search/update/delete
operations with document elements such as:
- ordinary text containers (paragraphs, headings, item lists);
- tables and cells;
OODoc/Manifest.pod view on Meta::CPAN
=head1 DESCRIPTION
The OpenOffice::OODoc::manifest class is a specialist derivative of
OpenOffice::OODoc::XPath allowing access to the content descriptor
of an OpenDocument or OpenOffice.org file.
For ordinary content processing applications, it's not absolutely
necessary to control the manifest. Member imports or deletions
(ex: createImageElement() in OpenOffice::OODoc::Image, raw_delete()
in OpenOffice::OODoc::File) may make the real content inconsistent
with the manifest. Up to now, the OpenOffice.org desktop suite don't
worry about that. However, OpenOffice::OODoc::Manifest provides a
few number of easy to use methods to get or set any entry in the
manifest. In addition, it allows the users (at their own risks) to
create or update any kind of special entry or mime type, without
control. There is no automatic consistency check between the manifest
and the real content (but this check and others could be easily
developed with the combination of this module and the other ones).
The manifest (i.e. the "META-INF/manifest.xml" part of an ODF package)
is a special member that describes the MIME types and the full internal
OODoc/Meta.pod view on Meta::CPAN
Adds 1 to the editing cycle count that is stored in the document, and
returns the new count. This count should be incremented each time
the document is edited through an ODF-compliant application.
See also editing_cycles().
=head3 initial_creator()
Like creator(), but apply to the creator of the first version of the
document. The OOo desktop software never updates this value, but this
method allows the user to read or write it.
=head3 keywords()
Without argument, returns a list of the document's keywords. In a
list context, the result is a table where each element is a keyword.
In a scalar context, the keywords are returned in a single character
string, each of which is separated by a comma and a space.
With arguments, adds a list of keywords to the existing one. The
OODoc/Meta.pod view on Meta::CPAN
$meta->statistic
('meta:table-count' => '4', 'status' => 'OK');
This example forces the number of tables to 4 (whatever the reality)
and adds an arbitrary attribute 'status' with value 'OK'.
Note : Such forced attributes do not upset the function of
the office software which ignores them. They could therefore be useful
in programs which handle documents out of reach of the end user.
However, if such a document is then edited or updated by a typical
end-user desktop application, these "foreign" attributes could be lost
and and replaced by what this application considers to be the "real"
values to those attributes it manages.
=head3 subject()
Without argument, returns the document's subject.
With argument, adds a new subject to the document.
=head3 title()
OODoc/Styles.pod view on Meta::CPAN
is not a problem for user-defined styles as the stored display-name is exactly
the same as the effective display name.
There are also numerous "automatic" styles in a document which are
created implicitly by the office application each time a particular
set of presentation attributes is given to an element, but where no
named style is referenced. Automatic styles which apply to the
document body are stored in content.xml (but in an XML element
isolated from the content). An automatic style's name can change
randomly each time the document is edited or saved through an interactive
desktop application. Applications which access automatic styles will not
want to indicate them using "hard-coded" names. The best way is to
retrieve each automatic style via an object that is known to use it.
Using a "hard-coded" name is all right for styles created by a
program (the createStyle() method requires it), but such a name should
only be considered to be stable for the duration of the session. If
you want a program-created style name to be then respected by
OpenOffice.org, you must create it as a named style. This is no more
complicated, but it is better to avoid making hundreds of styles
visible to the user that they do not need to see.
OODoc/Text.pod view on Meta::CPAN
=head3 expandTable(table, height, width)
Increases the size of the given table or spreadsheet.
This method silently executes a full normalization of the table before
resizing it. See normalizeSheet() for details about this operation.
This method is specially useful in order to ensure the availability of
an appropriate workspace in a spreadsheet whose apparent size is
almost unlimited through the GUI of a typical desktop software but
but whose real size is unknown and/or doesn't include all the target
area of the application.
The vertical expansion is implemented by repetitive replication of the
last row, while the horizontal expansion is implemented by repetitive
replication of the last cell of the last row. So the new cells in the
right side are copies of the old bottom-right cell, while the new rows
are copies of the old last row.
Any size argument which is not larger than the previous height or width
OODoc/Text.pod view on Meta::CPAN
=head3 lockSection(section [, key])
Installs a write protection on the given section.
If a second argument is provided, it's stored as an encrypted key
which is associated to the write protection. Caution, it's not the
key as it should be typed by the OOo end-user.
Such a write protection works only when the document is edited through
an OpenOffice.org-compatible desktop software. It doesn't prevent the
programs using OpenOffice::OODoc from deleting or updating the
protected sections.
=head3 makeHeading([options])
Creates a new heading element, or marks as a heading an existing
element.
Options:
examples/odffilesearch view on Meta::CPAN
#-----------------------------------------------------------------------------
# $Id: odffilesearch 0.007 2008-05-04$
#-----------------------------------------------------------------------------
=head1 NAME
odffilesearch - File selection by keywords
=head1 SYNOPSIS
odffilesearch -R "D:\Documents\*.odt" openoffice desktop XML
produces the list of the ODF Text documents present in the given
directory and its subdirectories, and containing the words
"openoffice", "desktop" AND "XML"
odffilesearch -command "rm -f %f" "*.ods *.odt" lost dismiss cancel
executes the "rm -f filename" (i.e. deletes the file in a Unix system)
for each ODT or ODS file present in the current directory
and containing the words "lost", "dismiss" AND "cancel"
=head1 USAGE
odffilesearch [-options] <file filter> <keyword list>
( run in 0.483 second using v1.01-cache-2.11-cpan-299005ec8e3 )