[bug] org-inlinetask produces invalid xhtml

[bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]


Summary: org-inlinetask produces invalid xhtml

The org file and exported html files are included. Org file also
contains some annotation on the bug.

Food for thought: If inline task entry is seen as a regular "body text"
even though it is wrapped in to "<pre> </pre>" element does that suggest
a possible way in which this bug could be fixed.


[-- Attachment #2: odt-export-bug.org --]
[-- Type: text/plain, Size: 693 bytes --]

* B oscillations
This is Suvayu's example but simplified. Also see the annotation
within the inline task itself.

_Questions_:
*************** Detector effects					 :Qn:

Suvayu's example uses lists within inline task. Can the html export
engine produce valid html when the inline task has lists. But honestly
why does a preformatted text looks like a well-formatted html
list. Isn't that strange. Just uncomment the below list and see for
yourself.

# 1. How is the Gaussian used for smearing of proper time resolution
#    derived? [[http://www.google.com][Google]] this.
# 2. Why is the proper time error PDF needed? Why is
#    smearing of time resolution not enough?
*************** END


[-- Attachment #3: odt-export-bug.html --]
[-- Type: text/html, Size: 3678 bytes --]

[-- Attachment #4: Type: text/plain, Size: 5 bytes --]


-- 

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

Nicolas,

> Summary: org-inlinetask produces invalid xhtml
>
> The org file and exported html files are included. Org file also
> contains some annotation on the bug.
>
> Food for thought: If inline task entry is seen as a regular "body text"
> even though it is wrapped in to "<pre> </pre>" element does that suggest
> a possible way in which this bug could be fixed.

Do you want to take a stab at this bug?

Having a valid html is in some sense necessary for producing for valid
odt output ...

Additional Note: I think instead of having templates one could have
org-<backend>-format-inlinetask(heading task todo priority whatever)

Jambunathan K.
-- 

Re: [bug] org-inlinetask produces invalid xhtml

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

>> Summary: org-inlinetask produces invalid xhtml

I've pushed a fix. Is it correct now?

> Additional Note: I think instead of having templates one could have
> org-<backend>-format-inlinetask(heading task todo priority whatever)

Not as long as org-inlinetask isn't loaded by default: it should be as
little intrusive as possible. But once it happens, I agree it could be
the path to go.

Regards,

-- 
Nicolas Goaziou

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>>> Summary: org-inlinetask produces invalid xhtml
>
> I've pushed a fix. Is it correct now?

The problem persists. You can put the exported html file in nxml-mode
and do a C-c C-n to find the validation errors.

I am attaching the two examples and the problematic html segment (marked
with VALIDATION ERROR) here. Note that one of the examples has a list in
the inline task.



[-- Attachment #2: odt-export-bug.org --]
[-- Type: text/plain, Size: 404 bytes --]

* B oscillations
This is Suvayu's example but simplified. Also see the annotation
within the inline task itself.

_Questions_:
*************** Detector effects					 :Qn:
1. How is the Gaussian used for smearing of proper time resolution
   derived? [[http://www.google.com][Google]] this.
2. Why is the proper time error PDF needed? Why is
   smearing of time resolution not enough?
*************** END


[-- Attachment #3: Type: text/plain, Size: 405 bytes --]



#+begin_src nxml
<pre class="inlinetask"><b>Detector effects</b><br />
<ol> <!-- VALIDATION ERROR HERE: Element not allowed in this context -->
  <li>How is the Gaussian used for smearing of proper time resolution
  derived? <a href="http://www.google.com">Google</a> this.
  </li>
  <li>Why is the proper time error PDF needed? Why is
  smearing of time resolution not enough?
  </li>
</ol>
#+end_src


[-- Attachment #4: odt-export-bug1.org --]
[-- Type: text/plain, Size: 470 bytes --]

* B oscillations
This is Suvayu's example but simplified. Also see the annotation
within the inline task itself.

_Questions_:
*************** Detector effects					 :Qn:
Suvayu's example uses lists within inline task. Can the html export
engine produce valid html when the inline task has lists. But honestly
why does a preformatted text looks like a well-formatted html
list. Isn't that strange. Just uncomment the below list and see for
yourself.
*************** END


[-- Attachment #5: Type: text/plain, Size: 968 bytes --]


#+begin_src nxml
<div id="outline-container-1" class="outline-2">
  <h2 id="sec-1"><span class="section-number-2">1</span> B oscillations </h2>
  <div class="outline-text-2" id="text-1">

    <p>This is Suvayu's example but simplified. Also see the annotation
    within the inline task itself.
    </p>
    <p>
      <span style="text-decoration:underline;">Questions</span>:
    </p>


    <pre class="inlinetask"><b>Detector effects</b><br />
    <p> <!-- VALIDATION ERROR: Element not allowed in this context -->
      Suvayu's example uses lists within inline task. Can the html export
      engine produce valid html when the inline task has lists. But honestly
      why does a preformatted text looks like a well-formatted html
      list. Isn't that strange. Just uncomment the below list and see for
      yourself.
    </pre> <!-- VALIDATION ERROR: Missing end-tag "p" -->

  </p></div> <!-- VALIDATION ERROR: Mismatched end-tag -->
</div>
#+end_src


-- 

Re: [bug] org-inlinetask produces invalid xhtml

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> The problem persists. You can put the exported html file in nxml-mode
> and do a C-c C-n to find the validation errors.

The problem is different now.

> I am attaching the two examples and the problematic html segment (marked
> with VALIDATION ERROR) here. Note that one of the examples has a list in
> the inline task.
>
>
>
> #+begin_src nxml
> <pre class="inlinetask"><b>Detector effects</b><br />
> <ol> <!-- VALIDATION ERROR HERE: Element not allowed in this context -->
>   <li>How is the Gaussian used for smearing of proper time resolution
>   derived? <a href="http://www.google.com">Google</a> this.
>   </li>
>   <li>Why is the proper time error PDF needed? Why is
>   smearing of time resolution not enough?
>   </li>
> </ol>
> #+end_src
>
> #+begin_src nxml
> <div id="outline-container-1" class="outline-2">
>   <h2 id="sec-1"><span class="section-number-2">1</span> B oscillations </h2>
>   <div class="outline-text-2" id="text-1">
>
>     <p>This is Suvayu's example but simplified. Also see the annotation
>     within the inline task itself.
>     </p>
>     <p>
>       <span style="text-decoration:underline;">Questions</span>:
>     </p>
>
>
>     <pre class="inlinetask"><b>Detector effects</b><br />
>     <p> <!-- VALIDATION ERROR: Element not allowed in this context -->
>       Suvayu's example uses lists within inline task. Can the html export
>       engine produce valid html when the inline task has lists. But honestly
>       why does a preformatted text looks like a well-formatted html
>       list. Isn't that strange. Just uncomment the below list and see for
>       yourself.
>     </pre> <!-- VALIDATION ERROR: Missing end-tag "p" -->
>
>   </p></div> <!-- VALIDATION ERROR: Mismatched end-tag -->
> </div>
> #+end_src

I see. Contents of inline tasks are meant to be interpreted during
export. Thus, paragraphs will be marked as <p>, lists as <ul> or
whatever...

This isn't compatible with the default <pre> tag provided. I can see two
possibilities. Come up with a better default value, or provide a way to
tell to template that contents will be verbatim (or both).

I prefer the first solution, but I can't think of something simple, yet
elegant enough, for that value. Do you have any suggestion?

Regards,

-- 
Nicolas Goaziou

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

> I see. Contents of inline tasks are meant to be interpreted during
> export. Thus, paragraphs will be marked as <p>, lists as <ul> or
> whatever...
>
> This isn't compatible with the default <pre> tag provided. I can see two
> possibilities. Come up with a better default value, or provide a way to
> tell to template that contents will be verbatim (or both).
>
> I prefer the first solution, but I can't think of something simple, yet
> elegant enough, for that value. Do you have any suggestion?

(I am speaking here from purely html/odt perspective)

1. When org-inlinetask is NOT LOADED, inline tasks are treated as
   regular headlines and are listified. (The "END" of inlinetask appears
   as listified headline though)

2. If inlinetask is LOADED, the exporter could check the headline level
   against org-inlinetask-min-level and take the following actions:

   - Continue to generate listified entries for inline tasks but
     surround them with <div class="inlinetask"> ... </div> entries.

   - Strip the "END" list item from being generated

I think org-inlinetask-export-handler could be reduced to 
1. removing the inlinetask when org-inlinetask-export is nil
2. stripping the inlinetask of drawers etc etc.

(Queestions: Does the org-inlinetask-export-handler treat nested inline
tasks well? Btw, Is nesting of inline tasks "legitimate" to begin with?
) 

I am sure html and odt exporters can take care of inlinetask purely
during post-processing and do away with templates altogether. I am not
sure about LaTeX exporter though.

What do you & others think? Let me work on a patch from odt/html side of
things.


Misc:

1. May be someone with css/html expertise can devise a nice css for
   formatting of inlinetasks as part of addressig this bug. 

2. I am undecided about how odt export be formatted - comments, text
   boxes, what else. In case of odt export, there is an option of always
   exporting the inline task but turn on/off their display conditionally
   based on user setting.

> Regards,

-- 

Re: [bug] org-inlinetask produces invalid xhtml

[suvayu ali]

Hello Nicolas and Jambu,

On Tue, Aug 9, 2011 at 11:51 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
>> I see. Contents of inline tasks are meant to be interpreted during
>> export. Thus, paragraphs will be marked as <p>, lists as <ul> or
>> whatever...
>>
>> This isn't compatible with the default <pre> tag provided. I can see two
>> possibilities. Come up with a better default value, or provide a way to
>> tell to template that contents will be verbatim (or both).
>>
>> I prefer the first solution, but I can't think of something simple, yet
>> elegant enough, for that value. Do you have any suggestion?
>
> (I am speaking here from purely html/odt perspective)
>
> 1. When org-inlinetask is NOT LOADED, inline tasks are treated as
>   regular headlines and are listified. (The "END" of inlinetask appears
>   as listified headline though)
>
> 2. If inlinetask is LOADED, the exporter could check the headline level
>   against org-inlinetask-min-level and take the following actions:
>
>   - Continue to generate listified entries for inline tasks but
>     surround them with <div class="inlinetask"> ... </div> entries.
>
>   - Strip the "END" list item from being generated

I don't know much html/css but lately I have been fooling around with
export of inlinetasks. I found that for html export having them as a
section with highlighting seemed to serve my purpose well. It seems to
me inline tasks are either used as task reminders in the context of a
larger document or as contextual notes. For either case, it serves the
purpose better if its highlighted or quoted in some coloured box or
something similar.

To achieve this, I modified the default templates for html and latex
export like this:


(html "<div class=\"%s\"><b>%s%s</b><br />%s</div>"
      '("inlinetask"
	(unless
	    (eq todo "")
	  (format "<span class=\"%s %s\">%s%s</span> " class todo todo priority))
	heading content))

;; this requires the todonotes package
(latex "\\todo[inline]{\\textbf{%s %s}\\linebreak{} %s}"
       '((unless
	     (eq todo "")
	   (format "\\textsc{%s%s}" todo priority))
	 heading content))


For html export with the above template one could control the styling by
defining the div.inlinetask class in their custom.css.

To have more control over the styling using multiple css classes, I
tried using HTML_CONTAINER_CLASS with an inline task and altering the
html template to something like this:


(html "<div class=\"%s\"><b>%s%s</b><br />%s</div>"
      '((org-entry-get nil "HTML_CONTAINER_CLASS")
	(unless
	    (eq todo "")
	  (format "<span class=\"%s %s\">%s%s</span> " class todo todo priority))
	heading content))


But that doesn't seem to work at all! I get no errors, just the
inlinetask gets exported with an empty class like this:


<div class=""> ... </div>


Strangely, if I replace the (org-entry-get ..) with (message "bla"), the
exported markup looks something like this:


<div class="bla"> ... </div>


I hope this gives you ideas or scope for improvement for export of
inlinetasks.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [bug] org-inlinetask produces invalid xhtml

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> 1. When org-inlinetask is NOT LOADED, inline tasks are treated as
>    regular headlines and are listified. (The "END" of inlinetask appears
>    as listified headline though)

Loading org-inlinetask is the user's job. He has to assume weird things
which will happen when the buffer holds inline tasks without them being
loaded (but I give him an excuse as inline tasks are completely
undocumented).

> 2. If inlinetask is LOADED, the exporter could check the headline level
>    against org-inlinetask-min-level and take the following actions:
>
>    - Continue to generate listified entries for inline tasks but
>      surround them with <div class="inlinetask"> ... </div> entries.
>
>    - Strip the "END" list item from being generated
>
> I think org-inlinetask-export-handler could be reduced to 
> 1. removing the inlinetask when org-inlinetask-export is nil
> 2. stripping the inlinetask of drawers etc etc.
>
> (Queestions: Does the org-inlinetask-export-handler treat nested
> inline tasks well? Btw, Is nesting of inline tasks "legitimate" to
> begin with? )

As far as I can tell, inline tasks are not designed to be nested.

> I am sure html and odt exporters can take care of inlinetask purely
> during post-processing and do away with templates altogether.

Templates are fine as long as inline tasks are not loaded by default. If
this changes, I agree there are better ways to handle them (one being
what you explain above).

But, a few weeks ago, Bastien suggested to think again inline tasks. So,
that might not happen soon.

> I am not sure about LaTeX exporter though.
>
> What do you & others think? Let me work on a patch from odt/html side of
> things.

What I think is that, for now, we just should keep the existing facility
and implement a working default template for HTML (and a new one for
ODT).


Regards,

-- 
Nicolas Goaziou

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

Nicolas

(Sent my mail too early. Resending with additions)

> As far as I can tell, inline tasks are not designed to be nested.

May be C-c C-x t should throw an error and enforce this.

If inlinetasks cannot be nested, may I know how one would use
org-inlinetask-promote and org-inlinetask-demote.

I understand that it's presence implies that even though inlinetasks
cannot be nested they could occur at various levels implying that inline
task deeper than a certain level are treated differently than
others. Does Org provide a way to NOT export trees deeper than a certain
level?

Jambunathan K.

Re: [bug] org-inlinetask produces invalid xhtml

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

>> As far as I can tell, inline tasks are not designed to be nested.
>
> May be C-c C-x t should throw an error and enforce this.

Done.

> If inlinetasks cannot be nested, may I know how one would use
> org-inlinetask-promote and org-inlinetask-demote.
>
> I understand that it's presence implies that even though inlinetasks
> cannot be nested they could occur at various levels

Indeed.

> implying that inline task deeper than a certain level are treated
> differently than others.

I fear that exporters are not aware about this implication.

The templates may support a `relative-level' keyword. An inline task at
`org-inlinetask-min-level' would set it at 0 and so on.

> Does Org provide a way to NOT export trees deeper than a certain
> level?

I don't think so, though you can remove them via a hook just before
export.


Regards,

-- 
Nicolas Goaziou

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

Nicolas

> As far as I can tell, inline tasks are not designed to be nested.

May be C-c C-x t should throw an error and enforce this.

If inlinetasks cannot be nested, may I know why one would do a applying
org-inlinetask-promote and org-inlinetask-demote.

Jambunathan K.

Re: [bug] org-inlinetask produces invalid xhtml

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]


> What I think is that, for now, we just should keep the existing facility
> and implement a working default template for HTML (and a new one for
> ODT).

I am attaching the patch and sample org/odt/doc/html files.

I have used the css style suggested by Suvayu Ali for inlinetask (but
with an yellow background). I have used text boxes for odt export [1].

Jambuanthan K.

Footnotes: 

[1] Initially I wanted to use Comments/Annotations for inlinetasks but
thanks to Suvayu's notings I have changed my mind.

1. It shows up in margin which has limited space. So the inline tasks
   have to be really small for pretty output.
2. Even though the spec says that <office:annotation>
   ... </office:annotation> can contain lists, LibreOffice render them
   lists/list-items as insipid paragraphs.
3. Body text in office annotations doesn't honor custom styles. It
   honors only automatic styles. (This seems more like a LibreOffice
   issue)

[2] Note that one can navigate just the Text Frames from within
LibreOffice UI and also create an index entry for it.


[-- Attachment #2: 0001-Prettify-inlinetasks-in-odt-and-x-html-backends.patch --]
[-- Type: text/plain, Size: 7700 bytes --]

From 6bbf2084d783726e05a2e006ea2f79017adf50d9 Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Fri, 12 Aug 2011 01:37:45 +0530
Subject: [PATCH] Prettify inlinetasks in odt and (x)html backends

* lisp/org-inlinetask.el (org-inlinetask-export-templates):
Fixed template for html so that the exported file is valid
xhtml. Added template for odt.
(org-inlinetask-export-handler): Fix typo in the regexp that
trims content. Make sure that the content is flanked by
paragraph boundaries on either side.

* lisp/org-html.el (org-export-html-style-default): Add style
for inlinetask.

* contrib/lisp/org-xhtml.el (org-export-xhtml-style-default):
Add style for inlinetask.

* contrib/odt/styles/OrgOdtStyles.xml: Added following custom
styles:  OrgInlineTaskHeading and OrgInlineTaskFrame.

* contrib/lisp/org-odt.el (org-odt-format-textbox)
(org-odt-format-inlinetask): Added

Refer following threads:
1. http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00238.html
2. http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00154.html

Thanks to Suvayu Ali for reporting this issue and suggesting
improvements.
---
 contrib/lisp/org-odt.el             |   22 ++++++++++++++++++++++
 contrib/lisp/org-xhtml.el           |    6 ++++++
 contrib/odt/styles/OrgOdtStyles.xml |   11 +++++++++++
 lisp/org-html.el                    |    6 ++++++
 lisp/org-inlinetask.el              |   15 ++++++++++-----
 5 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/contrib/lisp/org-odt.el b/contrib/lisp/org-odt.el
index 88d1068..848bba3 100644
--- a/contrib/lisp/org-odt.el
+++ b/contrib/lisp/org-odt.el
@@ -1077,6 +1077,28 @@ MAY-INLINE-P allows inlining it as an image."
 
       (org-export-odt-do-format-image embed-as caption attr label
 				       size href))))
+(defun org-odt-format-textbox (text style)
+  (let ((draw-frame-pair
+	 '("<draw:frame draw:style-name=\"%s\"
+              text:anchor-type=\"paragraph\"
+              style:rel-width=\"100%%\"
+              draw:z-index=\"0\">" . "</draw:frame>")))
+    (org-odt-format-tags
+     draw-frame-pair
+     (org-odt-format-tags
+      '("<draw:text-box fo:min-height=\"%dcm\">" . "</draw:text-box>")
+      text 0) style)))
+
+(defun org-odt-format-inlinetask (heading content
+					  &optional todo priority tags)
+  (org-odt-format-stylized-paragraph
+   nil (org-odt-format-textbox
+	(concat (org-odt-format-stylized-paragraph
+		 "OrgInlineTaskHeading"
+		 (org-lparse-format
+		  'HEADLINE (concat (org-lparse-format-todo todo) " " heading)
+		  nil tags))
+		content) "OrgInlineTaskFrame")))
 
 (defun org-export-odt-do-format-image (embed-as caption attr label
 						size href)
diff --git a/contrib/lisp/org-xhtml.el b/contrib/lisp/org-xhtml.el
index 74ad64b..8a4a01f 100644
--- a/contrib/lisp/org-xhtml.el
+++ b/contrib/lisp/org-xhtml.el
@@ -166,6 +166,12 @@ not be modified."
   dt { font-weight: bold; }
   div.figure { padding: 0.5em; }
   div.figure p { text-align: center; }
+  div.inlinetask {
+    padding:10px;
+    border:2px solid gray;
+    margin:10px;
+    background: #ffffcc;
+  }
   textarea { overflow-x: auto; }
   .linenr { font-size:smaller }
   .code-highlighted {background-color:#ffff00;}
diff --git a/contrib/odt/styles/OrgOdtStyles.xml b/contrib/odt/styles/OrgOdtStyles.xml
index d7ec5ee..317a234 100644
--- a/contrib/odt/styles/OrgOdtStyles.xml
+++ b/contrib/odt/styles/OrgOdtStyles.xml
@@ -359,6 +359,17 @@
   <style:style style:name="Frame" style:family="graphic">
    <style:graphic-properties text:anchor-type="paragraph" svg:x="0cm" svg:y="0cm" fo:margin-left="0.201cm" fo:margin-right="0.201cm" fo:margin-top="0.201cm" fo:margin-bottom="0.201cm" style:wrap="parallel" style:number-wrapped-paragraphs="no-limit" style:wrap-contour="false" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="center" style:horizontal-rel="paragraph-content" fo:padding="0.15cm" fo:border="0.002cm solid #000000"/>
   </style:style>
+
+  <!-- Inline Tasks -->
+  <style:style style:name="OrgInlineTaskHeading" style:family="paragraph" style:parent-style-name="Caption" style:next-style-name="Text_20_body">
+   <style:text-properties style:font-name="Arial1" fo:font-style="normal" fo:font-weight="bold"/>
+  </style:style>
+  <style:style style:name="OrgInlineTaskFrame" style:family="graphic" style:parent-style-name="Frame">
+   <style:graphic-properties svg:x="0cm" svg:y="0cm" style:wrap="none" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="center" style:horizontal-rel="paragraph-content" fo:background-color="#ffffcc" style:background-transparency="0%" fo:padding="0.15cm" fo:border="0.26pt solid #000000" style:shadow="none">
+    <style:background-image/>
+   </style:graphic-properties>
+  </style:style>
+
   <text:list-style style:name="Numbering_20_1" style:display-name="Numbering 1">
    <text:list-level-style-number text:level="1" text:style-name="Numbering_20_Symbols" style:num-suffix="." style:num-format="1">
     <style:list-level-properties text:list-level-position-and-space-mode="label-alignment">
diff --git a/lisp/org-html.el b/lisp/org-html.el
index c150b3d..bc45d73 100644
--- a/lisp/org-html.el
+++ b/lisp/org-html.el
@@ -158,6 +158,12 @@ not be modified."
   dt { font-weight: bold; }
   div.figure { padding: 0.5em; }
   div.figure p { text-align: center; }
+  div.inlinetask {
+    padding:10px;
+    border:2px solid gray;
+    margin:10px;
+    background: #ffffcc;
+  }
   textarea { overflow-x: auto; }
   .linenr { font-size:smaller }
   .code-highlighted {background-color:#ffff00;}
diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index 57ab505..0eb7361 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -107,11 +107,14 @@ When nil, they will not be exported."
   :type 'boolean)
 
 (defvar org-inlinetask-export-templates
-  '((html "<pre class=\"inlinetask\"><b>%s%s</b><br />%s</pre>"
+  '((html "<div class=\"inlinetask\"><b>%s%s</b><br />%s</div>"
 	  '((unless (eq todo "")
 	      (format "<span class=\"%s %s\">%s%s</span> "
 		      class todo todo priority))
 	    heading content))
+    (odt "%s" '((org-odt-format-inlinetask heading content
+					   todo priority tags)))
+
     (latex "\\begin\{description\}\n\\item[%s%s]~%s\\end\{description\}"
 	   '((unless (eq todo "") (format "\\textsc\{%s%s\} " todo priority))
 	     heading content))
