* Re: [bug] [odt] OpenDocument Text export produces corrupted files
2011-09-06 11:51 [bug] [odt] OpenDocument Text export produces corrupted files Anton Tarasenko
@ 2011-09-06 16:37 ` Jambunathan K
0 siblings, 0 replies; 2+ messages in thread
From: Jambunathan K @ 2011-09-06 16:37 UTC (permalink / raw)
To: Anton Tarasenko; +Cc: emacs-orgmode
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
>
>
--
^ permalink raw reply [flat|nested] 2+ messages in thread