XHTML export - customizing via local variables

XHTML export - customizing via local variables

[Adam Spiers]

Is org-export-html-style the only aspect of XHTML export which can be
customized via Local Variables?  It would be nice to be able to
override org-export-html-table-tag per-file, for instance, but it
didn't work for me and I wasn't clever enough to figure out how the
code works from a quick glance.  Thanks!

Re: XHTML export -   etc.

[Adam Spiers]

Another XHTML export question - is it possible to export special
symbols such as " " ?  If not, perhaps the @ syntax could be
extended from simple tags to these too, i.e. "@ " ?

Thanks!

Re: XHTML export -   etc.

[Bastien]

Adam Spiers <orgmode@adamspiers.org> writes:

> Another XHTML export question - is it possible to export special
> symbols such as "&nbsp;" ?  If not, perhaps the @ syntax could be
> extended from simple tags to these too, i.e. "@&nbsp;" ?

Have a look at `org-html-entities'.

You can use \nbsp in Org source file, it'll be converted to &nbsp;
smoothly.

-- 
Bastien

Re: XHTML export -   etc.

[Adam Spiers]

On Fri, Nov 02, 2007 at 03:26:19PM +0000, Bastien wrote:
> Adam Spiers <orgmode@adamspiers.org> writes:
> 
> > Another XHTML export question - is it possible to export special
> > symbols such as "&nbsp;" ?  If not, perhaps the @ syntax could be
> > extended from simple tags to these too, i.e. "@&nbsp;" ?
> 
> Have a look at `org-html-entities'.
> 
> You can use \nbsp in Org source file, it'll be converted to &nbsp;
> smoothly.

Perfect, thanks!  Probably worth adding this to the docs?

Re: XHTML export -   etc.

[Daniel Clemente]

  Hi,

   Bastien suggested in other thread adding ~ to get a „protected
space" in LaTeX, and now I discover that a \nbsp is also to get a
protected space in HTML.  So why can't we use the same syntax for
LaTeX and HTML?

   Some other similar signs:
\-   : breaking allowed
~  : protected space
--   : hyphen
Also -  ,  ---

   It would be nice if the behaviour in HTML and LaTeX were the same.

Re: XHTML export -   etc.

[Daniel Clemente]

Oops!

--  : dash, not hyphen :-)

„hyphen" is -

Re: XHTML export -   etc.

[Bastien]

"Daniel Clemente" <n142857@gmail.com> writes:

>    Bastien suggested in other thread adding ~ to get a „protected
> space" in LaTeX, and now I discover that a \nbsp is also to get a
> protected space in HTML.  So why can't we use the same syntax for
> LaTeX and HTML?

>    Some other similar signs:
> \-   : breaking allowed
> ~  : protected space
> --   : hyphen
> Also -  ,  ---

What about this:

| Org    | HTML   | LaTeX |
|--------+--------+-------|
| \-     | &shy;  | \-    |
| ~ or   | &nbsp; | ~     |
| --     | -      | --    |
| ---    | --     | ---   |

I'm not sure about the the last two columns.  Maybe it's simpler to
let -- and --- be -- and --- in HTML output as well.

-- 
Bastien

Re: XHTML export -   etc.

[William Henney]

Hi list

On 11/2/07, Bastien <bzg@altern.org> wrote:

> I'm not sure about the the last two columns.  Maybe it's simpler to
> let -- and --- be -- and --- in HTML output as well.
>

Shouldn't they be `&endash;' and `&emdash;' in HTML?

http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_Symbols

Cheers

Will


-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

Re: XHTML export -   etc.

[Daniel Clemente]

> Shouldn't they be `&endash;' and `&emdash;' in HTML?
>
> http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_Symbols
>

  You mean – and —
  – and — for -- and --- respectively is ok. I think there
exist no ---- and -----
  ­ with \-    and     with ~   are also good... There exists
also ​  (zero-width space), but that's not a sign for breaking
words into syllables; ­ is in addition better implemented.

   That means that following signs:
\-
~
--
---
   would have a special meaning when being exported on all org documents.

   I don't know if ~ is a good election. It should be looked for
inside of words (li~ke this), but probably excluding URLs. Maybe that
causes more problems to the users who want to write a literal ~.
   The symbol for „breaking allowed" could also be \~ ...  That's an
inconsistency with LaTeX ~, but is consistent with LaTeX's \-   And
that would leave ~ untouched and just use \- and \~ for hyphenation.


   Greets,
Daniel

Re: XHTML export -   etc.

[Bastien]

>    I don't know if ~ is a good election. It should be looked for
> inside of words (li~ke this), but probably excluding URLs. Maybe that
> causes more problems to the users who want to write a literal ~.

I also think this is too complex.

>    The symbol for „breaking allowed" could also be \~ ...  That's an
> inconsistency with LaTeX ~, but is consistent with LaTeX's \-   And
> that would leave ~ untouched and just use \- and \~ for hyphenation.

What is wrong with \- ?  It seems enough to me.

-- 
Bastien

Re: XHTML export -   etc.

[Daniel Clemente]

>
> >    The symbol for „breaking allowed" could also be \~ ...  That's an
> > inconsistency with LaTeX ~, but is consistent with LaTeX's \-   And
> > that would leave ~ untouched and just use \- and \~ for hyphenation.
>
> What is wrong with \- ?  It seems enough to me.

  Sorry, I wanted to say the symbol for „*nonbreaking space*" could be
\~   , instead of just ~
  That way the symbols for hyphenation are more symmetrical: \- for
„breaking allowed" and \~ for „nonbreaking space".
  And then the normal ~ is still rendered as expected.


