Is it ok to use on production?

[em...@gmail.com, em...@gmail.com]

Hello all,

I am analyzing ODTToolkit in order to replace Aspose in a project to generate .odt files, and I have some doubts.

1- Is there a final distribution that is ready to use on production projects?
I downloaded all available... there are ones with incubating code, some incomplete, and some with all dependencies needed.

2- On OpenOffice, we are able to write a text, open Character properties and apply a border around it and apply zero padding.
And we can see the border and padding applied to the text-properties in the content.xml:
<style:text-properties loext:shadow="none" loext:border="0.06pt solid #000000" loext:padding="0in" officeooo:paragraph-rsid="00129e44" officeooo:rsid="00129e44"/>

But I could not find a way to apply border and padding using the Text related classes, but only the Paragraph ones, and even using margin and other stuffs it is hard to get the same result.

Is there a way to have the border and padding applied to a text with ODFdom or SimpleODF APIs?

3- In case I have a left-aligned text, is it possible to get the position of first character of it, so that I can set the Indent (First Line or Before Text at OpenOffice).

Thanks for any help in advance.
Emerson Roman

Re: Is it ok to use on production?

[Svante Schubert <sv...@gmail.com>]

 Hello Emerson,

2018-07-05 5:39 GMT+02:00 emersonroman@gmail.com <em...@gmail.com>:

> Hello all,
>
> I am analyzing ODTToolkit in order to replace Aspose in a project to
> generate .odt files, and I have some doubts.
>

It is always valid to have doubts. Let me try to address those by guiding
you through the basic architecture and design decisions.

The core piece of the ODF Toolkit is the ODFDOM library.
All ODF documents are able to be loaded and saved without any loss of
information, as all XML is being stored in a DOM tree. A DOM tree allows
the generic expansion of the ODF document model even if there might be
custom XML nodes within the document.
In addition, it enables any XML technology as XPath queries on the tree or
running XSLT scripts directly on the ODF document (using the XSLT Runner
<http://incubator.apache.org/odftoolkit/xsltrunner/ODFXSLTRunner.html>).

The source code of the DOM is directly being generated from the grammar of
ODF, the ODF RelaxNG schema
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-schema.rng>.
But it became early apparent there was an need from customers for an easy
user view. Some higher level API, which does the obfuscating of the
underlying verbose XML syntax. We at Sun Microsystems called it the DOC
API, as we already had the underlying PKG API (package layer) dealing with
the ZIP storing the XML and images, the signatures and encryption and
obviously the generated classed of DOM API.
There had been some disconsense on the project between some IBM and Sun
developers and IBM forked and created the Simple API. When Oracle (after
buying Sun) donated the ODF Toolkit sources to Apache, IBM rejoined and
Simple API become a redundant piece. Therefore we deprecated the DOC API in
favor of the Simple API.

Nowadays, I believe it was not the perfect choice as are several source
code redundancies in the Simple API to ODFDOM and from a strategic view I
would like to generate more than currently possible from the ODF RelaxNG
grammar instead writing it by hand.
For instance, the grammar states that a paragraph (<text:p> XML element)
might have a @text:style-name attribute, but it does not mentioned that it
is always related to some @style:name of a style element of the styles. In
addition, when there is an XML parent element having multiple XML child
elements with an ID, the source code generator should provide the creation
of a lazy Map (e.g. for styles - in our case the ID would be the style:name
& style:familiy, which are identified as String and not as IDs, but this
could be declared in some configuration file for generation, as we already
have one config file
<https://github.com/apache/odftoolkit/blob/trunk/generator/schema2template/src/main/resources/examples/odf/config.xml>
 for all the "default values" and "style:family<->stylable element
relation". The default values are being extracted diretly from the ODF
specification by XSLT
<https://github.com/apache/odftoolkit/blob/trunk/xslt-runner/sample_xslt/getAttributeDefaults.xsl>
.
Therefore, I am working to generate as much as possible from the ODF XML
RelaxNG schema and additional information (e.g. styles linking, maps, etc.)
but also what are the root XML elements of the customer known entities as
paragraph, image, table, etc.
For this reason, I have started to experiment with the Apache Tinkerpop
Graph database using the Gremlin graph scripting language. I got funding
for the upcoming winter from the German government to work further in this
area.


> 1- Is there a final distribution that is ready to use on production
> projects?
> I downloaded all available... there are ones with incubating code, some
> incomplete, and some with all dependencies needed.
>

The latest sources on the repository is the latest production version.
Similar as you do not download a new version from Chrome but it is being
updated according to their sprints, I do no longer believe in version
numbers and yearly software cycles.
There are regression tests for the major feature and code reviews for every
patch.
There is a JAR with all dependency needed to ease the use from command line.
The "prefix" incubating is from Apache as there are not enough devolpers in
the past years to let it become a top level project. I personally would add
some features and change some designs before I would give out a 1.0, still
the product had been used for years by Sun/Oracle, IBM and Open-XChange on
the back-end to modify ODF documents. But too often they had forked and did
not contributed back.

I am a Freelancer from Berlin and if you need, I might provide you support
and guidance on a professional level addressing the problems that are
important to you.

>
> 2- On OpenOffice, we are able to write a text, open Character properties
> and apply a border around it and apply zero padding.
> And we can see the border and padding applied to the text-properties in
> the content.xml:
> <style:text-properties loext:shadow="none" loext:border="0.06pt solid
> #000000" loext:padding="0in" officeooo:paragraph-rsid="00129e44"
> officeooo:rsid="00129e44"/>
>
> But I could not find a way to apply border and padding using the Text
> related classes, but only the Paragraph ones, and even using margin and
> other stuffs it is hard to get the same result.
>
> Is there a way to have the border and padding applied to a text with
> ODFdom or SimpleODF APIs?
>
> If it is working with any ODF application and the information is stored in
the ODF XML - which is likely for OpenOffice - it is possible to address
with the ODFDOM as it allows the full access of the XML.
I am not aware of it in the Simple API, I suggest to take first a look at
the regression tests.



> 3- In case I have a left-aligned text, is it possible to get the position
> of first character of it, so that I can set the Indent (First Line or
> Before Text at OpenOffice).
>
> Yes ;-)
What I usually do if I need to investigate a feature in ODF XML (same for
OOXML) is to save the XML feature before and after the feature is enabled to
understand the XML being involved.
When located the XML nodes, you will find futher information in the ODF
specification (I prefer to use the HTML version of the spec)
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html>.

Thanks for any help in advance.
> Emerson Roman
>

To summarize the answer to your question:
Yes, production usage is not even valid, it more the library has matured
over years and is being used since ever in the production of several
companies.

Certainly, there are still things to improve, there always will be, like
dropping the DOM with its XML support in favour of a lower memory
footprint. As this is generated code it should be even possible to offer
both options by providing two different generated libraries.
Finally, I am certain Aspose as a company is far beyond in ODF know-how.
Several OASIS ODF technical committee (TC) members are working on this
project (including me) and there the upcoming collaboration approach by
dispatching user changes instead of documents is unique. Remember, sending
documents for collaboration is as clever as zipping your source code and
sending this. ;-)

If you are still not convinced, we might even have a short call, where you
can ask everything I might have missed, although the list is preferred so
others might get the answers as well.

Cheers,
Svante
ᐧ