Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Mathias Bauer]

Hi!

I just played with org's export functionality and following
minimal org file.  This results in three minor bugs and two
proposals/questions on org's behavior.

-------------------- file1.org --------------------
#+STARTUP: showeverything
#+OPTIONS: author:nil email:nil timestamp:nil
* Some section
Some text.
* TODO Some section with a TODO keyword
Some text.
* DONE Some section with another TODO keyword
Some text.
* Some section with TAG at the end                           :some_tag:
Some text.
* TODO Some section with TODO keyword and TAG at the end  :another_tag:
Some text.
---------------------------------------------------

* ASCII/Latin-1/UTF-8 export

** Bug 1: Underlining the headlines

Headlines without tags are underlined in a wrong manner.  It's
one character too long.

** Question/Proposal

As default, all level 1 headlines are underlined by - characters
and level 2 headlines with =.  Wouldn't it be more logical the
other way round: the lower the level, the more important the
headline and hence the "bigger" its underlining?  (Of course the
user can change the variable org-export-ascii-underline.)

* HTML export

** Question/Proposal

----------snip----------
<h2>...Some section with TAG at the end &nbsp;&nbsp;&nbsp;<span class="tag"><span class="some_tag">some_tag...
----------snip----------

Isn't a single space enough for separating the heading's text and
the tag?  Beside their number, the additional three (why not five
or n?) "&nbsp;" seem a little bit freaky to me...

To keep things even more flexible, couldn't the blank and the
"&nbsp;" be skipped both and could the CSS "tag" class be
modified instead.  Unfortunately, I don't know enough of CSS yet
to check if that will be possible at all.

For the table of contents we will have a similar phenomenon if an
additional "#+OPTIONS: tags:t" is added.  The separation between
text and tag in this case consists of three "&nbsp;" and *no*
space before.

** Bug 2: Exporting the tag into the toc

Adding "#+OPTIONS: tags:t" results in the following exported toc:

----------snip----------
<li>...Some section with TAG at the end&nbsp;&nbsp;&nbsp;<span class="tag"> some_tag</span></a></li>
----------snip----------

There is a space inside the <span>...</span> just before the tag
name which should not be there.

** Bug 3: Exporting the TODO keywords

----------snip----------
<h2>...<span class="todo TODO"> TODO</span> Some section with a TODO keyword</h2>
----------snip----------

There is a space inside the <span>...</span> just before the TODO
keyword which should not be there.


Could you please consider fixing these bugs.  Thanks for this
wonderful piece of software :-)

Mathias

P.S. For proving the above topics I used the proposed minimal org
installation.  So nothing in the following settings report has
something to do with my personal configuration.  But if it's the
will of (org-submit-bug-report)... :-)

------------------------------------------------------------------------

Emacs  : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-12-11 on raven, modified by Debian
Package: Org-mode version 7.8.03

current state:
==============
(setq
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-speed-command-hook '(org-speed-command-default-hook
                          org-babel-speed-command-hook)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-export-latex-format-toc-function 'org-export-latex-format-toc-default
 org-tab-first-hook '(org-hide-block-toggle-maybe
                      org-src-native-tab-command-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
                     org-src-mode-configure-edit-buffer)
 org-confirm-shell-link-function 'yes-or-no-p
 org-export-first-hook '(org-beamer-initialize-open-trackers)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-blank-before-new-entry nil
 org-babel-pre-tangle-hook '(save-buffer)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
                  org-cycle-show-empty-lines
                  org-optimize-window-after-visibility-change)
 org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207"
                   [org-add-hook change-major-mode-hook org-show-block-all
                    append local]
                   5]
                 org-babel-hide-all-hashes)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
                          org-babel-execute-safely-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-export-interblocks '((lob org-babel-exp-lob-one-liners)
                          (src org-babel-exp-inline-src-blocks))
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-occur-hook '(org-first-headline-recenter)
 org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code)
 org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
                               org-beamer-auto-fragile-frames
                               org-beamer-place-default-actions-for-lists)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-blocks '((src org-babel-exp-src-block nil)
                     (comment org-export-blocks-format-comment t)
                     (ditaa org-export-blocks-format-ditaa nil)
                     (dot org-export-blocks-format-dot nil))
 )

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Bastien]

Hi Mathias,

Mathias Bauer <mbauer@gmx.org> writes:

> I just played with org's export functionality and following
> minimal org file.  This results in three minor bugs and two
> proposals/questions on org's behavior.

Thanks for this report -- next time, please consider sending 
one mail per bug/request, it makes issues easier to track.

