[Feature Request] - Furigana - Yomigana - Ruby

[Feature Request] - Furigana - Yomigana - Ruby

[T.T.N.]

Hi,

So this is my first try to post to the mailing list. I Love Orgmode, you 
guys are the best!

I would like to use orgmode to capture japanese text to later export to 
latex, html and epub.
For japanese symbols, sometimes the pronounciation is put in smaller 
letters above the symbol to help the reader.
These are called ruby in general in typesetting (in japanese, they are 
also called furigana/yomigana, which I put in the header so not 
everybody thinks of the programming language..)
http://en.wikipedia.org/wiki/Furigana

In Latex, using CJK and ruby packages, This exports ok.
(A problem being that japanese text in headers doesn't. But i guess 
that's another (and rather Latex, not orgmode-specific) topic.

Now, my feature request would be to make the html exporter interpret the 
latex command
\ruby{symbol}{reading}
as:
<ruby> symbol <rp>(</rp><rt>reading</rt><rp>)</rp> <\ruby>

as suggested here, for parentheses on non-ruby supporting browsers:
http://xahlee.info/js/html5_ruby_tag.html


For the org-mode file (you might see some blank squares if you have no 
japanese support):
Here a minimal working example for export:

###
#+LATEX_HEADER: \usepackage[CJK, overlap]{ruby}
#+LATEX_HEADER: \usepackage{CJK} \end{CJK}
#+LATEX \begin{CJK}{UTF8}{min}

"\ruby{東}{ひがし}アジア" means east asia in japanese
#+LATEX \end{CJK}
###


All the best, and keep on rocking my world in plain text! =)

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Torsten Wagner]

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

Hi Tristan,

this feature request seems simple to implement on one side. However, it
opens a question how to deal with those in general.
\ruby{東} is a very specific command of the CJK package.
If this get's implemented in the standard html exporter, other very special
commands might need to follow. That could easily go into a nightmare. I do
not have a detailed view how the exporters work now, thus, it is a
interesting question I want to ask here: How should specific needs for
exporting (like Tristans) be embedded in the future.

People could fork exporters. Creating e.g. a HTML-CJK exporter.
Even better would be to have exporter modules which could be loaded by
users.

#+HTML_MODULES CJK,

However, I believe that for many users, the special cases are not very
frequent and complex. Might it be possible to create a very simple syntax
for exporting rules which could be either in those above modules or
directly within the file written by the user themself?

#+HTML_USER_RULE   \ruby{$1}{$2}, <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp>
<\ruby>

Would like to hear what other think about that.

Greetings

Torsten



On 28 May 2013 00:41, T.T.N. <tristan.nakagawa@gmail.com> wrote:

> Hi,
>
> So this is my first try to post to the mailing list. I Love Orgmode, you
> guys are the best!
>
> I would like to use orgmode to capture japanese text to later export to
> latex, html and epub.
> For japanese symbols, sometimes the pronounciation is put in smaller
> letters above the symbol to help the reader.
> These are called ruby in general in typesetting (in japanese, they are
> also called furigana/yomigana, which I put in the header so not everybody
> thinks of the programming language..)
> http://en.wikipedia.org/wiki/**Furigana<http://en.wikipedia.org/wiki/Furigana>
>
> In Latex, using CJK and ruby packages, This exports ok.
> (A problem being that japanese text in headers doesn't. But i guess that's
> another (and rather Latex, not orgmode-specific) topic.
>
> Now, my feature request would be to make the html exporter interpret the
> latex command
> \ruby{symbol}{reading}
> as:
> <ruby> symbol <rp>(</rp><rt>reading</rt><rp>**)</rp> <\ruby>
>
> as suggested here, for parentheses on non-ruby supporting browsers:
> http://xahlee.info/js/html5_**ruby_tag.html<http://xahlee.info/js/html5_ruby_tag.html>
>
>
> For the org-mode file (you might see some blank squares if you have no
> japanese support):
> Here a minimal working example for export:
>
> ###
> #+LATEX_HEADER: \usepackage[CJK, overlap]{ruby}
> #+LATEX_HEADER: \usepackage{CJK} \end{CJK}
> #+LATEX \begin{CJK}{UTF8}{min}
>
> "\ruby{東}{ひがし}アジア" means east asia in japanese
> #+LATEX \end{CJK}
> ###
>
>
> All the best, and keep on rocking my world in plain text! =)
>
>
>
>
>
>
>

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

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Suvayu Ali]

