Issues with AsciiDoc ODT backend under Windows

SqueezeMyLemon commented 11 years ago

Hi,

I have been trying to get the ODT backend to work under Windows XP (SP3) together with AsciiDoc 8.6.8 & OO 3.4.1 but am having issues. After making a couple of minor tweaks (e.g. to odt.conf) I got it to run, but still find some basic features not working. For example:

FODT output:

images not embedding properly with data-uri
admonition icons not linking correctly without data-uri

ODT output

missing document title
TOC not displayed correctly
numbered lists not working
images generate an error
icons generate an error with data-uri
text formatting (embolden, emphasis, colours etc.) not applied

Are these issues known/expected?

Cheers, Will

dagwieers commented 11 years ago

I am not surprised that ODT support has more issues, because it is more complicated to in a2x. I don't use ODT myself.

For the FODT support in asciidoc, what exactly is the problem ? I think both issues are already in the issue-tracker (one is related to LibreOffice, the second is related to an asciidoc problem).

SqueezeMyLemon commented 11 years ago

These are the issues I found so far...

General issues

System date function

Lines 722 & 723 in odt.conf cause an error:

<meta:creation-date>{sys:date --date={revdate={docdate}} +%Y-%m-%dT%H:%M:%S 2>/dev/null}</meta:creation-date>
<dc:date>{sys:date --date={docdate={revdate}} +%Y-%m-%dT%H:%M:%S 2>/dev/null}</dc:date>

Replacing with a simple reference to AsciiDoc defined attributes should be more platform independent:

<meta:creation-date>{docdate}T{eval:'{doctime}'[:8]}</meta:creation-date>
 <dc:date>{docdate}T{eval:'{doctime}'[:8]}</dc:date>

There is probably a cleaner solution to that though.

FODT backend

Images

When data-uri attribute is set the image is very small (I see this is raised already as a separate issue). I guess it is due to ODT not allowing for "original size" on dimension attributes for embedded images and assigning default dimensions of 0.57cm. BTW - if there is a solution to this, then it could be nice/cleaner to apply to admonition icons too rather than specifying a default size.

Icons & images

When data-uri attribute is not set, admonition icons & images are not linked properly. In the source for example:

xlink:href="C:/bin/asciidoc-8.6.8/images/icons/note.png"

In OO it is showing as:

file:///C:/_test/odf_test/C:/bin/asciidoc-8.6.8/images/icons/note.png

Prefixing the path with file:/// seems to resolve the issue in OO. For example, in odt.conf change line 432:

ifndef::data-uri[<draw:image xlink:href="{icon={iconsdir}/{name}.png}" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>]

to:

ifndef::data-uri[<draw:image xlink:href="file:///{icon={iconsdir}/{name}.png}" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>]

Text formatting - strikethrough

Strikethrough ([line-through]#xxx#) is not working. Seems asciidoc.odt.styles specifies style name as "strikethrough", but should be "line-through". For example, change line 568 in asciidoc.odt.styles:

<style:style style:name="strikethrough" style:family="text">

to:

<style:style style:name="line-through" style:family="text">

ODT backend

Hard coded path

Line 80 in a2x-backend.py causes an error:

opts = AttrDict(base_doc=os.path.join('/etc/asciidoc/backends/odt/asciidoc.ott'), temp_dir=None) # TODO remove hardcoded dir

Replacing with dynamic path reference should be more platform/installation independent:

opts = AttrDict(base_doc=os.path.join(os.path.dirname(os.path.abspath(__file__)), 'asciidoc.ott'), temp_dir=None)

There is probably a cleaner solution to that though.

Document title missing

The main document title seems to not be showing at all. I found adding a meta.xml file with the title set (and corresponding entry in manifest.xml) resolved it.

Admonition icons

These are not aligned properly compared to the text block - they are positioned above the text not to the side.

Numbered lists not working

They are displayed as regular lists, although the source/style name looks to be correct.

Text formatting - general

A lot of the text formatting (for example emphasis, embolden, underline, strikethrough, colours etc.) is not applied correctly (could be linked to issue with numbered lists above).

Cheers, Will

dagwieers commented 11 years ago

Can you send pull-requests for these changes ?

It's very easy in Github to do this, as you can simply edit any file and turn it into a pull-request.

Thanks a lot for going the extra mile !

dagwieers commented 11 years ago

docdate fix: this only would work if the format of the docdate would follow the ODF standard, which is not guaranteed.
image sizes: it is undefined how and ODF consumer should handle this, and none are doing what one would expect.
document title missing: for ODT files we should not make use of the meta-data (or generate the meta.xml)
admonitions: the style should be constructed so that it does the right thing, there is no easy fix
formatting/lists: are the correct styles included, the problem with ODT is that it "merges" the original file with what we generate

If you make a pull-request (or issue) for each fix or new problem, we can discuss each of them in its own thread. Much easier :-)