>    I removed the idea of using the tilde character `~' for inerting a non-breakable space in Org source file because:
> ...
>  - this is the function of Emacs non-breakable space character `'

   What do you mean? Did you type something? I see nothing; just `'

   Is it better to enter the unicode character directly, or offering
something like \~ ? I suppose both could be changed at the exporting,
so maybe it's a matter of taste.



Daniel

Re: XHTML export -   etc.

[Bastien]

"Daniel Clemente" <n142857@gmail.com> writes:

>   Sorry, I wanted to say the symbol for „*nonbreaking space*" could be
> \~ , instead of just ~

I think this would be weird.

By "nonbreaking character", I meant the output of C-x 8 SPC (try it).

This is iso-8859-1, not ascii, so we should avoid to handle this in Org
source file -- but my bet is that people who want to insert nonbreaking
characters are also people using other charsets than ascii.

>    Is it better to enter the unicode character directly, or offering
> something like \~ ? 

For me \~ would rather mean "don't convert ~", which means: output "~"
(at least in LaTeX, since the normal LaTeX conversion for ~ is \~)

-- 
Bastien

Re: XHTML export -   etc.

[Daniel Clemente]

Hi

>
> By "nonbreaking character", I meant the output of C-x 8 SPC (try it).
>
> This is iso-8859-1, not ascii, so we should avoid to handle this in Org
> source file -- but my bet is that people who want to insert nonbreaking
> characters are also people using other charsets than ascii.
>

   If you use C-x 8 SPC in a text file, you probably want to export it
as ~ in LaTeX, not to include that Unicode character directly. But
this conversion is a strange one, therefore it may be besser to offer
a syntax for the ~ (non-breaking space) in LaTeX. For instance \~ or ~

> >    Is it better to enter the unicode character directly, or offering
> > something like \~ ?
>
> For me \~ would rather mean "don't convert ~", which means: output "~"
> (at least in LaTeX, since the normal LaTeX conversion for ~ is \~)
>

   But we said that if someone writes ~ in an org-file, then it is
expected that ~ appears at the result. Therefore:
   ~ is for the sign ~
   other sign (maybe \~ ) is for the non-breaking space

   I know this behaviour it's not the same as LaTeX, but I don't think
it's a problem.


Daniel

Re: XHTML export -   etc.

[Bastien]

"Daniel Clemente" <n142857@gmail.com> writes:

>    If you use C-x 8 SPC in a text file, you probably want to export it
> as ~ in LaTeX, not to include that Unicode character directly. 

This is what i suggested.

> But this conversion is a strange one, 

Why?

> therefore it may be besser to offer a syntax for the ~ (non-breaking
> space) in LaTeX. For instance \~ or ~

I think I misunderstood at some point.  For me "\~" means "protect the
tilde character from conversion" which means "don't escape the tilde",
which results into a LaTeX nonbreaking-space (~).

Note that this is also the case for "%": \% unescape the "%" character,
then starts a comment in the LaTeX source.

My point about letting C-x 8 SPC being converted into ~ was this: those
people who are likely to use nonbreaking spaces are also those who won't
be scared by using non-ascii characters such as C-x 8 SPC in their Org
files.  I might be wrong on this.

-- 
Bastien

Re: XHTML export -   etc.

[Daniel Clemente]

>
> >    If you use C-x 8 SPC in a text file, you probably want to export it
> > as ~ in LaTeX, not to include that Unicode character directly.
>
> This is what i suggested.
>
   Ok, I misunderstood because you said „so we should avoid to handle
this in Org source file"

> > But this conversion is a strange one,
>
> Why?

   Well, I didn't know the character inserted by C-x 8 SPC, and I
suppose most people don't use it frequently. However, it could be used
and that would be simple. For instance:
 - you write C-x 8 SPC in your org files
 - C-x 8 SPC is exported to   on HTML
 - C-x 8 SPC is exported to ~ on HTML
 - ~ continues working normally: produces ~ on HTML and \~{} on LaTeX


>
> > therefore it may be besser to offer a syntax for the ~ (non-breaking
> > space) in LaTeX. For instance \~ or ~
>
> I think I misunderstood at some point.  For me "\~" means "protect the
> tilde character from conversion" which means "don't escape the tilde",
> which results into a LaTeX nonbreaking-space (~).
>
   But we don't need to „protect the tilde from conversion" because ~
already writes the tilde unconverted.  \~ is still free to other uses.
   Sometimes the \ means „don't escape", sometimes not. For instance
at \- it wouldn't mean „insert a hyphen", but „breaking allowed".
   Yes, that's confusing...


Daniel

Re: XHTML export -   etc.

[Bastien]

"Daniel Clemente" <n142857@gmail.com> writes:

>  - you write C-x 8 SPC in your org files
>  - C-x 8 SPC is exported to &nbsp; on HTML
>  - C-x 8 SPC is exported to ~ on HTML
>  - ~ continues working normally: produces ~ on HTML and \~{} on LaTeX

100% okay.  And you can add:

- \~ will insert ~ in the LaTeX source

>    Sometimes the \ means „don't escape", sometimes not. 

Are you okay with this:

 Org  =>  LaTeX
----------------
  \~  =>  ~
  \%  =>  %    
  \#  =>  #    
  \{  =>  {    
  \}  =>  }    
  \&  =>  &    
  \_  =>  _    
  \^  =>  ^    

(i.e. preventing special characters from being converted.)

-- 
Bastien

Re: XHTML export -   etc.

[Daniel Clemente]

>
> >  - you write C-x 8 SPC in your org files
> >  - C-x 8 SPC is exported to   on HTML
> >  - C-x 8 SPC is exported to ~ on HTML
> >  - ~ continues working normally: produces ~ on HTML and \~{} on LaTeX
>
> 100% okay.  And you can add:
>
> - \~ will insert ~ in the LaTeX source
>
   Yes

> >    Sometimes the \ means „don't escape", sometimes not.
>
> Are you okay with this:
>
>  Org  =>  LaTeX
> ----------------
>   \~  =>  ~
>   \%  =>  %
>   \#  =>  #
>   \{  =>  {
>   \}  =>  }
>   \&  =>  &
>   \_  =>  _
>   \^  =>  ^
>
> (i.e. preventing special characters from being converted.)

   Mmm... some of those characters /can/ already be written directly
and they won't be interpreted, so you suggest adding a second method
(ex: \# besides # ). Maybe some users find this confusing and prefer
just one way to write each sign.
   What do other people think? Should both # and \# write # ?

   But your proposal would convert \ into the generic escaping character.
   This is good since then you can always write \% (or with any
character of the list) and you know it will be escaped.
   But this is bad because this would only work on the characters you
proposed, not on all. Ex \[ would probably write \[ and not [

   I would suggest:
 1.  Using \# just for signs that are part of org's syntax: _ ^
 2.  Developing a general way to include a literal text without
processing of org's syntax. For instance, the string *word* where both
asterisks should be visible at the exported text (instead of a bold
word). That can be implemented with start-end markers (ex:
<literal>some *unprocessed* text</literal>) or with a marker before
each sign: (ex: some \*unprocessed\* text).

  1 and 2 can be combined if \# works with exactly all syntax
elements, that means, all elements which would otherwise change the
meaning and processing of the text. For instance:
\*
\/
\[
\]
\#
\|
\=
etc.
  Of course, also \\ must be present to write a literal \
  For the signs which are not part of org's syntax, you wouldn't need
to write \  Ex: \( is unnecesary since ( has no meaning in org.


   Sorry for starting anothed discussion :-)


Daniel

Re: XHTML export -   etc.

[Daniel Clemente]

I should add that the @<em>at-syntax@</em>:
-  is too HTML-specific (we need something that exports as good to
LaTeX as to HTML)
- and sometimes it isn't clear what to write. For instance if I want
to write [1] without being processed as a footnote (on a document with
footnotes on); something like @<span>[@</span>1@<span>]@</span> would
be too complex.


@<strong>@<em>Greetings@</em>@</strong> :-)
Daniel


2007/11/9, Daniel Clemente <n142857@gmail.com>:
> >
> > >  - you write C-x 8 SPC in your org files
> > >  - C-x 8 SPC is exported to &nbsp; on HTML
> > >  - C-x 8 SPC is exported to ~ on HTML
> > >  - ~ continues working normally: produces ~ on HTML and \~{} on LaTeX
> >
> > 100% okay.  And you can add:
> >
> > - \~ will insert ~ in the LaTeX source
> >
>    Yes
>
> > >    Sometimes the \ means „don't escape", sometimes not.
> >
> > Are you okay with this:
> >
> >  Org  =>  LaTeX
> > ----------------
> >   \~  =>  ~
> >   \%  =>  %
> >   \#  =>  #
> >   \{  =>  {
> >   \}  =>  }
> >   \&  =>  &
> >   \_  =>  _
> >   \^  =>  ^
> >
> > (i.e. preventing special characters from being converted.)
>
>    Mmm... some of those characters /can/ already be written directly
> and they won't be interpreted, so you suggest adding a second method
> (ex: \# besides # ). Maybe some users find this confusing and prefer
> just one way to write each sign.
>    What do other people think? Should both # and \# write # ?
>
>    But your proposal would convert \ into the generic escaping character.
>    This is good since then you can always write \% (or with any
> character of the list) and you know it will be escaped.
>    But this is bad because this would only work on the characters you
> proposed, not on all. Ex \[ would probably write \[ and not [
>
>    I would suggest:
>  1.  Using \# just for signs that are part of org's syntax: _ ^
>  2.  Developing a general way to include a literal text without
> processing of org's syntax. For instance, the string *word* where both
> asterisks should be visible at the exported text (instead of a bold
> word). That can be implemented with start-end markers (ex:
> <literal>some *unprocessed* text</literal>) or with a marker before
> each sign: (ex: some \*unprocessed\* text).
>
>   1 and 2 can be combined if \# works with exactly all syntax
> elements, that means, all elements which would otherwise change the
> meaning and processing of the text. For instance:
> \*
> \/
> \[
> \]
> \#
> \|
> \=
> etc.
>   Of course, also \\ must be present to write a literal \
>   For the signs which are not part of org's syntax, you wouldn't need
> to write \  Ex: \( is unnecesary since ( has no meaning in org.
>
>
>    Sorry for starting anothed discussion :-)
>
>
> Daniel
>

Re: XHTML export -   etc.

[Eddward DeVilla]

I feel tempted to bring up my suggestion of [markup|text] format
again, but I've been resisting because I feel like a develish nag.  So
[*|at-syntax] could still be html specific if you really want
something html specific, but there would be something that could be
portable to all export formats.  It would just be a matter of deciding
what 'org' marks should be supported and making sure exporters try to
support them.  And of course there are other ways to get around *at
syntax*.

Edd

On Nov 9, 2007 1:59 PM, Daniel Clemente <n142857@gmail.com> wrote:
> I should add that the @<em>at-syntax@</em>:
> -  is too HTML-specific (we need something that exports as good to
> LaTeX as to HTML)
> - and sometimes it isn't clear what to write. For instance if I want
> to write [1] without being processed as a footnote (on a document with
> footnotes on); something like @<span>[@</span>1@<span>]@</span> would
> be too complex.
>
>
> @<strong>@<em>Greetings@</em>@</strong> :-)
> Daniel
>
>
> 2007/11/9, Daniel Clemente <n142857@gmail.com>:
>
> > >
> > > >  - you write C-x 8 SPC in your org files
> > > >  - C-x 8 SPC is exported to &nbsp; on HTML
> > > >  - C-x 8 SPC is exported to ~ on HTML
> > > >  - ~ continues working normally: produces ~ on HTML and \~{} on LaTeX
> > >
> > > 100% okay.  And you can add:
> > >
> > > - \~ will insert ~ in the LaTeX source
> > >
> >    Yes
> >
> > > >    Sometimes the \ means „don't escape", sometimes not.
> > >
> > > Are you okay with this:
> > >
> > >  Org  =>  LaTeX
> > > ----------------
> > >   \~  =>  ~
> > >   \%  =>  %
> > >   \#  =>  #
> > >   \{  =>  {
> > >   \}  =>  }
> > >   \&  =>  &
> > >   \_  =>  _
> > >   \^  =>  ^
> > >
> > > (i.e. preventing special characters from being converted.)
> >
> >    Mmm... some of those characters /can/ already be written directly
> > and they won't be interpreted, so you suggest adding a second method
> > (ex: \# besides # ). Maybe some users find this confusing and prefer
> > just one way to write each sign.
> >    What do other people think? Should both # and \# write # ?
> >
> >    But your proposal would convert \ into the generic escaping character.
> >    This is good since then you can always write \% (or with any
> > character of the list) and you know it will be escaped.
> >    But this is bad because this would only work on the characters you
> > proposed, not on all. Ex \[ would probably write \[ and not [
> >
> >    I would suggest:
> >  1.  Using \# just for signs that are part of org's syntax: _ ^
> >  2.  Developing a general way to include a literal text without
> > processing of org's syntax. For instance, the string *word* where both
> > asterisks should be visible at the exported text (instead of a bold
> > word). That can be implemented with start-end markers (ex:
> > <literal>some *unprocessed* text</literal>) or with a marker before
> > each sign: (ex: some \*unprocessed\* text).
> >
> >   1 and 2 can be combined if \# works with exactly all syntax
> > elements, that means, all elements which would otherwise change the
> > meaning and processing of the text. For instance:
> > \*
> > \/
> > \[
> > \]
> > \#
> > \|
> > \=
> > etc.
> >   Of course, also \\ must be present to write a literal \
> >   For the signs which are not part of org's syntax, you wouldn't need
> > to write \  Ex: \( is unnecesary since ( has no meaning in org.
> >
> >
> >    Sorry for starting anothed discussion :-)
> >
> >
> > Daniel
> >
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

Re: XHTML export -   etc.

[Xiao-Yong Jin]

"Eddward DeVilla" <eddward@gmail.com> writes:

> I feel tempted to bring up my suggestion of [markup|text] format
> again, but I've been resisting because I feel like a develish nag.  So
> [*|at-syntax] could still be html specific if you really want
> something html specific, but there would be something that could be
> portable to all export formats.  It would just be a matter of deciding
> what 'org' marks should be supported and making sure exporters try to
> support them.  And of course there are other ways to get around *at
> syntax*.

I would vote against heavily mark-up format like that.  I
guess the original design of org-mode is to make a simple
text file that can make personal information organization
much simpler in emacs, as opposed to those half-mark-up
languages like emacs-muse.

I would suggest to keep current method, which is converting
everything that could be converted.  To resolve the
complication in some circumstances where conversion of `[1]'
or `_', `^' and etc. is not wanted, I would propose that we
can just use one of the mark-ups, `=code=', and make it be
actually `=verbatim='.