On Tue, May 28, 2013 at 03:00:40PM +0200, Torsten Wagner wrote:
> 
> However, I believe that for many users, the special cases are not very
> frequent and complex. Might it be possible to create a very simple syntax
> for exporting rules which could be either in those above modules or
> directly within the file written by the user themself?
> 
> #+HTML_USER_RULE   \ruby{$1}{$2}, <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>

Isn't this very similar to a #+MACRO definition but with a different
syntax and only for the HTML backend?

Maybe we could allow backend specific macro expansion definitions.
Something like:

  #+HTML_MACRO: ruby <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>
  #+LATEX_MACRO: ruby \ruby{$1}{$2}

  Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
  different backends.

What do you think?

Cheers,

PS: Actually on second thought it is probably possible to handle this
    with filters although I failed to find the appropriate filter.

    So you could try:

      #+MACRO: ruby <cookie><$1><$2></cookie>

    And the filter can translate the cookie to the appropriate backend
    specific expansion.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Suvayu Ali]

On Tue, May 28, 2013 at 05:01:56PM +0200, Suvayu Ali wrote:
> 
> PS: Actually on second thought it is probably possible to handle this
>     with filters although I failed to find the appropriate filter.
> 
>     So you could try:
> 
>       #+MACRO: ruby <cookie><$1><$2></cookie>
> 
>     And the filter can translate the cookie to the appropriate backend
>     specific expansion.

Maybe this will work (untested): org-export-filter-paragraph-functions.  The
assumption is you will use the macro by itself in a paragraph and not on
structural elements like headlines.

  (defun sa-latex-subscript (contents backend info)
    (when (eq backend 'latex)
      (replace-regexp-in-string "<cookie><\\([^>]+\\)><\\([^>]+\\)></cookie>"
                                "\\\\ruby{\\1}{\\2}" contents))
    (when (eq backend 'html)
      (replace-regexp-in-string "<cookie><\\([^>]+\\)><\\([^>]+\\)></cookie>"
                                "<ruby>\\1<rp>(</rp><rt>\\2</rt><rp>)</rp> <\ruby>"
                                contents)))

I did not check the regular expressions at all, so please test and let us know.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Thomas S. Dye]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Tue, May 28, 2013 at 03:00:40PM +0200, Torsten Wagner wrote:
>> 
>> However, I believe that for many users, the special cases are not very
>> frequent and complex. Might it be possible to create a very simple syntax
>> for exporting rules which could be either in those above modules or
>> directly within the file written by the user themself?
>> 
>> #+HTML_USER_RULE \ruby{$1}{$2}, <ruby> $1
>> <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>
>
> Isn't this very similar to a #+MACRO definition but with a different
> syntax and only for the HTML backend?
>
> Maybe we could allow backend specific macro expansion definitions.
> Something like:
>
>   #+HTML_MACRO: ruby <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>
>   #+LATEX_MACRO: ruby \ruby{$1}{$2}
>
>   Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
>   different backends.
>
> What do you think?
>
> Cheers,
>
> PS: Actually on second thought it is probably possible to handle this
>     with filters although I failed to find the appropriate filter.
>
>     So you could try:
>
>       #+MACRO: ruby <cookie><$1><$2></cookie>
>
>     And the filter can translate the cookie to the appropriate backend
>     specific expansion.

Another option would be a link:

  (org-add-link-type
   "ruby" nil
   (lambda (path desc format)
     (cond
      ((eq format 'html)
       (format "<ruby> %s <rp>(</rp><rt>%s</rt><rp>)</rp> <\ruby>" path desc))
      ((memq format '(beamer latex))
           (format "\\ruby{%s}{%s}" path desc)))))


[[ruby:東][ひがし]]

(untested)

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Christian Moe]

Suvayu Ali writes:

> Maybe we could allow backend specific macro expansion definitions.
> Something like:
>
>   #+HTML_MACRO: ruby <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>
>   #+LATEX_MACRO: ruby \ruby{$1}{$2}
>
>   Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
>   different backends.
>
> What do you think?

Existing (8.0) syntax already offers a way to achieve this using export
snippets, which now allow and require you to specify backends. To
recast your example:

  #+macro: ruby @@html:<ruby> $1<rp>(</rp><rt>$2</rt><rp>)</rp> </ruby>@@@@latex:\ruby{$1}{$2}@@

  Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
  different backends.

Note: I have no idea if the above actually results in appropriate
rubies, it's just to demonstrate the basic principle that you can write:

  #+macro: foo @@html:<foo>$1</foo>@@@@latex:\foo{$1}@@

Yours,
Christian

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Suvayu Ali]

On Wed, May 29, 2013 at 09:20:52AM +0200, Christian Moe wrote:
> 
> Suvayu Ali writes:
> 
> > Maybe we could allow backend specific macro expansion definitions.
> > Something like:
> >
> >   #+HTML_MACRO: ruby <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp> <\ruby>
> >   #+LATEX_MACRO: ruby \ruby{$1}{$2}
> >
> >   Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
> >   different backends.
> >
> > What do you think?
> 
> Existing (8.0) syntax already offers a way to achieve this using export
> snippets, which now allow and require you to specify backends. To
> recast your example:
> 
>   #+macro: ruby @@html:<ruby> $1<rp>(</rp><rt>$2</rt><rp>)</rp> </ruby>@@@@latex:\ruby{$1}{$2}@@
> 
>   Then {{{ruby(東,ひがし)}}} will be expanded appropriately for
>   different backends.
> 

You are right!  I had completely forgotten about snippets.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Tristan Nakagawa]

