Re: [O] [ox, patch] Add #+SUBTITLE

2015-03-28 Thread Melanie Bacou
 commonly found or required in any type of 
publication or technical document.


Would be useful to hear others' opinions.

--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] [ox, patch] Add #+SUBTITLE

2015-03-25 Thread Melanie Bacou
I would indeed go further and suggest adding the following once and for 
all as common ox features:


#+TITLE
#+SUBTITLE
#+DATE
#+AUTHORS (support multiple)
#+EMAILS (1 per author)
#+AFFILIATIONS (1 per author)
#+CLASSIFICATION (e.g. ACM, JEL, Dublin Core, your corporate 
classification, etc.)

#+KEYWORDS
#+DESCRIPTION
#+REVISION

This is not so much about what back-ends currently support (that's 
irrelevant in my view), it's about what minimum meta information is 
needed to publish and maintain meaningful documents. The use of these 
meta fields encourage good publishing practices, and all back-ends 
should eventually support all or a subset of these. Most LaTeX journal 
classes do. HTML would support these at least as meta content= tags. 
ODT and DOCX can support all using templates.


--Mel.



On 3/24/2015 5:05 AM, Nicolas Goaziou wrote:

Rasmus ras...@gmx.us writes:


Nicolas Goaziou m...@nicolasgoaziou.fr writes:


However, I think porting this feature to back-ends that do not support
it out of the box is pushing too hard.


In the patch there's ox-latex where e.g. KOMA-Script has as
subtitle-macro.  ox-html, ox-ascii, ox-odt all are pretty liberate formats
in terms of what elements are supported.


My concern is not technical. You can indeed tweak ox-html, ox-ascii
and ox-odt to support many things.

I just don't want to make it too difficult for back-end developers, and
maintainers, to keep up with compatibility with other back-ends, while
still allowing existing back-ends to extend (almost) freely.

E.g., when creating a new export back-end, it is quite obvious that one
will need to handle TITLE, DATE, AUTHOR and EMAIL somehow. Now, if you
request handlers for SUBTITLE, KEYWORDS and DESCRIPTION, it becomes more
tedious to achieve the task.

This is not really about SUBTITLE, but, sooner or later, we will have to
draw a line between common features ensuring compatibility between
back-ends and specific ones. The cost of the former is some orders of
magnitude higher.


This is why I suggested to move KEYWORD and DESCRIPTION outside of
ox.el, as they cannot be ported to all back-ends without relying on
dubious markup.


Yeah, I still have a patch for that...  I still have to do the
documentation changes.


Unless we decide that KEYWORD and DESCRIPTION should move to the common
features discussed above. In this case, they stay in ox.el and all
major back-ends are expected to handle them. WDYT?