> ** Bug 1: Underlining the headlines
>
> Headlines without tags are underlined in a wrong manner.  It's
> one character too long.

It's a matter of taste.  I like this additionnal character 
and I think Carsten added it intentionally.

> ** Question/Proposal
>
> As default, all level 1 headlines are underlined by - characters
> and level 2 headlines with =.  Wouldn't it be more logical the
> other way round: the lower the level, the more important the
> headline and hence the "bigger" its underlining?  (Of course the
> user can change the variable org-export-ascii-underline.)

Unless many users think this is illogical, I won't change the 
default.

> * HTML export
>
> ** Question/Proposal
>
> ----------snip----------
> <h2>...Some section with TAG at the end &nbsp;&nbsp;&nbsp;<span class="tag"><span class="some_tag">some_tag...
> ----------snip----------
>
> Isn't a single space enough for separating the heading's text and
> the tag?  Beside their number, the additional three (why not five
> or n?) "&nbsp;" seem a little bit freaky to me...

They _are_ freaky :)  But they are also needed.  

Even if the tags display is taken care of by the CSS, 
we must prevent collapsing the tags with the previous 
strings in case the CSS is not available -- just think
of what the HTML page should look like with w3m/lynx.

> ** Bug 2: Exporting the tag into the toc
>
> Adding "#+OPTIONS: tags:t" results in the following exported toc:
>
> ----------snip----------
> <li>...Some section with TAG at the end&nbsp;&nbsp;&nbsp;<span class="tag"> some_tag</span></a></li>
> ----------snip----------
>
> There is a space inside the <span>...</span> just before the tag
> name which should not be there.

Fixed, thanks.

> ** Bug 3: Exporting the TODO keywords
>
> ----------snip----------
> <h2>...<span class="todo TODO"> TODO</span> Some section with a TODO keyword</h2>
> ----------snip----------
>
> There is a space inside the <span>...</span> just before the TODO
> keyword which should not be there.

Fixed, thanks.

-- 
 Bastien

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Mathias Bauer]

Hi Bastien,

* Bastien wrote on 2012-03-09 at 03:09 (+0100):

> Mathias Bauer <mbauer@gmx.org> writes:
>
> Thanks for this report -- next time, please consider sending
> one mail per bug/request, it makes issues easier to track.

ok, I'll do so - even for small bugs.  Promised :-)

> > Headlines without tags are underlined in a wrong manner.
> > It's one character too long.
>
> It's a matter of taste.  I like this additionnal character and
> I think Carsten added it intentionally.

Hm, yes it is.  I just wondered because the strings of the title
and the toc headline have a different underlining.

> > ----------snip----------
> > <h2>...Some section with TAG at the end &nbsp;&nbsp;&nbsp;<span class="tag"><span class="some_tag">some_tag...
> > ----------snip----------
> >
> > Isn't a single space enough for separating the heading's text
> > and the tag?  Beside their number, the additional three (why
> > not five or n?) "&nbsp;" seem a little bit freaky to me...
>
> They _are_ freaky :)  But they are also needed.
>
> Even if the tags display is taken care of by the CSS, we must
> prevent collapsing the tags with the previous strings in case
> the CSS is not available -- just think of what the HTML page
> should look like with w3m/lynx.

Thanks for your explanation.  I completely missed text based
browsers.  And ordinary spaces are _really_ not enough for them?
Concerning CSS I'm digging into the docs ... but tomorrow :-)

Regards,
Mathias

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Sebastien Vauban]

Hi Bastien and Mathias,

Bastien wrote:
>> As default, all level 1 headlines are underlined by - characters and level
>> 2 headlines with =. Wouldn't it be more logical the other way round: the
>> lower the level, the more important the headline and hence the "bigger" its
>> underlining? (Of course the user can change the variable
>> org-export-ascii-underline.)
>
> Unless many users think this is illogical, I won't change the default.

To be honest, fixing this was on my (huge) todo list: I've always found it
disturbing to have more imposing level-2 titles than the level-1 titles.

For me, it makes a lot of sense to invert both, as Mathias is suggesting it.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Gustav Wikström]

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

>
>
>
> For me, it makes a lot of sense to invert both, as Mathias is suggesting
> it.
>
>
+1