Hi Torsten,

Thanks for the input,
To have definable export rules would indeed be great, to increase
flexibility while keeping the base exporter simple and lightweight.

I agree that this is somewhat specific, however, I believe that
globally, this is not unfrequent, and will become quite frequent soon:

There is, for example, the ease of drafting and flexibility of output
(print quality pdf and epub-convertible html),so orgmode can be used so
well outside of the traditional latex-technical and science paper realms
for novels, books, blog-posts (org2blog).

And imagining the number of people on this planet speaking Chinese and
japanese, Korean, Thai, and other languages I am not even aware of that
use rubys to help reading, the number of people learning these
languages, creating two-language blog-posts, textbooks, etc etc.

It might take a while before all browsers support the tags (my Firefox
doesnt even yet), but for epub&pdf creation, this would already be great!


(Just to back up the feature-request beyond definately needed and
appreciated discussion about how and if to make the exporter more
modular or costumizable)  ..  =)

best,
Tristan




On 2013-05-28 15:00, Torsten Wagner wrote:
> Hi Tristan,
> 
> this feature request seems simple to implement on one side. However, it
> opens a question how to deal with those in general.
> \ruby{東} is a very specific command of the CJK package.
> If this get's implemented in the standard html exporter, other very special
> commands might need to follow. That could easily go into a nightmare. I do
> not have a detailed view how the exporters work now, thus, it is a
> interesting question I want to ask here: How should specific needs for
> exporting (like Tristans) be embedded in the future.
> 
> People could fork exporters. Creating e.g. a HTML-CJK exporter.
> Even better would be to have exporter modules which could be loaded by
> users.
> 
> #+HTML_MODULES CJK,
> 
> However, I believe that for many users, the special cases are not very
> frequent and complex. Might it be possible to create a very simple syntax
> for exporting rules which could be either in those above modules or
> directly within the file written by the user themself?
> 
> #+HTML_USER_RULE   \ruby{$1}{$2}, <ruby> $1 <rp>(</rp><rt>$2</rt><rp>)</rp>
> <\ruby>
> 
> Would like to hear what other think about that.
> 
> Greetings
> 
> Torsten
> 
> 
> 
> On 28 May 2013 00:41, T.T.N. <tristan.nakagawa@gmail.com> wrote:
> 
>> Hi,
>>
>> So this is my first try to post to the mailing list. I Love Orgmode, you
>> guys are the best!
>>
>> I would like to use orgmode to capture japanese text to later export to
>> latex, html and epub.
>> For japanese symbols, sometimes the pronounciation is put in smaller
>> letters above the symbol to help the reader.
>> These are called ruby in general in typesetting (in japanese, they are
>> also called furigana/yomigana, which I put in the header so not everybody
>> thinks of the programming language..)
>> http://en.wikipedia.org/wiki/**Furigana<http://en.wikipedia.org/wiki/Furigana>
>>
>> In Latex, using CJK and ruby packages, This exports ok.
>> (A problem being that japanese text in headers doesn't. But i guess that's
>> another (and rather Latex, not orgmode-specific) topic.
>>
>> Now, my feature request would be to make the html exporter interpret the
>> latex command
>> \ruby{symbol}{reading}
>> as:
>> <ruby> symbol <rp>(</rp><rt>reading</rt><rp>**)</rp> <\ruby>
>>
>> as suggested here, for parentheses on non-ruby supporting browsers:
>> http://xahlee.info/js/html5_**ruby_tag.html<http://xahlee.info/js/html5_ruby_tag.html>
>>
>>
>> For the org-mode file (you might see some blank squares if you have no
>> japanese support):
>> Here a minimal working example for export:
>>
>> ###
>> #+LATEX_HEADER: \usepackage[CJK, overlap]{ruby}
>> #+LATEX_HEADER: \usepackage{CJK} \end{CJK}
>> #+LATEX \begin{CJK}{UTF8}{min}
>>
>> "\ruby{東}{ひがし}アジア" means east asia in japanese
>> #+LATEX \end{CJK}
>> ###
>>
>>
>> All the best, and keep on rocking my world in plain text! =)
>>
>>
>>
>>
>>
>>
>>
> 

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Torsten Wagner]

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