SqueezeMyLemon commented 11 years ago

Can you send pull-requests for these changes ?

Sure, will do!

docdate fix: this only would work if the format of the docdate would follow the ODF standard, which is not guaranteed.

Well docdate is currently set in asciidoc.py using the date_str function. This function hardcodes the format:

return time.strftime('%Y-%m-%d',t)

So I think it is safe to use, unless asciidoc is changed to use a different format (e.g. system format etc.).

image sizes: it is undefined how and ODF consumer should handle this, and none are doing what one would expect.

Yea seems strange to me that this basic functionality is missing from the ODT specification.

document title missing: for ODT files we should not make use of the meta-data (or generate the meta.xml)

Why should we not use meta.xml?

admonitions: the style should be constructed so that it does the right thing, there is no easy fix

I think once (if!) the other style issues are resolved, then some more investigation can be done on this issue if required.

formatting/lists: are the correct styles included, the problem with ODT is that it "merges" the original file with what we generate

I'll take a closer look, but from my initial analysis it looked as though all styles were included correctly and the same when compared to FODT. The difference being that for ODT the styles are in a separate XML doc rather than embedded.

dagwieers commented 11 years ago

On Fri, 14 Dec 2012, SqueezeMyLemon wrote:

docdate fix: this only would work if the format of the docdate would follow the ODF standard, which is not guaranteed.

Well docdate is currently set in asciidoc.py using the date_str function. This function hardcodes the format:

return time.strftime('%Y-%m-%d',t)

So I think it is safe to use, unless asciidoc is changed to use a different format (e.g. system format etc.).

But that's not what the ODF standard accepts. According to the standard it requires a dateTime value, which is defined as:

 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime

image sizes: it is undefined how and ODF consumer should handle this, and none are doing what one would expect.

Yea seems strange to me that this basic functionality is missing from the ODT specification.

It is undefined how a consumer should behave when no dimensions, or only one dimension is provided. The standard in fact does not specify at all how consumers needs to behave or what properties are mandatory (or if absent, default to).

document title missing: for ODT files we should not make use of the meta-data (or generate the meta.xml)

Why should we not use meta.xml?

Because it is easier if we don't have to create the file. At the moment there's no easy way to do this. For FODT everything is plain simple, we generate a single file. A packaged ODT is a lot harder since asciidoc does not provide all the additional information...

That is why the title is missing, the metadata is missing. If we simply do not add it as a reference to metadata, but instead include the title as text, it would work. (We would still lack the other metadata though).

I am not that much interested in packaged ODT files, FODT works out fine. And you can use LibreOffice to make a packaged ODT out of it if you like. (using unoconv from the command line).

admonitions: the style should be constructed so that it does the right thing, there is no easy fix

I think once (if!) the other style issues are resolved, then some more investigation can be done on this issue if required.

formatting/lists: are the correct styles included, the problem with ODT is that it "merges" the original file with what we generate