These are just what I think.  Probably there is another way
to go: merge with emacs-muse!


Xiao-Yong
-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: XHTML export -   etc.

[Bastien]

Xiao-Yong Jin <xj2106@columbia.edu> writes:

> "Eddward DeVilla" <eddward@gmail.com> writes:
>
>> I feel tempted to bring up my suggestion of [markup|text] format
>> again, but I've been resisting because I feel like a develish nag.  So
>> [*|at-syntax] could still be html specific if you really want
>> something html specific, but there would be something that could be
>> portable to all export formats.  It would just be a matter of deciding
>> what 'org' marks should be supported and making sure exporters try to
>> support them.  And of course there are other ways to get around *at
>> syntax*.
>
> I would vote against heavily mark-up format like that.  I
> guess the original design of org-mode is to make a simple
> text file that can make personal information organization
> much simpler in emacs, as opposed to those half-mark-up
> languages like emacs-muse.

FWIW, I second this.

-- 
Bastien

Re: XHTML export -   etc.

[Bastien]

About escaping characters in LaTeX, here is the rule I'm trying to stick
to: 

1. If a character is a special character in LaTeX, org-export-latex.el
   will escape it (so that this character will be correctly displayed in
   the resulting .dvi.)

2. If you escape such a character in the Org source file, then this
   character won't be escaped in the LaTeX source file, meaning that you
   want to refer to the special meaning of this character in LaTeX.