Hi Tristan,

don't get me wrong. Being married to a Chinese and lived in Japan for many
years I know exactly what you are talking about ;)
I just feel it needs some clean and well defined way how to implement all
those different export features without cluttering the basic exporters.

Somehow the same reason why we use a zillion of packages for LaTeX itself.
I just got aware of that, by reading your post. Recently, we got new
exporters thus, should be the next step to get/define modules for those
exporters or even being able to write your own rules easily within the file?

The 2 worst case scenarios IMHO...
the exporters gets more and more extended getting harder to maintain and
error prome
people start forking the exporters html-cjk, html-hangul, html-netscape ;)

Thus, I would love to hear what others might think is the most clean way to
add your feature request and be prepared for the many many others in the
future.

Greetings

Torsten









On 28 May 2013 17:43, Tristan Nakagawa <tristan.nakagawa@gmail.com> wrote:

> Hi Torsten,
>
> Thanks for the input,
> To have definable export rules would indeed be great, to increase
> flexibility while keeping the base exporter simple and lightweight.
>
> I agree that this is somewhat specific, however, I believe that
> globally, this is not unfrequent, and will become quite frequent soon:
>
> There is, for example, the ease of drafting and flexibility of output
> (print quality pdf and epub-convertible html),so orgmode can be used so
> well outside of the traditional latex-technical and science paper realms
> for novels, books, blog-posts (org2blog).
>
> And imagining the number of people on this planet speaking Chinese and
> japanese, Korean, Thai, and other languages I am not even aware of that
> use rubys to help reading, the number of people learning these
> languages, creating two-language blog-posts, textbooks, etc etc.
>
> It might take a while before all browsers support the tags (my Firefox
> doesnt even yet), but for epub&pdf creation, this would already be great!
>
>
> (Just to back up the feature-request beyond definately needed and
> appreciated discussion about how and if to make the exporter more
> modular or costumizable)  ..  =)
>
> best,
> Tristan
>
>
>
>
> On 2013-05-28 15:00, Torsten Wagner wrote:
> > Hi Tristan,
> >
> > this feature request seems simple to implement on one side. However, it
> > opens a question how to deal with those in general.
> > \ruby{東} is a very specific command of the CJK package.
> > If this get's implemented in the standard html exporter, other very
> special
> > commands might need to follow. That could easily go into a nightmare. I
> do
> > not have a detailed view how the exporters work now, thus, it is a
> > interesting question I want to ask here: How should specific needs for
> > exporting (like Tristans) be embedded in the future.
> >
> > People could fork exporters. Creating e.g. a HTML-CJK exporter.
> > Even better would be to have exporter modules which could be loaded by
> > users.
> >
> > #+HTML_MODULES CJK,
> >
> > However, I believe that for many users, the special cases are not very
> > frequent and complex. Might it be possible to create a very simple syntax
> > for exporting rules which could be either in those above modules or
> > directly within the file written by the user themself?
> >
> > #+HTML_USER_RULE   \ruby{$1}{$2}, <ruby> $1
> <rp>(</rp><rt>$2</rt><rp>)</rp>
> > <\ruby>
> >
> > Would like to hear what other think about that.
> >
> > Greetings
> >
> > Torsten
> >
> >
> >
> > On 28 May 2013 00:41, T.T.N. <tristan.nakagawa@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> So this is my first try to post to the mailing list. I Love Orgmode, you
> >> guys are the best!
> >>
> >> I would like to use orgmode to capture japanese text to later export to
> >> latex, html and epub.
> >> For japanese symbols, sometimes the pronounciation is put in smaller
> >> letters above the symbol to help the reader.
> >> These are called ruby in general in typesetting (in japanese, they are
> >> also called furigana/yomigana, which I put in the header so not
> everybody
> >> thinks of the programming language..)
> >> http://en.wikipedia.org/wiki/**Furigana<
> http://en.wikipedia.org/wiki/Furigana>
> >>
> >> In Latex, using CJK and ruby packages, This exports ok.
> >> (A problem being that japanese text in headers doesn't. But i guess
> that's
> >> another (and rather Latex, not orgmode-specific) topic.
> >>
> >> Now, my feature request would be to make the html exporter interpret the
> >> latex command
> >> \ruby{symbol}{reading}
> >> as:
> >> <ruby> symbol <rp>(</rp><rt>reading</rt><rp>**)</rp> <\ruby>
> >>
> >> as suggested here, for parentheses on non-ruby supporting browsers:
> >> http://xahlee.info/js/html5_**ruby_tag.html<
> http://xahlee.info/js/html5_ruby_tag.html>
> >>
> >>
> >> For the org-mode file (you might see some blank squares if you have no
> >> japanese support):
> >> Here a minimal working example for export:
> >>
> >> ###
> >> #+LATEX_HEADER: \usepackage[CJK, overlap]{ruby}
> >> #+LATEX_HEADER: \usepackage{CJK} \end{CJK}
> >> #+LATEX \begin{CJK}{UTF8}{min}
> >>
> >> "\ruby{東}{ひがし}アジア" means east asia in japanese
> >> #+LATEX \end{CJK}
> >> ###
> >>
> >>
> >> All the best, and keep on rocking my world in plain text! =)
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>

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

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Tristan Nakagawa]

