emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [bug] [odt] OpenDocument Text export produces corrupted files


From: Jambunathan K
Subject: Re: [O] [bug] [odt] OpenDocument Text export produces corrupted files
Date: Tue, 06 Sep 2011 22:07:22 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt)

Hello Anton

Thanks for reporting this problem and suggesting a
workaround/solution. Can tey some alternative solutions than the one
suggested in the stackoverflow thread.

Please read on.

> Hello!
>
> Org-mode produces corrupted ODT files (date format does not pass the
> validation). Details and patch:

With the development version this is what I see in my "meta.xml".
 
,----
| <dc:date>2011-09-06T20:23:59+05:30</dc:date>        
`----

and I have confirmed that there are no errors reported by the Emacs's
rng or online validators.

> stackoverflow dot
> com/questions/7299979/org-modes-odt-export-produces-corrupted-files/7304042
        
> With kindahero's hint the reason was found (odt validator):
> ,----
> | upload:///test.odt/meta.xml[13,42]:Error:"2011-09-04T16:30:23%:z" does
> | not satisfy the "dateTime" type
> `----

> %:z is a typo in defun org-odt-format-date that produces wrong meta.xml.

Atleast on my machine, I don't see %:z reproduced verbatim in the
ouptut.

I stole the "%:z" from the below thread in emacs-devel. 
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00262.html

There is a mention that "%:z" is a "GNU extension". It looks like it is
a portability issue. May I know what OS and what distribution of Emacs
you are using?

> Anyway, ODT standard requires another dateFormat:
> 2011-09-04T16:30:23.12, i.e. including milliseconds and excluding
> timezone offset.

Well, actually the milliseconds portion is optional and timezone offset
is definitely permitted.

This is what 1.1 spec says

,----
| 3.1.9 Creation Date and Time
| 
| The <meta:creation-date> element specifies the date and time when the
| document was created initially.
| 
| To conform with [xmlschema-2], the date and time format is
| YYYY-MM-DDThh:mm:ss.
| 
| 3.1.10 Modification Date and Time
| 
| The <dc:date> element specifies the date and time when the document was
| last modified.
| 
| To conform with [xmlschema-2], the date and time format is 
YYYY-MM-DDThh:mm:ss.
| 
| The name of this element was chosen for compatibility with the Dublin
| Core.
`----

,---- http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime 
|
| 3.2.7.1 Lexical representation 
|
| The ·lexical space· of dateTime consists of finite-length sequences of
| characters of the form: 
| '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?, where
|  [snip]
|
| '.' s+ (if present) represents the fractional seconds;
| zzzzzz (if present) represents the timezone (as described below).
| 
`----

> The following patch can be applied:
> ...\org\contrib\lisp\org-odt.el, line 1576 (may differ), inside defun
> org-odt-format-date (date):
>       (format-time-string "%Y-%m-%dT%T%:z")))))
> Replace with:
>       (format-time-string "%Y-%m-%dT%T.00")))))

I am able to see valid meta.xml with this change. But ...

> Well, we've lost milliseconds (they aren't documented in
> format-time-string) but passed the validation. 

Well if it is not documented then relying on it may not be a good
idea. For example, I went with "%;z" which worked for me (and may be
other users who are on GNU systems) but was broken for you.

Does replacing 

(format-time-string "%Y-%m-%dT%T%:z")

with 

  (let ((stamp (format-time-string "%Y-%m-%dT%H:%M:%S%z"))) ;; no %z here
    (format "%s:%s" (substring stamp 0 -2) (substring stamp -2)))

work for you. This is suggestion is from
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00257.html

Or 

Does replacing 

(format-time-string "%Y-%m-%dT%T%:z")

with

 (format-time-string "%Y-%m-%dT%T") ;; no %:z here

produce valid documents for you.


> Word will still be unhappy with a new file, but after the online
> validation and validation within Emacs, that's Word's problem.

:-). Well, I have no access to Word.

ps: Org permits #+DATE: declaration to contain either a user-provided
date string or a format specifier. The use of these options is not
recommended at (this point in time). For better portability, it is
better that #+DATE is not-specified at all or if it is specified, the
user has to be aware of the notes made above. There is a warning message
that org-odt.el emits if user forces a date string. I am not sure how
best this warning has attracted attention to itself.

Jambunathan K.

> Regards,
> Anton
>
>

-- 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]