Now, if SUBTITLE is a feature desperately needed everywhere, which can
be discussed, it should be moved to ox.el and probably
`org-element-document-keywords'. IMO, this is not necessary. SUBTITLE
should be kept for back-ends that can handle it.


IMO it is.


See above. I don't mind much, as long as we eventually stop
compatibility hell at some point.

If you think it's important, then go ahead.


The only place where there's a hack is in ox-latex and
that's cause article is the default class.  If you prefer, it can just
output to the \subtitle{·} by default and say it's KOMA-script only.  That
seems harsh, though.


I agree it would be harsh.


As a side note, ox-texinfo doesn't parse SUBTITLE. You might want to
change it and update manual accordingly.


The patch doesn't touch ox-texinfo.  I don't mind fixing that bug,
though.


It isn't a bug at the moment, since that feature is documented in the
manual. However, it will become inconsistent if other back-ends parse
SUBTITLE.


Regards,




--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org



Re: [O] [ox, patch] Add #+SUBTITLE

2015-03-25 Thread Melanie Bacou

I forgot:

#+COPYRIGHT


On 3/25/2015 10:36 PM, Melanie Bacou wrote:

I would indeed go further and suggest adding the following once and for
all as common ox features:

#+TITLE
#+SUBTITLE
#+DATE
#+AUTHORS (support multiple)
#+EMAILS (1 per author)
#+AFFILIATIONS (1 per author)
#+CLASSIFICATION (e.g. ACM, JEL, Dublin Core, your corporate
classification, etc.)
#+KEYWORDS
#+DESCRIPTION
#+REVISION

This is not so much about what back-ends currently support (that's
irrelevant in my view), it's about what minimum meta information is
needed to publish and maintain meaningful documents. The use of these
meta fields encourage good publishing practices, and all back-ends
should eventually support all or a subset of these. Most LaTeX journal
classes do. HTML would support these at least as meta content= tags.
ODT and DOCX can support all using templates.

--Mel.



On 3/24/2015 5:05 AM, Nicolas Goaziou wrote:

Rasmus ras...@gmx.us writes:


Nicolas Goaziou m...@nicolasgoaziou.fr writes:


However, I think porting this feature to back-ends that do not support
it out of the box is pushing too hard.


In the patch there's ox-latex where e.g. KOMA-Script has as
subtitle-macro.  ox-html, ox-ascii, ox-odt all are pretty liberate
formats
in terms of what elements are supported.


My concern is not technical. You can indeed tweak ox-html, ox-ascii
and ox-odt to support many things.

I just don't want to make it too difficult for back-end developers, and
maintainers, to keep up with compatibility with other back-ends, while
still allowing existing back-ends to extend (almost) freely.

E.g., when creating a new export back-end, it is quite obvious that one
will need to handle TITLE, DATE, AUTHOR and EMAIL somehow. Now, if you
request handlers for SUBTITLE, KEYWORDS and DESCRIPTION, it becomes more
tedious to achieve the task.

This is not really about SUBTITLE, but, sooner or later, we will have to
draw a line between common features ensuring compatibility between
back-ends and specific ones. The cost of the former is some orders of
magnitude higher.


This is why I suggested to move KEYWORD and DESCRIPTION outside of
ox.el, as they cannot be ported to all back-ends without relying on
dubious markup.


Yeah, I still have a patch for that...  I still have to do the
documentation changes.


Unless we decide that KEYWORD and DESCRIPTION should move to the common
features discussed above. In this case, they stay in ox.el and all
major back-ends are expected to handle them. WDYT?


Now, if SUBTITLE is a feature desperately needed everywhere, which can
be discussed, it should be moved to ox.el and probably
`org-element-document-keywords'. IMO, this is not necessary. SUBTITLE
should be kept for back-ends that can handle it.


IMO it is.


See above. I don't mind much, as long as we eventually stop
compatibility hell at some point.

If you think it's important, then go ahead.


The only place where there's a hack is in ox-latex and
that's cause article is the default class.  If you prefer, it can just
output to the \subtitle{·} by default and say it's KOMA-script only.
That
seems harsh, though.


I agree it would be harsh.


As a side note, ox-texinfo doesn't parse SUBTITLE. You might want to
change it and update manual accordingly.


The patch doesn't touch ox-texinfo.  I don't mind fixing that bug,
though.


It isn't a bug at the moment, since that feature is documented in the
manual. However, it will become inconsistent if other back-ends parse
SUBTITLE.


Regards,






--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] [ox, patch] Add #+SUBTITLE

2015-03-25 Thread Melanie Bacou
Here is how titles and subtitles are supported in Bootstrap (the most 
popular HTML/CSS/JS framework):


div class=page-header
  h1This would be the title smalland this the subtitle/small/h1
/div

ref: http://getbootstrap.com/components/#page-header

Another commonly seen approach is this (many web CMS use this pseudo 
standard):


h1 class=titleMy Title/h1
h2 class=subtitleMy Subtitle/h1

--Mel.



On 3/22/2015 9:17 PM, Eric Abrahamsen wrote:

Rasmus ras...@gmx.us writes:


Eric Abrahamsen e...@ericabrahamsen.net writes:


Rasmus ras...@gmx.us writes:

In ox-html, You might consider wrapping the title and subtitle in an
hgroup if :html5-fancy is t. Or maybe that's going too far! Either
way, I like this.