Hi,

For some reason, I don't get the follow-ups per mail, neither can I
respond via the gmane interface =(.
Right now I don't have time to figure it out, so I will let you know
here for all solutions:

Thanks, all, very nice! In fact, pure awesomeness!

And it's brand new. I didn't know about it before, and now found the
info that you mentioned it:
http://orgmode.org/worg/org-8.0.html

I had just looked with my old emacs version in the manual, not the
upgrade release notes..
(I had 7.9.3d, I had updated via the emacs package manager, but
unsuccessful due to loading some orgmode functions at startup in emacs.
after renaming .emacs and deleting the old org, the package manager
successfully updated.)


I didn't get Suvayus solution in the old version, i suspect it might
work in the new version, but since the snippet version (see below)
doesnt involve changing the backend for every macro, i didn't follow up
on it

Thomas' ruby link solution works nicely (except the closing tag should
be </ruby>, not <\ruby>, and works for both for latex and html.

The only downside is that you won't see the symbol in the original
orgfile or in section headers in the export, just the reading, but that
is a very minor annoyance and this is a very nice elegant solution with
a very readable source org file.
(I don't guess the link could be redefined to switch reading and symbol
around?)

Christians suggestion with snippets works great, both for html and pdf
via latex; even in section headers.
(it took me reading the 8.0 upgrade info to understand we were talking
about the <at> symbol, not literally "<at>" in the code.

Thanks all for your help =)
And Torsten, I guess this also lines out the solution on how to
implement specific features without cluttering the basic exporters.

m_ _m

best,
Tristan


On 2013-05-28 19:36, Torsten Wagner wrote:
> Hi Tristan,
> 
> don't get me wrong. Being married to a Chinese and lived in Japan for many
> years I know exactly what you are talking about ;)
> I just feel it needs some clean and well defined way how to implement all
> those different export features without cluttering the basic exporters.
> 
> Somehow the same reason why we use a zillion of packages for LaTeX itself.
> I just got aware of that, by reading your post. Recently, we got new
> exporters thus, should be the next step to get/define modules for those
> exporters or even being able to write your own rules easily within the file?
> 
> The 2 worst case scenarios IMHO...
> the exporters gets more and more extended getting harder to maintain and
> error prome
> people start forking the exporters html-cjk, html-hangul, html-netscape ;)
> 
> Thus, I would love to hear what others might think is the most clean way to
> add your feature request and be prepared for the many many others in the
> future.
> 
> Greetings
> 
> Torsten
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 28 May 2013 17:43, Tristan Nakagawa <tristan.nakagawa@gmail.com> wrote:
> 
>> Hi Torsten,
>>
>> Thanks for the input,
>> To have definable export rules would indeed be great, to increase
>> flexibility while keeping the base exporter simple and lightweight.
>>
>> I agree that this is somewhat specific, however, I believe that
>> globally, this is not unfrequent, and will become quite frequent soon:
>>
>> There is, for example, the ease of drafting and flexibility of output
>> (print quality pdf and epub-convertible html),so orgmode can be used so
>> well outside of the traditional latex-technical and science paper realms
>> for novels, books, blog-posts (org2blog).
>>
>> And imagining the number of people on this planet speaking Chinese and
>> japanese, Korean, Thai, and other languages I am not even aware of that
>> use rubys to help reading, the number of people learning these
>> languages, creating two-language blog-posts, textbooks, etc etc.
>>
>> It might take a while before all browsers support the tags (my Firefox
>> doesnt even yet), but for epub&pdf creation, this would already be great!
>>
>>
>> (Just to back up the feature-request beyond definately needed and
>> appreciated discussion about how and if to make the exporter more
>> modular or costumizable)  ..  =)
>>
>> best,
>> Tristan
>>
>>
>>
>>
>> On 2013-05-28 15:00, Torsten Wagner wrote:
>>> Hi Tristan,
>>>
>>> this feature request seems simple to implement on one side. However, it
>>> opens a question how to deal with those in general.
>>> \ruby{東} is a very specific command of the CJK package.
>>> If this get's implemented in the standard html exporter, other very
>> special
>>> commands might need to follow. That could easily go into a nightmare. I
>> do
>>> not have a detailed view how the exporters work now, thus, it is a
>>> interesting question I want to ask here: How should specific needs for
>>> exporting (like Tristans) be embedded in the future.
>>>
>>> People could fork exporters. Creating e.g. a HTML-CJK exporter.
>>> Even better would be to have exporter modules which could be loaded by
>>> users.
>>>
>>> #+HTML_MODULES CJK,
>>>
>>> However, I believe that for many users, the special cases are not very
>>> frequent and complex. Might it be possible to create a very simple syntax
>>> for exporting rules which could be either in those above modules or
>>> directly within the file written by the user themself?
>>>
>>> #+HTML_USER_RULE   \ruby{$1}{$2}, <ruby> $1
>> <rp>(</rp><rt>$2</rt><rp>)</rp>
>>> <\ruby>
>>>
>>> Would like to hear what other think about that.
>>>
>>> Greetings
>>>
>>> Torsten
>>>
>>>
>>>
>>> On 28 May 2013 00:41, T.T.N. <tristan.nakagawa@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> So this is my first try to post to the mailing list. I Love Orgmode, you
>>>> guys are the best!
>>>>
>>>> I would like to use orgmode to capture japanese text to later export to
>>>> latex, html and epub.
>>>> For japanese symbols, sometimes the pronounciation is put in smaller
>>>> letters above the symbol to help the reader.
>>>> These are called ruby in general in typesetting (in japanese, they are
>>>> also called furigana/yomigana, which I put in the header so not
>> everybody
>>>> thinks of the programming language..)
>>>> http://en.wikipedia.org/wiki/**Furigana<
>> http://en.wikipedia.org/wiki/Furigana>
>>>>
>>>> In Latex, using CJK and ruby packages, This exports ok.
>>>> (A problem being that japanese text in headers doesn't. But i guess
>> that's
>>>> another (and rather Latex, not orgmode-specific) topic.
>>>>
>>>> Now, my feature request would be to make the html exporter interpret the
>>>> latex command
>>>> \ruby{symbol}{reading}
>>>> as:
>>>> <ruby> symbol <rp>(</rp><rt>reading</rt><rp>**)</rp> <\ruby>
>>>>
>>>> as suggested here, for parentheses on non-ruby supporting browsers:
>>>> http://xahlee.info/js/html5_**ruby_tag.html<
>> http://xahlee.info/js/html5_ruby_tag.html>
>>>>
>>>>
>>>> For the org-mode file (you might see some blank squares if you have no
>>>> japanese support):
>>>> Here a minimal working example for export:
>>>>
>>>> ###
>>>> #+LATEX_HEADER: \usepackage[CJK, overlap]{ruby}
>>>> #+LATEX_HEADER: \usepackage{CJK} \end{CJK}
>>>> #+LATEX \begin{CJK}{UTF8}{min}
>>>>
>>>> "\ruby{東}{ひがし}アジア" means east asia in japanese
>>>> #+LATEX \end{CJK}
>>>> ###
>>>>
>>>>
>>>> All the best, and keep on rocking my world in plain text! =)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Christian Moe]

