Re: [O] [ox, patch] Add #+SUBTITLE
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
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
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
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
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
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
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?
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
[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?
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?
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?
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