First result on my search engine says¹ :

 Update 16th April, 2013. hgroup has now been removed from the HTML5
 specification. We are working on an article to help guide authors on
 which markup patterns they should use instead.

 Update 4th April, 2013. Please note that following this decision,
 hgroup will be removed from the HTML5 specification. As such, we don’t
 endorse using it on production sites.

I don't know anything about html, though.  Is there another element you
had in mind?  Or is the html5doctor just wrong?


Between me and html5doctor, I'd believe html5doctor. That's a shame
though! hgroup always made a lot of sense to me.





--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] [ox, patch] Add #+SUBTITLE

2015-03-20 Thread Melanie Bacou

Very nice, thanks!

On 3/20/2015 10:26 PM, Marcin Borkowski wrote:


On 2015-03-21, at 00:23, Rasmus ras...@gmx.us wrote:


This patch adds #+SUBTITLE to a couple of backends.  This property is

WDTY?


+1

Best,



--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org



Re: [O] Using org-mode to create an on-line manual for a software product

2015-02-24 Thread Melanie Bacou
Another hosted service that uses markdown (not org-mode) 
http://readthedocs.org/



On 2/24/2015 8:38 PM, Melanie Bacou wrote:

Ciaran
Have a look at ox-twbs in MELPA https://github.com/marsmining/ox-twbs.
This will publish your org files to HTML with Twitter Bootstrap CSS
support that you can customize.
There's also https://github.com/fniessen/org-html-themes
--Mel.

On 2/24/2015 9:55 AM, ciaran_mulloy wrote:

Hi!
I've been using Org-mode for creating an administration manual and user
guide for a software product in the company I work.

I output the manual to latex (nearly 170 pages).

The thought occurs to me that it might be possible to publish it to html
for use as an on-line manual that could be invoked from within the
application. Ideally it would be useful to be able to open the relevant
section in the manual in a browser.

Does anyone have practical experience, or suggestions of implementing
such a solution with org-mode? The software application runs in a CentOS
6.X environment

Regards,
Ciaran Mulloy







--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] Using org-mode to create an on-line manual for a software product

2015-02-24 Thread Melanie Bacou

Ciaran
Have a look at ox-twbs in MELPA https://github.com/marsmining/ox-twbs. 
This will publish your org files to HTML with Twitter Bootstrap CSS 
support that you can customize.

There's also https://github.com/fniessen/org-html-themes
--Mel.

On 2/24/2015 9:55 AM, ciaran_mulloy wrote:

Hi!
I've been using Org-mode for creating an administration manual and user
guide for a software product in the company I work.

I output the manual to latex (nearly 170 pages).

The thought occurs to me that it might be possible to publish it to html
for use as an on-line manual that could be invoked from within the
application. Ideally it would be useful to be able to open the relevant
section in the manual in a browser.

Does anyone have practical experience, or suggestions of implementing
such a solution with org-mode? The software application runs in a CentOS
6.X environment

Regards,
Ciaran Mulloy





--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




[O] Table notes (below table) in LaTeX?

2015-02-22 Thread Melanie Bacou

Hi,
I have a document with over 50 tables and I need to indicate data 
sources right below every table. Looking through the list I've found the 
workaround below, but it's rather syntax heavy, and places the table 
notes a little too far from the actual table.



#+CAPTION: Tanzania Segmentation (Scheme #1, 23 Segments)
#+NAME: tab:tza-seg1
#+ATTR_LATEX: :environment tabu :align lrrr
#+begin_threeparttable
| Segment   |  Area | Population |   Population |
|   |   ||  Density |
|   | /sq. km./ || /pp/sq. km./ |
|---+---++--|
| l   |   r |r |  r |
| BC, CM| 4,178 |983,305 |  235 |
| BC, CM, RS-WR | 9,057 |672,557 |   74 |
| BC, ML| 7,618 |358,121 |   47 |
| SM, CM|11,836 |  2,288,607 |  193 |
| TM|23,958 |  1,287,792 |   54 |
#+begin_tablenotes
_Source_: authors and other notes and data sources.
#+end_tablenotes
#+end_threeparttable

Instead I'd like to simply place all data sources and notes in a bottom 
row (as in the LaTeX fragment below).