I'll take a closer look, but from my initial analysis it looked as though all styles were included correctly and the same when compared to FODT. The difference being that for ODT the styles are in a separate XML doc rather than embedded.

I noticed something peculiar in LibreOffice/OpenOffice regarding the order of styles. Somehow the order is important for styles to work. I think I corrected the order of the default styles, but I may have missed a few still.

The specification does not require any specific order, so that seems to be a bug. I never reported it though.

SqueezeMyLemon commented 11 years ago

Sorry for the slow response, only just had a chance to get back to this.

But that's not what the ODF standard accepts. According to the standard it requires a dateTime value, which is defined as: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime

The fix I suggested ({docdate}T{eval:'{doctime}'[:8]}) uses {docdate} as-is and the first 8 characters of {doctime}, where:

{docdate} = time.strftime('%Y-%m-%d',t)
{doctime} = time.strftime('%H:%M:%S',t) + time.tzname

So as long as the hardcoded formats are not changed in asciidoc.py, then the result should adhere to the W3C standard.

Because it is easier if we don't have to create the file. At the moment there's no easy way to do this.

Easier isn't always better ;)

For FODT everything is plain simple, we generate a single file. A packaged ODT is a lot harder since asciidoc does not provide all the additional information..

Understood, but unfortunately FODT is not widely supported. For example, GoogleDocs & M$ Word do not support the format and OpenOffice requires a plugin/filter to open an FODT.

I am not that much interested in packaged ODT files, FODT works out fine. And you can use LibreOffice to make a packaged ODT out of it if you like. (using unoconv from the command line).

It's a shame when it is almost there straight from AsciiDoc to ODT (adding another step here seems a bit clumsy, especially when FODT/ODT are so closely related).

I noticed something peculiar in LibreOffice/OpenOffice regarding the order of styles. Somehow the order is important for styles to work. I think I corrected the order of the default styles, but I may have missed a few still. The specification does not require any specific order, so that seems to be a bug. I never reported it though.

Interesting, will take a look at that when I get a chance.

elextr commented 11 years ago

On 21 December 2012 01:37, SqueezeMyLemon notifications@github.com wrote:

Sorry for the slow response, only just had a chance to get back to this.

But that's not what the ODF standard accepts. According to the standard it requires a dateTime value, which is defined as: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime

The fix I suggested ({docdate}T{eval:'{doctime}'[:8]}) uses {docdate}as-is and the first 8 characters of {doctime}, where:

{docdate} = time.strftime('%Y-%m-%d',t) {doctime} = time.strftime('%H:%M:%S',t) + time.tzname

So as long as the hardcoded formats are not changed in asciidoc.py, then the result should adhere to the W3C standard.

Because it is easier if we don't have to create the file. At the moment there's no easy way to do this.

Easier isn't always better ;)

For FODT everything is plain simple, we generate a single file. A packaged ODT is a lot harder since asciidoc does not provide all the additional information..

Understood, but unfortunately FODT is not widely supported. For example, GoogleDocs & M$ Word do not support the format and OpenOffice requires a plugin/filter to open an FODT.

I am not that much interested in packaged ODT files, FODT works out fine. And you can use LibreOffice to make a packaged ODT out of it if you like. (using unoconv from the command line).

It's a shame when it is almost there straight from AsciiDoc to ODT (adding another step here seems a bit clumsy, especially when FODT/ODT are so closely related).

I created the first version of the ODT generating code in my spare time. I now have no time to do any more and Dag has no need of it, but contributions would be welcome.

Cheers Lex

I noticed something peculiar in LibreOffice/OpenOffice regarding the order of styles. Somehow the order is important for styles to work. I think I corrected the order of the default styles, but I may have missed a few still. The specification does not require any specific order, so that seems to be a bug. I never reported it though.

Interesting, will take a look at that when I get a chance.

— Reply to this email directly or view it on GitHubhttps://github.com/dagwieers/asciidoc-odf/issues/39#issuecomment-11575640.

dagwieers / asciidoc-odf