It would conform more to a sort of "standard" that way, (see
http://en.wikipedia.org/wiki/Lightweight_markup_language#Section_headers)


> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>
/Gustav

[-- Attachment #2: Type: text/html, Size: 833 bytes --]

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Gregor Zattler]

Hi Gustav,
* Gustav Wikström <gustav.erik@gmail.com> [09. Mar. 2012]:
>> For me, it makes a lot of sense to invert both, as Mathias is suggesting
>> it.
>>
> +1
+1
 
> It would conform more to a sort of "standard" that way, (see
> http://en.wikipedia.org/wiki/Lightweight_markup_language#Section_headers)

We did it this way on mechanical typewriters.

Fred Flintstone

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Ivy Foster]

On 09 Mar 2012, at  3:09 am +0100, Bastien wrote:
> Mathias Bauer <mbauer@gmx.org> writes:
> > As default, all level 1 headlines are underlined by -
> > characters and level 2 headlines with =. Wouldn't it be
> > more logical the other way round

> Unless many users think this is illogical, I won't change
> the default.

Personally, I tend to agree with Mathias here. Maybe it's
just because I like Markdown, but the `=' underline just
feels like stronger emphasis to me. (Of course, I keep
meaning to write a Markdown exporter, but also keep putting
it off, so there you go.)

Ivy

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Carsten Dominik]

On 9.3.2012, at 11:12, Sebastien Vauban wrote:

> Hi Bastien and Mathias,
> 
> Bastien wrote:
>>> As default, all level 1 headlines are underlined by - characters and level
>>> 2 headlines with =. Wouldn't it be more logical the other way round: the
>>> lower the level, the more important the headline and hence the "bigger" its
>>> underlining? (Of course the user can change the variable
>>> org-export-ascii-underline.)
>> 
>> Unless many users think this is illogical, I won't change the default.
> 
> To be honest, fixing this was on my (huge) todo list: I've always found it
> disturbing to have more imposing level-2 titles than the level-1 titles.
> 
> For me, it makes a lot of sense to invert both, as Mathias is suggesting it.

For what it is worth, I do agree that this looks wrong now and changing
it would make it better.  I do not remember why I chose the sequence
that we have now.  Looking at it now, I would also insert ....... after
^^^^^^, and hope that ##### and $$$$$ never get any use :)

Also I do not remember to consciously make the underlining one
character too long.... but I also agree with Bastien that it
does not look bad.  Maybe another variable.....

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> For what it is worth, I do agree that this looks wrong now and changing
> it would make it better.  I do not remember why I chose the sequence
> that we have now.  Looking at it now, I would also insert ....... after
> ^^^^^^, and hope that ##### and $$$$$ never get any use :)

For the record, `e-ascii' back-end currently uses the following default
set-up:

#+begin_src emacs-lisp
(defcustom org-e-ascii-underline '((ascii ?= ?~ ?-)
				   (latin1 ?= ?~ ?-)
				   (utf-8 ?═ ?─ ?╌ ?┄ ?┈))
  "Characters for underlining headings in ASCII export.

Alist whose key is a symbol among `ascii', `latin1' and `utf-8'
and whose value is a list of characters.

For each supported charset, this variable associates a sequence
of underline characters.  In a sequence, the characters will be
used in order for headlines level 1, 2, ...  If no character is
available for a given level, the headline won't be underlined."
  :group 'org-export-e-ascii
  :type '(list
	  (cons :tag "Underline characters sequence"
		(const :tag "ASCII charset" ascii)
		(repeat character))
	  (cons :tag "Underline characters sequence"
		(const :tag "Latin-1 charset" latin1)
		(repeat character))
	  (cons :tag "Underline characters sequence"
		(const :tag "UTF-8 charset" utf-8)
		(repeat character))))
#+end_src

IMO, ...., ^^^^^, #####, $$$$$$ are just ugly and should require user's
approval (i.e. customization).


Regards,

-- 
Nicolas Goaziou

Re: Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Bastien]

Ivy Foster <joyfulgirl@archlinux.us> writes:

> On 09 Mar 2012, at  3:09 am +0100, Bastien wrote:
>> Mathias Bauer <mbauer@gmx.org> writes:
>> > As default, all level 1 headlines are underlined by -
>> > characters and level 2 headlines with =. Wouldn't it be
>> > more logical the other way round
>
>> Unless many users think this is illogical, I won't change
>> the default.
>
> Personally, I tend to agree with Mathias here. Maybe it's
> just because I like Markdown, but the `=' underline just
> feels like stronger emphasis to me. (Of course, I keep
> meaning to write a Markdown exporter, but also keep putting
> it off, so there you go.)

This is what is now in the master branch (org-ascii.el):

(defcustom org-export-ascii-underline '(?\= ?\- ?\~ ?\^ ?\. ?\# ?\$)

Thanks to all for the feedback, and to Mathias for the initial 
suggestion!

-- 
 Bastien