\begin{table}[htb]
\caption{\label{tab:tza-seg1}Tanzania Segmentation (Scheme \#1, 23 
Segments)}

\centering
\begin{tabu}{lrrr}
\toprule
Segment  Area  Population  Population\\
  Density\\
  \emph{sq. km.}\emph{pp/sq. km.}\\
\midrule
BC, CM  4,178  983,305  235\\
BC, CM, RS-WR  9,057  672,557  74\\
BC, ML  7,618  358,121  47\\
RS-WR  13,729  412,623  30\\
RS, CM  10,959  1,059,554  97\\
SM  5,592  514,030  92\\
SM, CM  11,836  2,288,607  193\\
TM  23,958  1,287,792  54\\
\bottomrule
Source: authors and other notes and data sources.\\
\end{tabu}
\end{table}


Any tip to achieve this without using threeparttable?
Thanks, --Mel.


--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] Citation syntax: a revised proposal

2015-02-19 Thread Melanie Bacou

[cite: ...]{:type subtype}

Best,
Richard





--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




Re: [O] ox-html: stand-alone export option?

2015-02-19 Thread Melanie Bacou

Hi Rasmus, see below.

On 2/18/2015 5:39 AM, Rasmus wrote:

Hi Melanie,

Melanie Bacou m...@mbacou.com writes:


I'm using ox-html to work on shared documents with my
collaborators. We're working off a Dropbox account and converting our
org files to HTML periodically.


Cool.


Problem with all cloud storages is they don't work with relative links
inside HTML (links to external images, CSS, and JS resources).


I use git and ssh to a wm which I guess is different from cloud storages
so maybe I don't understand.  If you open the browser of my.html and you
have an absolute path to https://orgmode.org/logo.png the browser would
display it no?  Likewise for img/logo.png.  Probably I've
misunderstood. . .


You're right with Github or remote storages there's no problem (links to 
images like `./fig/my_fig.png` or local CSS or JS `./css/my_css_.css` 
are interpreted as usual. The problem is only on cloud storage services 
like Dropbox where each resource gets a unique (unknown a priori) ID. 
These make it difficult to publish HTML documents.





We would really benefit from having a stand-alone HTML exporter
feature that automatically embeds all external references into one
single HTML file, so they can be shared with Dropbox, Google Drive,
OneDrive and the likes.


Would you base64 encode images and inline code or do you have something
else in mind with single HTML file?  It's not built into Org ATM.


Yes indeed was thinking of a stand-alone option that would include 
base64 encoded images and also verbatim include all local CSS and JS in 
the document head.




In the short run maybe there's a tool that can do.  For instance, in
Firefox it will save auxiliary material when you save a page.  I don't
know if also save whatever scripts you rely on from whatever CDN far away...


Right, I looked at that too, but no true stand-alone option in FF or 
Chrome, both browsers include resources in a separate folder. Might 
spend a little more time searching for another utility.





Has this been discussed previously? Would there be any other work around?


I think there was one guy who had patch that would automatically download
external images.  Pretty neat.  I don't know if it was applied in the end.


I'd vote for this feature. In fact I believe it's now an option with 
RMarkdown/HTML documents.




—Rasmus



--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




[O] #+TOC: figures in ox-html?

2015-02-17 Thread Melanie Bacou

Hi,

The `#+TOC: tables` construct does export nicely to HTML. Just wondering 
if `#+TOC: figures` and maybe `#+TOC: equations` is on the roadmap, or 
could anyone provide a hook to make this work in the meantime?


Thanks, --Mel.

--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org




[O] ox-html: stand-alone export option?

2015-02-17 Thread Melanie Bacou

Hi,
I'm using ox-html to work on shared documents with my collaborators. 
We're working off a Dropbox account and converting our org files to HTML 
periodically.


Problem with all cloud storages is they don't work with relative links 
inside HTML (links to external images, CSS, and JS resources).


We would really benefit from having a stand-alone HTML exporter 
feature that automatically embeds all external references into one 
single HTML file, so they can be shared with Dropbox, Google Drive, 
OneDrive and the likes.


Has this been discussed previously? Would there be any other work around?

Thanks all, --Mel.

--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org