incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <>
Subject Re: GSoC: ODF Command Line Tools Application
Date Mon, 19 Mar 2012 19:16:59 GMT
On 19.03.2012 17:30, Michał Jaskurzyński wrote:
> Hi Rob,
>> One observation:  you
>> have a -s parameter that contains a mini script of commands.  Could
>> this be a in a separate file as well, which could make it easier to do
>> more complex scenarios?
> Yes, I mentioned that in first example. -S will read script from file
>  >We could even have a special "small language"
>> for text processing of WYSIWYG documents.  The interesting thing about
>> that approach is that the same syntax could be implemented on multiple
>> languages, e.g., ODF Toolkit for a GSoC project, but then someone else
>> could implement on top of Apache POI to support MS Office documents.
>> So it will be good to have a clean abstraction and separation between
>> the command layers and the ODF-manipulation layers.
>> I think the Simple API that we have today is a good level of
>> abstraction for many text operations, but it requires a skilled Java
>> programmer to work with it.  They don't need to understand ODF in
>> detail, but they do need to understand Java.
> I think that most of commands can by translated directly to java api
> so script like this:
> newImage(filename);
> addParagraph(content);
> addList("element1", "element2");
> addTable(3, 3);
> This approach can be easily implemented in our tool and it will let to
> create odf documents from shell script. The another advantage is that
> programmer will not have to learn new api.
I assume that the above code is meant similar to a stack, where every
command is appending an entity to an ODF document, right?
What if you want to add something to arbitrary places within a document,
for instance reusing ODF entity once created?
Like if you are not referencing by parameters of an operation to a
certain place in the document, it might indicate that the component
should be appended to the end of the document.

Some similar approach as you plan is under development in OASIS, where
the changes of a document are saved in a queue of operations in a new
ODF XML file called undo.xml. To be precisely the operation to undo the
changes are being saved, as new ODF change-tracking.
Basically the idea is the same and these operations are intended to be
overtaking as high-level API to this project.
I have uploaded last Friday some examples [1] and there is presentation
[2] providing an overview to this approach.
Perhaps this work might be inspiring.




View raw message