@@ -349,12 +352,14 @@ Either remove headline and meta data, or do special formatting."
 		;; Ensure CONTENT has minimal indentation, a single
 		;; newline character at its boundaries, and isn't
 		;; protected.
-		(when (string-match "`\\([ \t]*\n\\)+" content)
+		(when (string-match "\\`\\([ \t]*\n\\)+" content)
 		  (setq content (substring content (match-end 0))))
 		(when (string-match "[ \t\n]+\\'" content)
 		  (setq content (substring content 0 (match-beginning 0))))
-		(org-add-props (concat "\n" (org-remove-indentation content) "\n")
-		    '(org-protected nil))))
+		(org-add-props
+		    (concat "\n\n" (org-remove-indentation content) "\n\n")
+		    '(org-protected nil org-native-text nil))))
+
 	(when (string-match org-complex-heading-regexp headline)
 	  (let* ((nil-to-str
 		  (function
@@ -371,7 +376,7 @@ Either remove headline and meta data, or do special formatting."
 		 (backend-spec (assq org-export-current-backend
 				     org-inlinetask-export-templates))
 		 (format-str (org-add-props (nth 1 backend-spec)
-				 '(org-protected t)))
+				 '(org-protected t org-native-text t)))
 		 (tokens (cadr (nth 2 backend-spec)))
 		 ;; Build export string. Ensure it won't break
 		 ;; surrounding lists by giving it arbitrary high
-- 
1.7.2.3


[-- Attachment #3: inlinetask.org --]
[-- Type: text/plain, Size: 1022 bytes --]

* TODO [#A] A regular todo					     :boring:
  This is a regular todo.

*  Some topic							   :colorful:
blah blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah
*************** TODO [#B] A simple inline task:			     :simple:
continue blah continue blah continue blah continue blah continue blah
continue blah continue blah continue blah continue blah continue blah
continue blah continue blah continue blah continue blah continue blah
continue blah

*************** TODO [#C] An inline task with extra notes	   :detailed:
1. note1 note1 note1 note1 note1 note1 note1 note1 note1 note1 note1
   note1 note1 note1
2. note2 note2 note2 note2 note2 note2 note2 note2 note2 note2 note2
   note2 note2
*************** END
again continue blah again continue blah again continue blah again
continue blah again continue blah again continue blah again continue
blah again continue blah again continue blah again continue blah again
continue blah again continue blah


[-- Attachment #4: inlinetask.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 8785 bytes --]

[-- Attachment #5: inlinetask.doc --]
[-- Type: application/msword, Size: 20480 bytes --]

[-- Attachment #6: inlinetask.html --]
[-- Type: text/html, Size: 4871 bytes --]

[-- Attachment #7: Type: text/plain, Size: 23 bytes --]




















-- 

Re: [bug] org-inlinetask produces invalid xhtml

[Bastien]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> I am attaching the patch and sample org/odt/doc/html files.

Applied, thanks a lot!

-- 
 Bastien

Re: [bug] org-inlinetask produces invalid xhtml

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Loading org-inlinetask is the user's job. He has to assume weird things
> which will happen when the buffer holds inline tasks without them being
> loaded (but I give him an excuse as inline tasks are completely
> undocumented).

We should fix this -- anyone willing to put a stab at this?

Thanks!

-- 
 Bastien