I don't use any notion of "Org's special character".

As long as this approach handles 99% of the special characters issues, I
think it's better not to try to invent any new specific Org syntax or to
impose new writing conventions...

I will work on the relevant code for that this week, let's see what
happen then.

Thanks,

"Daniel Clemente" <n142857@gmail.com> writes:

>>
>    Yes
>
>> >    Sometimes the \ means „don't escape", sometimes not.
>>
>> Are you okay with this:
>>
>>  Org  =>  LaTeX
>> ----------------
>>   \~  =>  ~
>>   \%  =>  %
>>   \#  =>  #
>>   \{  =>  {
>>   \}  =>  }
>>   \&  =>  &
>>   \_  =>  _
>>   \^  =>  ^
>>
>> (i.e. preventing special characters from being converted.)
>
>    Mmm... some of those characters /can/ already be written directly
> and they won't be interpreted, so you suggest adding a second method
> (ex: \# besides # ). Maybe some users find this confusing and prefer
> just one way to write each sign.
>    What do other people think? Should both # and \# write # ?
>
>    But your proposal would convert \ into the generic escaping character.
>    This is good since then you can always write \% (or with any
> character of the list) and you know it will be escaped.
>    But this is bad because this would only work on the characters you
> proposed, not on all. Ex \[ would probably write \[ and not [
>
>    I would suggest:
>  1.  Using \# just for signs that are part of org's syntax: _ ^
>  2.  Developing a general way to include a literal text without
> processing of org's syntax. For instance, the string *word* where both
> asterisks should be visible at the exported text (instead of a bold
> word). That can be implemented with start-end markers (ex:
> <literal>some *unprocessed* text</literal>) or with a marker before
> each sign: (ex: some \*unprocessed\* text).
>
>   1 and 2 can be combined if \# works with exactly all syntax
> elements, that means, all elements which would otherwise change the
> meaning and processing of the text. For instance:
> \*
> \/
> \[
> \]
> \#
> \|
> \=
> etc.
>   Of course, also \\ must be present to write a literal \
>   For the signs which are not part of org's syntax, you wouldn't need
> to write \  Ex: \( is unnecesary since ( has no meaning in org.
>
>
>    Sorry for starting anothed discussion :-)
>
>
> Daniel
>

-- 
Bastien

Re: XHTML export -   etc.

[William Henney]

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

On 11/2/07, Daniel Clemente <n142857@gmail.com> wrote:
> > Shouldn't they be `&endash;' and `&emdash;' in HTML?
> >
> > http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_Symbols
> >
>
>   You mean &ndash; and &mdash;

Yes. Thanks for the correction.

Personally, I tend to just use the unicode characters directly in my
org file. This works quite well om the whole (see attached example).

Cheers

Will

-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: unicode.org --]
[-- Type: application/octet-stream, Size: 6646 bytes --]

#+TITLE:     Unicode and org mode
#+AUTHOR:    William Henney
#+EMAIL:     w.henney@astrosmo.unam.mx
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:nil toc:t \n:nil @:t ::t |:t ^:t f:t *:t TeX:t LaTeX:t skip:t p:nil

* Notes on using unicode characters in org mode 
** How to enter the unicode characters
   Use either the SGML or TeX input method.
*** Using the TeX input method
    + Type =C-u C-\ tex= to activate
    + Type things like =\alpha= or =x^2= and they will be translated
      into the unicode glyph. Use tab for completion help. 
    + Pro: "Intuitive" to use. 
    + Con: Gets in the way of typing a "real" backslash
*** Using the SGML input method
    + Type =C-u C-\ sgml= to activate
    + Type things like =&alpha;= or =&deg;= to get α and °. 
    + Pro: Access to more glyphs than with TeX it seems
    + Con: No access to sub/superscripts
      
** Punctuation
   We can use the em and en dashes—this clause is bounded by em
   dashes—directly in the org file. However, they aren't very easily
   distinguishable in some fonts, especially fixed width ones at small
   sizes. Here is a range of numbers separated by an en dash: 223–999.
   In this sentence – following British typographic convention –
   the en dash is used like the em dash is used in American
   typography. Here are some minus signs:— binary (223 − 999) and
   unary (−0.2). Finally, here is a hyphen for comparison: a-b. They
   look good in proportional fonts, such as Times, Futura and
   Optima. Baskerville is the font where they look most like their
   Computer Modern versions. In fact, Baskerville looks quite a lot
   like CMR in other ways too… Oh, and that was an ellipsis. 
   
:   Test in fixed-width font:— range 666–999 

   | symbol  | examples |
   |---------+----------|
   | hyphen  | 1-2  a-b |
   | en dash | 1–2  a–b |
   | em dash | 1—2  a—b |
   | minus   | 1−2  a−b |
   |---------+----------|

   It seems that the glyphs for the non-ascii characters are always
   taken from those of the font family of the =default= face, even
   where the font-lock face is specifically set to another font
   family.

** Dealing with pre-formatted text
:This uses the org-code face, so we can easily make 
:it fixed-width
   Even if we are using a proportional font family for the =default=
   face, by customizing the =org-code= face, we can use a fixed-width
   font (such as Monaco) for pre-formatted material (lines starting
   with ":" and words delimited with "="). We can do the same with the
   =org-table= face, so that the alignment of table lines still
   works. In the case of the pairing of Monaco and Times, it is also
   necessary to set the height of the fixed-width faces to 0.85, so
   that the character sizes match up.
*** Bugs
    1. Table alignment still won't be quite right if there are unicode
       characters in the table cells, since the glyphs for these have
       variable widths, even in a /supposedly/ fixed-width font like
       Monaco. 
    2. It doesn't work for sections with the QUOTE keyword, since
       these do not use any special face.
   
** Other typographical symbols (e.g., §)
   It would be nice if we could use ∗, • and ⋆ as list markers. Maybe
   even ♥and ♠, although they look a bit heavy. 

** Greek letters and math symbols: /α = x² − y²/

   Examples: ½∫ Ξ₀ dz = ℏc/λ ⇒ ϑ ⊂ {⊼, ⋓, ∡} □


*** Variations between fonts (Mac OS X 10.4/Aquamacs 1.2)
      As far as I can see, only a few fonts have their own set of
      glyphs for the Greek letters. Times has a nice set of glyphs,
      although it does have the problem that italic nu and italic v
      look /very/ similar. Spot the difference: /νv/ ! Most font
      families use a common set of glyphs that have a Sans Serif feel
      to them, as though they were designed to go with Helvetica
      (although Helvetica actually uses a slightly different
      set). These glyphs have the problem that the "gamma" looks too
      much like a "y" and the "tau" looks like a "t". When used with
      Monaco, they look too small. 

     
*** Super- and sub-scripts
    These don't exist for all letters. 

*** Example alphabets
    αβγδεζηθικλμνξοπρστυφχψω\\
    /αβγδεζηθικλμνξοπρστυφχψω/\\
    abcdefghijklmnopqrstuvwxyz\\
    /abcdefghijklmnopqrstuvwxyz/ \\
    ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ\\
    /ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ/ \\
    ABCDEFGHIJKLMNOPQRSTUVWXYZ\\
    /ABCDEFGHIJKLMNOPQRSTUVWXYZ/ \\
    
:    αβγδεζηθικλμνξοπρστυφχψω
:    /αβγδεζηθικλμνξοπρστυφχψω/
:    abcdefghijklmnopqrstuvwxyz
:    /abcdefghijklmnopqrstuvwxyz/
:    ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ
:    /ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ/
:    ABCDEFGHIJKLMNOPQRSTUVWXYZ
:    /ABCDEFGHIJKLMNOPQRSTUVWXYZ/

** Export to HTML
   This should work since the charset is declared as utf-8. However,
   support in browsers is variable.
   + Safari and Opera work the best—everything looks pretty nice in
     both. 
   + Firefox does OK, but the minus signs come out as hyphen. The bold
     math looks funny too with greek letters being *very* bold.  

** Export to LaTeX
   Presumably, this won't work out of the box. I haven't tried it
   yet. However, see this [[http://iamleeg.blogspot.com/2007/10/nice-looking-latex-unicode.html][blog post by Graham Lee]] for a possible
   solution:
:\usepackage{ucs} % Unicode support
:\usepackage[utf8x]{inputenc} % UCS' UTF-8 driver is better than the LaTeX kernel's
:\usepackage[T1]{fontenc} % The default font encoding only contains Latin characters
:\usepackage{ae,aecompl} % Almost European fonts/hyphenation do a better job than Computer Modern

*** Update [2007-11-02 Fri]
    Best to use the option =\usepackage[mathletters]{ucs}=, since
    otherwise it tries to use commands like =\textalpha= and I have no
    idea where these are defined (and Google wasn't much help). With
    =mathletters= it uses the standard math symbol greek alphabet,
    whether you are in math mode or not. I guess a better solution
    would be to use =\ifmmode= to test if we are in math mode and use
    =\upalpha= if we are not. 
**** Problems encountered with =org-export-latex=
     + Backslashes in quoted text are not properly escaped. 
 
** Integration with calc
   Calc does not understand unicode as afar as I can see (e.g., it
   doesn't recognise 2.3 ± 0.4 as an error form). Presumably, this
   could be fixed rather easily since calc already has the concept of
   display styles. 



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

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: XHTML export -   etc.

[Bastien]

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

"William Henney" <whenney@gmail.com> writes:

> Personally, I tend to just use the unicode characters directly in my
> org file. This works quite well om the whole (see attached example).

This is *very* nice.

I attach the corresponding .tex source and a .pdf output.

I used org-export-latex.el for this.  I had to handle backslashes issues
(hopefully this will be fixed in org-export-latex.el) and some unicode
characters could not be printed:

Unicode characters: ✧ ♥ ⊼ ⋓ ∡ □ ϑ

ERROR: Package ucs Error: Unknown Unicode character 9829 = U+2665,

I don't have any clue on how this could be handled...


[-- Attachment #2: unicode.tex --]
[-- Type: text/x-tex, Size: 7742 bytes --]

% Created 2007-11-03 sam 11:58
\documentclass[11pt,a4paper]{article}
\usepackage[mathletters]{ucs}
%\usepackage{ucs}             % Unicode support
\usepackage[utf8x]{inputenc}   % UCS' UTF-8 driver is better than the LaTeX kernel's
\usepackage[T1]{fontenc}      % The default font encoding only contains Latin characters
\usepackage{ae,aecompl}       % Almost European fonts/hyphenation do a better job than Computer Modern
\usepackage{graphicx}
\usepackage{hyperref}
\hypersetup{
  colorlinks=true,
  urlcolor=blue,
  linkcolor=blue,
  }

\title{Unicode and org mode}
\author{William Henney}
\date{03 novembre 2007}

\begin{document}

\maketitle

\section*{Notes on using unicode characters in org mode}

\subsection*{How to enter the unicode characters}

Use either the SGML or TeX input method.

\subsubsection*{Using the TeX input method}

\begin{itemize}
\item Type \texttt{C-u C-\textbackslash{} tex} to activate
\item Type things like \texttt{$\alpha$} or \texttt{$x^2$} and they will be translated
      into the unicode glyph. Use tab for completion help.
\item Pro: ``Intuitive'' to use.
\item Con: Gets in the way of typing a ``real'' backslash
\end{itemize}

\subsubsection*{Using the SGML input method}

\begin{itemize}
\item Type \texttt{C-u C-\textbackslash{} sgml} to activate
\item Type things like \texttt{\&alpha;} or \texttt{\&deg;} to get α and °.
\item Pro: Access to more glyphs than with TeX it seems
\item Con: No access to sub/superscripts
\end{itemize}

\subsection*{Punctuation}

We can use the em and en dashes—this clause is bounded by em
dashes—directly in the org file. However, they aren't very easily
distinguishable in some fonts, especially fixed width ones at small
sizes. Here is a range of numbers separated by an en dash: 223–999.  In
this sentence – following British typographic convention – the en dash
is used like the em dash is used in American typography. Here are some
minus signs:— binary (223 − 999) and unary (−0.2). Finally, here is a
hyphen for comparison: a-b. They look good in proportional fonts, such
as Times, Futura and Optima. Baskerville is the font where they look
most like their Computer Modern versions. In fact, Baskerville looks
quite a lot like CMR in other ways too… Oh, and that was an ellipsis.
 
\begin{verbatim}
   Test in fixed-width font:— range 666–999 
\end{verbatim}


\begin{tabular}{ll}
 symbol   &  examples  \\
\hline
 hyphen   &  1-2  a-b  \\
 en dash  &  1–2  a–b  \\
 em dash  &  1—2  a—b  \\
 minus    &  1−2  a−b  \\
\hline
\end{tabular}


It seems that the glyphs for the non-ascii characters are always taken
from those of the font family of the \texttt{default} face, even where
the font-lock face is specifically set to another font family.

\subsection*{Dealing with pre-formatted text}

\begin{verbatim}
This uses the org-code face, so we can easily make 
it fixed-width
\end{verbatim}

Even if we are using a proportional font family for the \texttt{default}
face, by customizing the \texttt{org-code} face, we can use a
fixed-width font (such as Monaco) for pre-formatted material (lines
starting with ``:'' and words delimited with ``=''). We can do the same
with the \texttt{org-table} face, so that the alignment of table lines
still works. In the case of the pairing of Monaco and Times, it is also
necessary to set the height of the fixed-width faces to 0.85, so that
the character sizes match up.

\subsubsection*{Bugs}

\begin{enumerate}
\item Table alignment still won't be quite right if there are unicode
       characters in the table cells, since the glyphs for these have
       variable widths, even in a \emph{supposedly} fixed-width font like
       Monaco.
\item It doesn't work for sections with the QUOTE keyword, since
       these do not use any special face.
\end{enumerate}

\subsection*{Other typographical symbols (e.g., §)}

% FIXME Cannot be printed:
% It would be nice if we could use ∗, • and ⋆ as list markers. Maybe even
% ♥ and ♠, although they look a bit heavy.

Diamond character: ♢ 

% FIXME Cannot be printed:
%✧ ♥ ⊼ ⋓ ∡ □ ϑ

\subsection*{Greek letters and math symbols: \emph{α = x² − y²}}

% FIXME Cannot be printed:
%Examples: ½∫ Ξ₀ dz = ℏc/λ ⇒ ϑ ⊂ \{⊼, ⋓, ∡\} □
Examples: ½∫ Ξ₀ dz = ℏc/λ ⇒ 

\subsubsection*{Variations between fonts (Mac OS X 10.4/Aquamacs 1.2)}

As far as I can see, only a few fonts have their own set of glyphs for
the Greek letters. Times has a nice set of glyphs, although it does have
the problem that italic nu and italic v look \emph{very} similar. Spot
the difference: \emph{νv} ! Most font families use a common set of
glyphs that have a Sans Serif feel to them, as though they were designed
to go with Helvetica (although Helvetica actually uses a slightly
different set). These glyphs have the problem that the ``gamma'' looks
too much like a ``y'' and the ``tau'' looks like a ``t''. When used with
Monaco, they look too small.
     
\subsubsection*{Super- and sub-scripts}

These don't exist for all letters. 

\subsubsection*{Example alphabets}

αβγδεζηθικλμνξοπρστυφχψω\\
/αβγδεζηθικλμνξοπρστυφχψω/\\
abcdefghijklmnopqrstuvwxyz\\
\emph{abcdefghijklmnopqrstuvwxyz} \\
ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ\\
\emph{ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ} \\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\\
\emph{ABCDEFGHIJKLMNOPQRSTUVWXYZ} \\
    
\begin{verbatim}
αβγδεζηθικλμνξοπρστυφχψω
/αβγδεζηθικλμνξοπρστυφχψω/
abcdefghijklmnopqrstuvwxyz
/abcdefghijklmnopqrstuvwxyz/
ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ
/ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ/
ABCDEFGHIJKLMNOPQRSTUVWXYZ
/ABCDEFGHIJKLMNOPQRSTUVWXYZ/
\end{verbatim}

\subsection*{Export to HTML}

This should work since the charset is declared as utf-8. However,
support in browsers is variable.

\begin{itemize}
\item Safari and Opera work the best—everything looks pretty nice in
  both.
\item Firefox does OK, but the minus signs come out as hyphen. The bold
  math looks funny too with greek letters being \textbf{very} bold.
\end{itemize}

\subsection*{Export to \LaTeX{}}

   Presumably, this won't work out of the box. I haven't tried it
   yet. However, see this \href{http://iamleeg.blogspot.com/2007/10/nice-looking-latex-unicode.html}{blog post by Graham Lee} for a possible
   solution:

\begin{verbatim}
\usepackage{ucs} % Unicode support
\usepackage[utf8x]{inputenc} % UCS' UTF-8 driver is better than the \LaTeX{} kernel's
\usepackage[T1]{fontenc} % The default font encoding only contains Latin characters
\usepackage{ae,aecompl} % Almost European fonts/hyphenation do a better job than Computer Modern
\end{verbatim}

\subsubsection*{Update [2007-11-02 Fri]}

% FIXME (some chars were removed):
Best to use the option \texttt{[mathletters]}, since otherwise it tries
to use commands like \texttt{textalpha} and I have no idea where these
are defined (and Google wasn't much help). With \texttt{mathletters} it
uses the standard math symbol greek alphabet, whether you are in math
mode or not. I guess a better solution would be to use \texttt{ifmmode}
to test if we are in math mode and use \texttt{upalpha} if we are not.

\begin{description}

\item[Problems encountered with \texttt{org-export-latex}]

\begin{itemize}
\item Backslashes in quoted text are not properly escaped.
\end{itemize}

\end{description}

\subsection*{Integration with calc}

Calc does not understand unicode as afar as I can see (e.g., it
doesn't recognise 2.3 ± 0.4 as an error form). Presumably, this
could be fixed rather easily since calc already has the concept of
display styles. 

\end{document}

[-- Attachment #3: unicode.pdf --]
[-- Type: application/pdf, Size: 117008 bytes --]

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


-- 
Bastien

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

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: XHTML export -   etc.

[William Henney]

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

Hi Bastien

On 11/3/07, Bastien <bzg@altern.org> wrote:
> "William Henney" <whenney@gmail.com> writes:
>
> > Personally, I tend to just use the unicode characters directly in my
> > org file. This works quite well om the whole (see attached example).
>
> This is *very* nice.
>

Glad you liked it

> I attach the corresponding .tex source and a .pdf output.
>
> I used org-export-latex.el for this.  I had to handle backslashes issues
> (hopefully this will be fixed in org-export-latex.el)

That would be great!

> and some unicode
> characters could not be printed:
>
> Unicode characters: ✧ ♥ ⊼ ⋓ ∡ □ ϑ
>
> ERROR: Package ucs Error: Unknown Unicode character 9829 = U+2665,
>
> I don't have any clue on how this could be handled...
>

Here is what I have managed to work out. Apologies for answering in
org syntax :)

------------------------------------------------------------------------
*** Second update [2007-11-03 Sat]
**** Finding LaTeX definitions for obscure symbols
     Look in the
[[http://www.ctan.org/tex-archive/info/symbols/comprehensive/][Comprehensive
LaTeX Symbol List]] to find the package
     where each symbol is defined.
     + =\usepackage{amssymb}= provides lots of the more obscure math
       symbols, such as ⋓ (=\Cup=).
**** Telling =ucs.sty= about symbols it doesn't understand
     We can use something like
:\DeclareUnicodeCharacter{977}{\ensuremath{\vartheta}}
     + Note that the code (e.g., 977) can be found from the TeX error
       message. It seems to be decimal, but I still haven't worked out
       its relation to the Unicode hex code.
     + A better way might be to add the new definitions to the ucs
       config files and run =makeunidef.pl=
------------------------------------------------------------------------

Attached are example .tex and .pdf that work for me.

Cheers

Will

-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: unicode-test.tex --]
[-- Type: application/x-tex, Size: 801 bytes --]

[-- Attachment #3: unicode-test.pdf --]
[-- Type: application/pdf, Size: 22723 bytes --]

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

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: XHTML export -   etc.

[Bastien]

"William Henney" <whenney@gmail.com> writes:

>> ERROR: Package ucs Error: Unknown Unicode character 9829 = U+2665,
>>
>> I don't have any clue on how this could be handled...
>
> Here is what I have managed to work out. Apologies for answering in
> org syntax :)

Hey this is great.  I ♥ typesetting :)

-- 
Bastien

Re: XHTML export -   etc.

[William Henney]

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

On 11/3/07, Bastien <bzg@altern.org> wrote:
> "William Henney" <whenney@gmail.com> writes:
> >
> > Here is what I have managed to work out. Apologies for answering in
> > org syntax :)
>
> Hey this is great.  I ♥ typesetting :)
>

Me too. And the possibilities for new smilies are endless:

•⋖
⌣

Cheers

Will


-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: XHTML export -   etc.

[Bastien]

"William Henney" <whenney@gmail.com> writes:

>> I'm not sure about the the last two columns.  Maybe it's simpler to
>> let -- and --- be -- and --- in HTML output as well.
>
> Shouldn't they be `&endash;' and `&emdash;' in HTML?
> http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_Symbols

Yes, thanks.  So we have now:

| Org | HTML    | LaTeX |
|-----+---------+-------|
| \-  | &shy;   | \-    |
| " " | &nbsp;  | ~     |
| --  | &ndash; | --    |
| --- | &mdash; | ---   |

(Please note that you can already obtain the HTML &shy; &nbsp; and
friends by inserting \shy \nbsp etc.  But not having to bother about
special character names in the source file is certainly the right
direction.)

I removed the idea of using the tilde character `~' for inerting a
non-breakable space in Org source file because:

- this is the function of Emacs non-breakable space character ` '

- the tilde char can be used in several other places, and we need to
  keep the handling of special characters as simple as possible...

- this seems too close to the LaTeX convention.

So now: do people think this conversion table is okay?  Too complex?
Incomplete?  Unnecessary?

-- 
Bastien

Re: XHTML export -   etc.

[Bastien]

Adam Spiers <orgmode@adamspiers.org> writes:

>> You can use \nbsp in Org source file, it'll be converted to &nbsp;
>> smoothly.
>
> Perfect, thanks!  Probably worth adding this to the docs?

Yes, you're right.

I guess (info "(org)Enhancing text") is the appropriate place for that.

-- 
Bastien

Re: XHTML export - customizing via local variables

[Bastien]

Hi Adam,

Adam Spiers <orgmode@adamspiers.org> writes:

> Is org-export-html-style the only aspect of XHTML export which can be
> customized via Local Variables?  It would be nice to be able to
> override org-export-html-table-tag per-file, for instance, but it
> didn't work for me and I wasn't clever enough to figure out how the
> code works from a quick glance.  

A buffer-local value for `org-export-html-table-tag' won't be of any
help here, so you can't blame yourself :)

Perhaps something like #+TABLE_TAG: would be useful so that
`org-export-plist-vars' can know about a :table-tag property.

I don't know -- Carsten would be of a wiser advice on this.

-- 
Bastien