Tristan Nakagawa writes:

> Christians suggestion with snippets works great, both for html and pdf
> via latex; even in section headers.
> (it took me reading the 8.0 upgrade info to understand we were talking
> about the <at> symbol, not literally "<at>" in the code.

Hi, glad to hear it worked out. 

Did you see the code as literally "<at>"? I did use the symbol, so this
must be the work of some overzealous email-address obfuscating
software. That's useful to know for another time if this comes up on the
list.

Yours,
Christian

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Suvayu Ali]

On Wed, May 29, 2013 at 06:46:59PM +0200, Christian Moe wrote:
> 
> Tristan Nakagawa writes:
> 
> > Christians suggestion with snippets works great, both for html and pdf
> > via latex; even in section headers.
> > (it took me reading the 8.0 upgrade info to understand we were talking
> > about the <at> symbol, not literally "<at>" in the code.
> 
> Hi, glad to hear it worked out. 
> 
> Did you see the code as literally "<at>"? I did use the symbol, so this
> must be the work of some overzealous email-address obfuscating
> software. That's useful to know for another time if this comes up on the
> list.

I believe gmane does that.  :-p

-- 
Suvayu

Open source is the future. It sets us free.

Re: [Feature Request] - Furigana - Yomigana - Ruby

[Suvayu Ali]

Hello Tristan,

Since you broought up Org versions, I thought it would be pertinent to
classify the version dependence of the possible solutions.

On Wed, May 29, 2013 at 05:20:21PM +0200, Tristan Nakagawa wrote:
> 
> I didn't get Suvayus solution in the old version, i suspect it might
> work in the new version, but since the snippet version (see below)
> doesnt involve changing the backend for every macro, i didn't follow up
> on it

My solution with filters is only possible with Org 8.x or above.  Also a
minor nit-pick, my solution goes into your emacs setup; the backends
stay as it is.  But I would say Christian's solution is much more
elegant and portable in the sense that the Org file is self contained
and independent of the setup.

> Thomas' ruby link solution works nicely (except the closing tag should
> be </ruby>, not <\ruby>, and works for both for latex and html.
>
> The only downside is that you won't see the symbol in the original
> orgfile or in section headers in the export, just the reading, but that
> is a very minor annoyance and this is a very nice elegant solution with
> a very readable source org file.
> (I don't guess the link could be redefined to switch reading and symbol
> around?)

Tom's solution is probably the most portable across different Org
versions.

> Christians suggestion with snippets works great, both for html and pdf
> via latex; even in section headers.
> (it took me reading the 8.0 upgrade info to understand we were talking
> about the <at> symbol, not literally "<at>" in the code.

This one again is a Org 8.x or above solution.

Hope you can adapt either of these to your needs.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.