Blank lines in literal html

Blank lines in literal html

[Wanrong Lin]

Hi,

Sometimes I use "htmlize" to  convert  a section of my buffer into html 
and then insert it into my org file with "#+BEGIN_HTML" and 
"#+END_HTML". One thing I noticed is the blank lines in the original 
text is "amplified". For example, I have a section like this in my org file:

#+BEGIN_HTML
<pre>
Line 1

Line 2 with a blank line in between
</pre>
#+END_HTML

When I export the above to a html file, there are actaully 3 blank lines 
between my "Line 1" and "Line 2".

Is the above a bug or I mis-configured something? Thank you very much.

Wanrong

Re: Blank lines in literal html

[Wanrong Lin]

Finally, I decided to learn some elisp debugging techniques and as a 
practice, it seems I found the bug and fixed it with this patch (against 
org.el in 5.16b)

@@ -24437,7 +24437,7 @@
           (when (re-search-backward
              "\\(<p>\\)\\([ \t\r\n]*\\)\\=" (- (point) 100) t)
         (setq par (match-string 1))
-        (replace-match "\\2\n"))
+        (replace-match ""))
           (insert line "\n")
           (while (and lines
               (get-text-property 0 'org-protected (car lines)))

I am not completely sure whether this is the right fix, but so far the 
output looks OK to me.

Can Carsten take a look of it and see whether it is OK to check this 
into the next release? Thanks a lot.

Wanrong


Wanrong Lin wrote:
> Hi,
>
> Sometimes I use "htmlize" to  convert  a section of my buffer into 
> html and then insert it into my org file with "#+BEGIN_HTML" and 
> "#+END_HTML". One thing I noticed is the blank lines in the original 
> text is "amplified". For example, I have a section like this in my org 
> file:
>
> #+BEGIN_HTML
> <pre>
> Line 1
>
> Line 2 with a blank line in between
> </pre>
> #+END_HTML
>
> When I export the above to a html file, there are actaully 3 blank 
> lines between my "Line 1" and "Line 2".
>
> Is the above a bug or I mis-configured something? Thank you very much.
>
> Wanrong
>
>
>
>

Re: Re: Blank lines in literal html

[Bastien]

Hi Wanrong,

Wanrong Lin <wanrong.lin@gmail.com> writes:

> Finally, I decided to learn some elisp debugging techniques and as a
> practice, it seems I found the bug and fixed it with this patch (against
> org.el in 5.16b)
>
> @@ -24437,7 +24437,7 @@
>           (when (re-search-backward
>              "\\(<p>\\)\\([ \t\r\n]*\\)\\=" (- (point) 100) t)
>         (setq par (match-string 1))
> -        (replace-match "\\2\n"))
> +        (replace-match ""))
>           (insert line "\n")
>           (while (and lines
>               (get-text-property 0 'org-protected (car lines)))
>
> I am not completely sure whether this is the right fix, but so far the
> output looks OK to me.

Thanks for this.  I think the patch is safe (I'm testing it for two or
three days now) but I cannot predict it will be in any cases.  I guess
Carsten will have a better call on this.

(BTW, the issue your raising here concerns the way the HTML code *looks*
and IMO they are less important than issues regarding the correctness of
the HTML code... Just a thought.)

-- 
Bastien

Re: Re: Blank lines in literal html

[Wanrong Lin]

Bastien wrote:
> Hi Wanrong,
>
> Wanrong Lin <wanrong.lin@gmail.com> writes:
>
>   
>> Finally, I decided to learn some elisp debugging techniques and as a
>> practice, it seems I found the bug and fixed it with this patch (against
>> org.el in 5.16b)
>>
>> @@ -24437,7 +24437,7 @@
>>           (when (re-search-backward
>>              "\\(<p>\\)\\([ \t\r\n]*\\)\\=" (- (point) 100) t)
>>         (setq par (match-string 1))
>> -        (replace-match "\\2\n"))
>> +        (replace-match ""))
>>           (insert line "\n")
>>           (while (and lines
>>               (get-text-property 0 'org-protected (car lines)))
>>
>> I am not completely sure whether this is the right fix, but so far the
>> output looks OK to me.
>>     
>
> Thanks for this.  I think the patch is safe (I'm testing it for two or
> three days now) but I cannot predict it will be in any cases.  I guess
> Carsten will have a better call on this.
>
> (BTW, the issue your raising here concerns the way the HTML code *looks*
> and IMO they are less important than issues regarding the correctness of
> the HTML code... Just a thought.)
>
>   

Thanks for testing. Surely the No.1 priority is to have correct HTML 
syntax. But I think how the page looks comes very close as a second 
priority. After all, we use HTML because we want certain look (and 
better navigation).

Wanrong

Re: Re: Blank lines in literal html

[Bastien]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> Thanks for testing. Surely the No.1 priority is to have correct HTML
> syntax. But I think how the page looks comes very close as a second
> priority.

I'm not sure we're speaking about the same thing: I was speaking about
the HTML *source code*, not the HTML page as rendered in a browser.  I
think it's okay to be somewhat liberal about source code readability,
but not about exporting in correct HTML.

(Note that if both browsers and webpages where both implementing and
respecting W3C specs, then correct rendering and correct syntax would
always come together.)

-- 
Bastien

Re: Re: Blank lines in literal html

[Wanrong Lin]

Bastien wrote:
> Wanrong Lin <wanrong.lin@gmail.com> writes:
>
>   
>> Thanks for testing. Surely the No.1 priority is to have correct HTML
>> syntax. But I think how the page looks comes very close as a second
>> priority.
>>     
>
> I'm not sure we're speaking about the same thing: I was speaking about
> the HTML *source code*, not the HTML page as rendered in a browser.  I
> think it's okay to be somewhat liberal about source code readability,
> but not about exporting in correct HTML.
>
> (Note that if both browsers and webpages where both implementing and
> respecting W3C specs, then correct rendering and correct syntax would
> always come together.)
>
>   
Sorry, actually we were talking about different things. Maybe because we 
have different understandings of the bug itself. Just want to clarify 
the bug a little bit.

Actually, the bug is *NOT* concerned about how the HTML code looks, it 
is concerned about how the HTML page look. If I put a segment of HTML 
code in an org file that should display only one blank line, but the 
exported page displays 3 blank lines in a browser, that page has correct 
syntax but wrong content (although the rendering is still correct). 
Because the exported part is bracket in a <pre> ... </pre> section, a 
changed number of blank lines in the HTML code also changes the number 
of displayed blank lines in the browser.


 

Re: Re: Blank lines in literal html

[Bastien]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> Sorry, actually we were talking about different things. Maybe because we
> have different understandings of the bug itself. Just want to clarify
> the bug a little bit.
>
> Actually, the bug is *NOT* concerned about how the HTML code looks, it
> is concerned about how the HTML page look. If I put a segment of HTML
> code in an org file that should display only one blank line, but the
> exported page displays 3 blank lines in a browser, that page has
> correct syntax but wrong content (although the rendering is still
> correct). Because the exported part is bracket in a <pre> ... </pre>
> section, a changed number of blank lines in the HTML code also changes
> the number of displayed blank lines in the browser.

Yes, you're perfectly right.  I've submitted your patch to Carsten, I
think he will take it (or a modified version.)  Thanks again for your
report/fix!

-- 
Bastien

Re: Blank lines in literal html

[Carsten Dominik]

On Dec 5, 2007 8:31 PM, Wanrong Lin <wanrong.lin@gmail.com> wrote:
>
> Finally, I decided to learn some elisp debugging techniques and as a
> practice, it seems I found the bug and fixed it with this patch (against
> org.el in 5.16b)
>
> @@ -24437,7 +24437,7 @@
>            (when (re-search-backward
>               "\\(<p>\\)\\([ \t\r\n]*\\)\\=" (- (point) 100) t)
>          (setq par (match-string 1))
> -        (replace-match "\\2\n"))
> +        (replace-match ""))
>            (insert line "\n")
>            (while (and lines
>                (get-text-property 0 'org-protected (car lines)))
>
> I am not completely sure whether this is the right fix, but so far the
> output looks OK to me.


Hi Wanrong,

thanks for this patch - it is not the correct fix in this case, it is an issue
having to do with the fact that an empty line cannot hold text properties,
and that orgmode marks lines that are protected from processing by
putting a text property on it.  In this case, the fix is to continue the
loop looking for additional protected lines until the first non-empty,
unprotected line is found.  I am fixing this in the next release.

Bastien, thanks for your input on this as well.

- Carsten

>
> Can Carsten take a look of it and see whether it is OK to check this
> into the next release? Thanks a lot.
>
> Wanrong
>
>
>
> Wanrong Lin wrote:
> > Hi,
> >
> > Sometimes I use "htmlize" to  convert  a section of my buffer into
> > html and then insert it into my org file with "#+BEGIN_HTML" and
> > "#+END_HTML". One thing I noticed is the blank lines in the original
> > text is "amplified". For example, I have a section like this in my org
> > file:
> >
> > #+BEGIN_HTML
> > <pre>
> > Line 1
> >
> > Line 2 with a blank line in between
> > </pre>
> > #+END_HTML
> >
> > When I export the above to a html file, there are actaully 3 blank
> > lines between my "Line 1" and "Line 2".
> >
> > Is the above a bug or I mis-configured something? Thank you very much.
> >
> > Wanrong
> >
> >
> >
> >
>
>

Re: Blank lines in literal html

[Wanrong Lin]

Thanks a lot for looking at this and explaining what is the true cause. 
Look forward to the fixed version.

Wanrong

> Hi Wanrong,
>
> thanks for this patch - it is not the correct fix in this case, it is an issue
> having to do with the fact that an empty line cannot hold text properties,
> and that orgmode marks lines that are protected from processing by
> putting a text property on it.  In this case, the fix is to continue the
> loop looking for additional protected lines until the first non-empty,
> unprotected line is found.  I am fixing this in the next release.
>
> Bastien, thanks for your input on this as well.
>
> - Carsten
>
>