Re: [O] [ANN] Merge of new export framework on Wednesday
Hello, Rick Frankel r...@rickster.com writes: Also, shouldn't :html-style-include-default be :html-head-include-default? The variable and this property should stay html-style-include-default, or at worst become html-head-include-default-style. The intent of changing things from html-style... to html-head... was to make it clear that the use is for anything in the head, not merely style. It is still appropriate for variables that actually refer to style to have the word style in them. IMHO, Terry -- T.F. Torrey
Re: [O] [ANN] Merge of new export framework on Wednesday
On Saturday, March 2, 2013, Bastien wrote: Hi Sean, Sean O'Halpin sean.ohal...@gmail.com javascript:; writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef I am on commit 40fc98e so I think I have all of the fixes to this change. I noticed that it no longer concatenates multiple lines from the file header. I used to have multiple #+HTML_STYLE: lines in my Org files that layered in different CSS. The nice thing about designing my CSS this way is that I have a base style and could change individual documents as needed by just adding a new HTML_STYLE line that loads a small, simple override CSS. I would get one link style sheet / line to match each HTML_STYLE line. Now it appears that only the last line is exported to the HTML file.
Re: [O] [ANN] Merge of new export framework on Wednesday
On Tue, Feb 05, 2013 at 02:07:50PM +0100, Suvayu Ali wrote: Hi Eric, On Tue, Feb 05, 2013 at 11:20:18PM +1030, Eric S Fraga wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: I have attached a somewhat cleaned up version of what I had so far. You can apply the patch on top of Worg master. If you think this is clean enough for a starting point then I will push it to Worg. I think it's definitely worth pushing to Worg. There's obviously much to do but having even the basics that you present in this document is very helpful. Just knowing that there is an org-e-beamer minor mode made it worth reading. I pushed the commit, but I see the publishing failed. I updated the article considerably. Comments welcome. http://orgmode.org/cgit.cgi/worg.git/commit/?id=0b98d52bee82c856d46df7ce49bc7738fb9d2b4d Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello, Mike McLean mike.mcl...@pobox.com writes: I noticed that it no longer concatenates multiple lines from the file header. I used to have multiple #+HTML_STYLE: lines in my Org files that layered in different CSS. The nice thing about designing my CSS this way is that I have a base style and could change individual documents as needed by just adding a new HTML_STYLE line that loads a small, simple override CSS. I would get one link style sheet / line to match each HTML_STYLE line. Now it appears that only the last line is exported to the HTML file. This should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Bastien, On Sat, Mar 02, 2013 at 07:14:07PM +0100, Bastien wrote: Hi Sean, Sean O'Halpin sean.ohal...@gmail.com writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef It seems to me a few files in contrib needs to be updated, and also the manual of course. $ git grep -i html_style contrib/lisp/ox-deck.el: (:html-style-extra HTML_STYLE nil org-html-style-extra newline) contrib/lisp/ox-s5.el: (:html-style-extra HTML_STYLE nil org-html-style-extra newline) doc/org.texi:@cindex #+HTML_STYLE doc/org.texi:#+HTML_STYLE: link rel=stylesheet type=text/css href=stylesheet.css / doc/org.texi:@itemx #+LaTeX_HEADER:, #+HTML_STYLE:, #+HTML_LINK_UP:, #+HTML_LINK_HOME:, I updated the FAQ entry on Worg for new exporter switch. http://orgmode.org/cgit.cgi/worg.git/commit/?id=b137e931edd6cddfdcf4df40d29e93f01ad59242 Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] Merge of new export framework on Wednesday
On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou n.goaz...@gmail.comwrote:
Hello,
Mike McLean mike.mcl...@pobox.com writes:
I noticed that it no longer concatenates multiple lines from the file
header. I used to have multiple #+HTML_STYLE: lines in my Org files that
layered in different CSS. The nice thing about designing my CSS this way
is
that I have a base style and could change individual documents as needed
by
just adding a new HTML_STYLE line that loads a small, simple override
CSS.
I would get one link style sheet / line to match each HTML_STYLE line.
Now it appears that only the last line is exported to the HTML file.
This should be fixed.
It doesn't seem to be. I have put together a ECM. I have two CSS files,
representing a “base” style and an optional “override” style. I have two
versions of an org test file that differ only in the first 2 lines of the
file. One “works” (loads both style sheets and displays the text as
described in the document), one does not.
This is a minimal ECM. In my actual setup I have the equivalent of the base
CSS file in a file named ~org-options.txt~ that I include into every single
Org file I ever create via ~#+SETUPFILE~. I load my override CSS on a
per-document basis in the document header below the ~#+SETUPFILE:~
directive.
a, h1, h2, h3, h4, h5, h6 {
color: red;
margin-bottom: 0.5em;
}
test-org-export-not-works.org
Description: Binary data
/*
* CSS Overrides for documents that should display in blue and have blockquotes
*/
p {
color: blue;
}
blockquote {
float:right;
width:160px;
font-size:90%;
margin:0 0 0 10px;
padding:15px;
font-family:Georgia, Times New Roman, Times, serif;
border-left:solid 3px #DEDEDE;
}
test-org-export-works.org
Description: Binary data
Re: [O] [ANN] Merge of new export framework on Wednesday
Mike McLean mike.mcl...@pobox.com writes: On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou n.goaz...@gmail.comwrote: Hello, Mike McLean mike.mcl...@pobox.com writes: I noticed that it no longer concatenates multiple lines from the file header. I used to have multiple #+HTML_STYLE: lines in my Org files that layered in different CSS. The nice thing about designing my CSS this way is that I have a base style and could change individual documents as needed by just adding a new HTML_STYLE line that loads a small, simple override CSS. I would get one link style sheet / line to match each HTML_STYLE line. Now it appears that only the last line is exported to the HTML file. This should be fixed. It doesn't seem to be. Indeed. I overlooked some code typo. Could you try again (a restart may be required)? Thank you. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
On Monday, March 4, 2013, Nicolas Goaziou wrote: Mike McLean mike.mcl...@pobox.com javascript:; writes: On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou n.goaz...@gmail.comjavascript:; wrote: Hello, Mike McLean mike.mcl...@pobox.com javascript:; writes: I noticed that it no longer concatenates multiple lines from the file header. I used to have multiple #+HTML_STYLE: lines in my Org files that layered in different CSS. The nice thing about designing my CSS this way is that I have a base style and could change individual documents as needed by just adding a new HTML_STYLE line that loads a small, simple override CSS. I would get one link style sheet / line to match each HTML_STYLE line. Now it appears that only the last line is exported to the HTML file. This should be fixed. It doesn't seem to be. Indeed. I overlooked some code typo. Could you try again (a restart may be required)? That did it. Thank you. Overall I'm loving the new exporter, BTW. Awesome job!!!
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: $ git grep -i html_style contrib/lisp/ox-deck.el: (:html-style-extra HTML_STYLE nil org-html-style-extra newline) contrib/lisp/ox-s5.el: (:html-style-extra HTML_STYLE nil org-html-style-extra newline) doc/org.texi:@cindex #+HTML_STYLE doc/org.texi:#+HTML_STYLE: link rel=stylesheet type=text/css href=stylesheet.css / doc/org.texi:@itemx #+LaTeX_HEADER:, #+HTML_STYLE:, #+HTML_LINK_UP:, #+HTML_LINK_HOME:, Fixed, thanks! And thanks for fixing this in Worg, that helps a lot. Best, -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
On Sat, Mar 2, 2013 at 6:14 PM, Bastien b...@altern.org wrote: Hi Sean, Sean O'Halpin sean.ohal...@gmail.com writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef Best, -- Bastien Thanks! It will now feel less hacky to use it for other head elements :) Also, it's just struck me - wouldn't it be more consistent if ATTR_HTML were HTML_ATTR, ATTR_LATEX were LATEX_ATTR, etc.? But I suppose if you go down that route of everything export backend related being prefixed with the export type, you'd really have to change BEGIN_HTML to HTML_BEGIN, etc. Perhaps going too far... Regards, Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Sean, Sean O'Halpin sean.ohal...@gmail.com writes: Also, it's just struck me - wouldn't it be more consistent if ATTR_HTML were HTML_ATTR, ATTR_LATEX were LATEX_ATTR, etc.? I don't really think so -- ATTR_HTML is more like BEGIN_HTML than #+HTML_HEAD, which is a global option, not a local setting or an environment... and we can't break all .org files like this :) -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Bastien-
On Sat, Mar 02, 2013 at 07:14:07PM +0100, Bastien wrote:
Done. You can now use HTML_HEAD instead of HTML_STYLE.
Some variables were also renamed, check the details here:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef
In trying to migrate these changes to the slide exporters, i noticed
some confusion w/ the migration of html-style vs. html-style-extra:
- (:html-style nil nil org-html-style)
- (:html-style-extra HTML_STYLE nil org-html-style-extra newline)
- (:html-style-include-default nil nil org-html-style-include-default)
- (:html-style-include-scripts nil nil org-html-style-include-scripts)
+ (:html-head HTML_HEAD nil org-html-head newline)
+ (:html-style-include-default nil nil org-html-head-include-default-style)
+ (:html-head-include-scripts nil nil org-html-head-include-scripts)
...
- exp-plist :html-style-extra
- (concat (or (plist-get exp-plist :html-style-extra) )
+ exp-plist :html-head-extra
+ (concat (or (plist-get exp-plist :html-head-extra) )
\n
style)
Specifically,
- :html-style was renamed to :html-head (ok), but the
in-buffer property HTML_HEAD was added to this export
property.
- :html-style-extra was (which was associated w/t the
in-buffer property HTML_STYLE) was removed from the export
prop list (but is referenced later in the code.
- `org-html-head-extra' is mentioned in a doc string but never
defined.
I think this is a bug/typo. Wouldn't the following be closer to a
straight renaming:
(:html-head nil nil org-html-head newline)
(:html-head-extra HTML_HEAD nil org-html-head-extra newline)
or should {org-,:}html-head-extra be dropped entirely?
Also, shouldn't :html-style-include-default be
:html-head-include-default?
rick
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Sean, Sean O'Halpin sean.ohal...@gmail.com writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef Best, -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Bastien, Bastien wrote: Sean O'Halpin sean.ohal...@gmail.com writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef Isn't it peculiar to rename STYLE into HEAD, in all affected vars but one? - html-STYLE-include-default - html-STYLE-include-default (unchanged) - html-STYLE-include-scripts - html-HEAD-include-scripts - org-html-STYLE-include-default - org-html-HEAD-include-default-STYLE - org-html-STYLE-include-scripts - org-html-HEAD-include-scripts Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: - html-STYLE-include-default - html-STYLE-include-default (unchanged) Fixed, thanks. -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello, Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? As far as I am concerned, you can. Bastien (CC'ed) might have another plan for these files, though. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Yes, please go ahead. Thanks, -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Bastien writes: Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Yes, please go ahead. Done, please check that I didn't miss any file. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Done, please check that I didn't miss any file. org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't they go into oldexp, too? Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou n.goaz...@gmail.com writes: Achim Gratz strom...@nexgo.de writes: Done, please check that I didn't miss any file. org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't they go into oldexp, too? Indeed, done. -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
On Fri, Feb 8, 2013 at 4:45 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Sean O'Halpin wrote:
I suggest we rename it to #+HTML_HEAD.
But I'd like to propose HTML_HEADER instead (?), to mirror what LaTeX_HEADER
does -- at least, if that one still exists, which I'm not sure about (not
enough played with the new exporter yet).
I'm going on the assumption that what comes after the =#+HTML_= prefix
is specific to the HTML back-end. Where LaTeX has a /conceptual/
header, HTML has a /concrete/ =head= element. There's nothing to
mirror =LaTeX_CLASS= for example because the concept of document class
does not exist in HTML.
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Regards,
Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello,
Sean O'Halpin sean.ohal...@gmail.com writes:
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Not every back-end has a concept of head (think about Markdown
back-end). We don't need a general concept for something that isn't
general.
Also, completely unifying every back-end is close to impossible, unless
the same person writes every back-end[1]. Most of the options are
shared, that's the goal of ox.el, but in the end, each back-end decides
how it handles the others.
Regards,
[1] Even then, back-ends are so different that it would ultimately fail,
anyway.
--
Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? I recommend contrib/obsolete/ or contrib/attic/. Regards, Achim. --
Re: [O] [ANN] Merge of new export framework on Wednesday
On Sat, Feb 9, 2013 at 1:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Sean O'Halpin sean.ohal...@gmail.com writes:
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Not every back-end has a concept of head (think about Markdown
back-end). We don't need a general concept for something that isn't
general.
I haven't made myself clear. I'm not suggesting a general concept of
head. What I am suggesting is that the back-ends handle these
back-end specific concepts themselves, rather than add more buffer
keywords for every new exporter. The general concept is that we want
to communicate document level information to the back-end, in this
case, bits of text to insert at specific places which are dependent on
the specific back-end in question.
Also, completely unifying every back-end is close to impossible, unless
the same person writes every back-end[1]. Most of the options are
shared, that's the goal of ox.el, but in the end, each back-end decides
how it handles the others.
This would not require unifying every back-end at all. In fact, quite
the opposite. All you would need would be for the generic exporter
framework to provide the back-end a dictionary of key value pairs,
such as ((:head script.../) ...), which the back-end would
interpret. You would avoid having to add document level keywords such
as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the
back-end's responsibility to validate and document these options. My
suggestion is really not so different from what the new exporter does
anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we
have =#+EXPORT: html link-up ...=.
Perhaps I'm just expressing a preference for fewer buffer-level
keywords - feel free to ignore the suggestion.
Regards,
Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Sean O'Halpin sean.ohal...@gmail.com writes: I haven't made myself clear. I'm not suggesting a general concept of head. What I am suggesting is that the back-ends handle these back-end specific concepts themselves, rather than add more buffer keywords for every new exporter. Each back-end adds its own keywords, define them, document them and interpret them. So, basically, backends handle these concept themselves, don't they? This would not require unifying every back-end at all. In fact, quite the opposite. All you would need would be for the generic exporter framework to provide the back-end a dictionary of key value pairs, such as ((:head script.../) ...), which the back-end would interpret. This is exactly what is happening. You would avoid having to add document level keywords such as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the back-end's responsibility to validate and document these options. My suggestion is really not so different from what the new exporter does anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we have =#+EXPORT: html link-up ...=. Honestly, besides the syntax, I don't see any difference. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou n.goaz...@gmail.com writes: Sean O'Halpin sean.ohal...@gmail.com writes: You would avoid having to add document level keywords such as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the back-end's responsibility to validate and document these options. My suggestion is really not so different from what the new exporter does anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we have =#+EXPORT: html link-up ...=. Honestly, besides the syntax, I don't see any difference. IIUC, the difference is that #+HTML_LINK_UP and friends are all direct children of the document in the former case, and in the latter case all exporter-related options are grouped. An intermediate solution would be to group all options specific to one backend in #+EXPORT_backend (and in this case, there could be a generic #+EXPORT: that could be used by every backend). OTOH, most #+keywords statements are meant for the exporter (there are exceptions) anyway, so this might sound like premature or over-generalization. I didn't read the whole thread and do not actually export very often so might have completely missed the point. -- Nico.
Re: [O] [ANN] Merge of new export framework on Wednesday
Great work on the new exporter! One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Regards, Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Sean, Sean O'Halpin wrote: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? Why not... I suggest we rename it to #+HTML_HEAD. But I'd like to propose HTML_HEADER instead (?), to mirror what LaTeX_HEADER does -- at least, if that one still exists, which I'm not sure about (not enough played with the new exporter yet). Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] Merge of new export framework on Wednesday
Greetings, The new exporter just arrived in my git repository and I wanted to say Congratulations! but even more importantly, THANK YOU. Kudos on a job very well done, if not 100% complete yet. I have been looking forward to this for quite some time, now. I would like to extend my Congratulations and THANK YOU to the rest of the Org-mode community/team as well, not limited to Nicolas, though this happens to be the occasion of the new exporter's release. Org-mode (and GNU-Emacs more generally, and Free software more generally than that) has changed my life, and by extension those who live and work near me, in my view, for the better. Cheers, and may we share many good days ahead. -- Jay Kerns On Sun, Feb 3, 2013 at 2:00 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: ━ ANNOUNCING THE NEW EXPORT FRAMEWORK ━
Re: [O] [ANN] Merge of new export framework on Wednesday
Suvayu Ali fatkasuvayu+li...@gmail.com writes: Hi Eric, I have used the beamer export quite a few times with the new exporter, I must admit I haven't actually tried any of my big beamer talks (hundreds of slides)... I've been too intimidated to do so! I have done a short talk but one with no special blocks, columns, etc. That worked very well. The only problem I had was figuring out how to tell the new exporter what level of headlines corresponded to frames... and I can't remember how I found out (#+OPTIONS: H:2)! Maybe I should just suck it and see! [...] Maybe I should put whatever I have on Worg so that others can work on it. I'll try to find some time in the coming two weeks. I think that would be great. I would be happy to work on any such document if it means getting some documentation in place. If you want to send me, offline, what you've got, I'd be happy to have a look. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Eric, On Tue, Feb 05, 2013 at 07:55:46PM +1030, Eric S Fraga wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: Maybe I should put whatever I have on Worg so that others can work on it. I'll try to find some time in the coming two weeks. I think that would be great. I would be happy to work on any such document if it means getting some documentation in place. If you want to send me, offline, what you've got, I'd be happy to have a look. I have attached a somewhat cleaned up version of what I had so far. You can apply the patch on top of Worg master. If you think this is clean enough for a starting point then I will push it to Worg. Cheers, -- Suvayu Open source is the future. It sets us free. From d7dfb6133bcea0127d0c386334a833e8ac64323e Mon Sep 17 00:00:00 2001 From: Suvayu Ali fatkasuvayu+li...@gmail.com Date: Tue, 5 Feb 2013 10:21:23 +0100 Subject: [PATCH] Documentation for beamer export with new exporter Start an article to serve as initial documentation for beamer export using the new exporter. This is also the working document for a tutorial for the exporter. --- org-tutorials/org-beamer/org-e-beamer.org | 141 ++ 1 file changed, 141 insertions(+) create mode 100644 org-tutorials/org-beamer/org-e-beamer.org diff --git a/org-tutorials/org-beamer/org-e-beamer.org b/org-tutorials/org-beamer/org-e-beamer.org new file mode 100644 index 000..f857174 --- /dev/null +++ b/org-tutorials/org-beamer/org-e-beamer.org @@ -0,0 +1,141 @@ +#+TITLE: Beamer presentations using the new export engine +#+AUTHOR:Suvayu Ali +#+EMAIL: fatkasuvayu+linux at gmail dot com +#+DATE: 2013-02-05 +#+DESCRIPTION: +#+KEYWORDS: +#+LANGUAGE: en +#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t +#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc +#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js +#+EXPORT_SELECT_TAGS: export +#+EXPORT_EXCLUDE_TAGS: noexport +#+LINK_UP: +#+LINK_HOME: + +#+startup: folded + +* Introduction +This tutorial covers exporting org documents to LaTeX Beamer slides +using the new export engine, =org-elements= and =org-export=, written +by Nicolas Goaziou. + +_Note:_ It will not cover any of the basic features common with the +old beamer exporter; it will only focus on the improvements, new +additions and backwards incompatibilities. It is also assumed that +the reader is already acquainted with GNU Emacs and Org mode itself. +Basic understanding of LaTeX and the Beamer package is also assumed. + +* Configuring export options +Apart from the usual export options provided by the =OPTIONS= keyword, +you can put additional beamer export options in the file header. For +a minimal beamer export, you have to specify the =LaTeX_CLASS= and the +=LaTeX_CLASS_OPTIONS= keywords in the header of a file. A preset +export template can be inserted by calling the interactive function +=org-e-beamer-insert-options-template=. This can be further modified +as per your needs. You can also do a subtree export; in that case you +can provide the keywords as =PROPERTIES=. However the keyword names +should be prepended with =EXPORT_=. A list of supported +keywords are, + +#+caption: Export option keywords and corresponding subtree properties. +| File header keywords | Subtree properties | +|---+--| +| =OPTIONS= | =EXPORT_OPTIONS= | +| =LaTeX_CLASS= | =EXPORT_LaTeX_CLASS= | +| =LaTeX_CLASS_OPTIONS= | =EXPORT_LaTeX_CLASS_OPTIONS= | +| =LaTeX_HEADER=| =EXPORT_LaTeX_HEADER=| +| =BEAMER_THEME=| =EXPORT_BEAMER_THEME=| +| =BEAMER_FONT_THEME= | =EXPORT_BEAMER_FONT_THEME= | +| =BEAMER_INNER_THEME= | =EXPORT_BEAMER_INNER_THEME= | +| =BEAMER_OUTER_THEME= | =EXPORT_BEAMER_OUTER_THEME= | + +For a subtree export, a few extra keywords are supported. For example +you can specify the exported filename with the =EXPORT_FILE_NAME= +property. + +#+caption: Properties specific to subtree export +| Subtree properties | Functionality| +|+--| +| =EXPORT_TITLE= | Export title | +| =EXPORT_AUTHOR=| Export author| +| =EXPORT_DATE= | Export date | +| =EXPORT_FILE_NAME= | Export file name | + +A simple file header might look like the example below. +#+begin_example + ,#+LaTeX_CLASS: beamer + ,#+LaTeX_CLASS_OPTIONS: [smaller,presentation] + ,#+BEAMER_THEME: default +#+end_example +A corresponding subtree export should have properties as shown below. +#+begin_example + ,* Exported title +:PROPERTIES: +:EXPORT_LaTeX_CLASS: beamer +:EXPORT_LaTeX_CLASS_OPTIONS: [presentation,smaller] +:EXPORT_BEAMER_THEME: default +:EXPORT_FILE_NAME: presentation.pdf +:END: +#+end_example + +The export class is passed on to the =\documentclass= LaTeX command, +and the options
Re: [O] [ANN] Merge of new export framework on Wednesday
Suvayu Ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Tue, Feb 05, 2013 at 07:55:46PM +1030, Eric S Fraga wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: Maybe I should put whatever I have on Worg so that others can work on it. I'll try to find some time in the coming two weeks. I think that would be great. I would be happy to work on any such document if it means getting some documentation in place. If you want to send me, offline, what you've got, I'd be happy to have a look. I have attached a somewhat cleaned up version of what I had so far. You can apply the patch on top of Worg master. If you think this is clean enough for a starting point then I will push it to Worg. Cheers, Hi Suvayu, I think it's definitely worth pushing to Worg. There's obviously much to do but having even the basics that you present in this document is very helpful. Just knowing that there is an org-e-beamer minor mode made it worth reading. If I get my original tutorial updated, the two documents together will be sufficient for many people, I think. I'm working on this now but I have run into some very strange problems to do with frame levels. Everything else seems to be fine. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Eric, On Tue, Feb 05, 2013 at 11:20:18PM +1030, Eric S Fraga wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: I have attached a somewhat cleaned up version of what I had so far. You can apply the patch on top of Worg master. If you think this is clean enough for a starting point then I will push it to Worg. I think it's definitely worth pushing to Worg. There's obviously much to do but having even the basics that you present in this document is very helpful. Just knowing that there is an org-e-beamer minor mode made it worth reading. I pushed the commit, but I see the publishing failed. remote: Publishing file /home/emacs/git/worg/org-tutorials/org-beamer/org-e-beamer.org using `org-publish-org-to-html' remote: Exporting... remote: Wrong type argument: stringp, nil remote: worg publish process 16964 exited at 02/05/13@07:01:27 Not sure why though since I checked publishing to html before committing. Can someone take a look? -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Nicolas! Great news and I'm really looking forward using the new exporter, but: 3. Export section from Org manual is now obsolete. It is being rewritten, but until this task is completed, your best source of information will still be the ML or the source files. I rely on orgmode for my homepage at work. If that stops just working without helping documentation that's no good, at least for me ... Is there already a draft of docs available? One point to pull me over from vim to emacs was the fantastic documentation of orgmode. Now I'm sitting here a bit fearful of losing the great tool for an undetermined period of time. If there are no docs at all I, as a simple user, would suggest to postpone the release till after some usage notes are available. Alternatively keep the old exporter alive , please, till the new one has documentation. (or the migration path has documentation) Anyway thanks for all your work! Just 2c Detlef
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou n.goaz...@gmail.com writes: ━ ANNOUNCING THE NEW EXPORT FRAMEWORK ━ Thanks Nicolas, this is much appreciated. I have been looking forward to this for a long time. Perhaps we should set up a Worg TODO page for documentation? To make it easier to contribute bits. Thanks, Rasmus -- Vote for proprietary math!
Re: [O] [ANN] Merge of new export framework on Wednesday
Detlef Steuer detlef.ste...@gmx.de writes: Hi Nicolas! Great news and I'm really looking forward using the new exporter, but: 3. Export section from Org manual is now obsolete. It is being rewritten, but until this task is completed, your best source of information will still be the ML or the source files. I rely on orgmode for my homepage at work. If that stops just working without helping documentation that's no good, at least for me ... Is there already a draft of docs available? One point to pull me over from vim to emacs was the fantastic documentation of orgmode. Now I'm sitting here a bit fearful of losing the great tool for an undetermined period of time. If there are no docs at all I, as a simple user, would suggest to postpone the release till after some usage notes are available. Alternatively keep the old exporter alive , please, till the new one has documentation. (or the migration path has documentation) Anyway thanks for all your work! Just 2c Detlef Hi Detlef, If you rely on org-mode for some production-level things, wouldn't it be most prudent to wait until the new exporter was shipped and fully tested before migrating your work setup? You'll still have all the documentation for the older version in the mean time, and once the new documentation is written, you'll be able to migrate with fewer problems. This is the whole principle that drives Debian, Debian-testing, and Debian-unstable. Dave
Re: [O] [ANN] Merge of new export framework on Wednesday
On Mon, Feb 04, 2013 at 08:49:28AM -0500, David Bjergaard wrote: Detlef Steuer detlef.ste...@gmx.de writes: [...] If there are no docs at all I, as a simple user, would suggest to postpone the release till after some usage notes are available. Alternatively keep the old exporter alive , please, till the new one has documentation. (or the migration path has documentation) [...] If you rely on org-mode for some production-level things, wouldn't it be most prudent to wait until the new exporter was shipped and fully tested before migrating your work setup? You'll still have all the documentation for the older version in the mean time, and once the new documentation is written, you'll be able to migrate with fewer problems. I would echo this sentiment. Org mode from master has no business in a production environment, just like any other software project. You can still keep using the latest stable release of Org (or even the tip of the maint branch) in production. And once everything is ready (including docs) for the new exporter, it will be released and possibly shipped with Emacs. You can easily switch then. Is there any particular reason for you to use master in production? Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Detlef and all, Detlef Steuer detlef.ste...@gmx.de writes: If there are no docs at all I, as a simple user, would suggest to postpone the release till after some usage notes are available. Alternatively keep the old exporter alive , please, till the new one has documentation. (or the migration path has documentation) To be clear (and I think Nicolas assumed it was clear), Org 8.0 will not be release until the documentation is fully updated. We will also make sure that Worg contains some useful tips to help with the migration, especially when it comes to use filters instead of hooks -- and on how to use old exporters that will live in contribs. For those tasks, any help on Worg will be more than welcome! -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Suvayu Ali fatkasuvayu+li...@gmail.com writes: [...] I would echo this sentiment. Org mode from master has no business in a production environment, just like any other software project. Although I agree, in principle, with this statement, life is not always so straightforward. I track org for my day to day use because I find some of the new features that appear quite useful. However, I do also rely on some form of stability for certain tasks. These are conflicting desires and I realise that this is *my* problem! However, I also am concerned at the move to the new exporter without documentation. This move appears premature if the documentation is not yet ready, not even in a draft form. I have been using the new exporter for many tasks but have not completely moved over for two: generation of beamer presentations and publishing of web pages. The latter is probably not a major issue for me but the former is. I simply have no idea how to convert my old org beamer files to the new exporter as there is no documentation at all. The source code (org-e-beamer.el) is of some help but not enough for me to know how to convert, in particular, slides with blocks and columns. Maybe it will be trivial to convert. However, I have been unsuccessful in finding anything on the mailing list that describes how to. This could be my fault in not searching properly, of course, so I would welcome any pointers to relevant emails. My solution will be to not update org until that documentation is available. Not a major problem but frustrating nonetheless. By the way, in case this email is taken the wrong way, I am in no way upset or angry! And I really appreciate all the work that has gone into the new exporter: it works brilliantly for those aspects that I have figured out and is a great step forward for org overall. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Eric, On Tue, Feb 05, 2013 at 11:37:35AM +1030, Eric S Fraga wrote: I have been using the new exporter for many tasks but have not completely moved over for two: generation of beamer presentations and publishing of web pages. The latter is probably not a major issue for me but the former is. I simply have no idea how to convert my old org beamer files to the new exporter as there is no documentation at all. The source code (org-e-beamer.el) is of some help but not enough for me to know how to convert, in particular, slides with blocks and columns. I have used the beamer export quite a few times with the new exporter, and I'm very pleased with it. I believe there is one backwards incompatible change, apart from that I think it's mostly feature enhancements. I have been trying to write some of the things down as a Worg article as preliminary documentation, but lately I have been incredibly busy to make any significant progress. I started from the old beamer tutorial as a template on how to structure it. Usually I also keep an eye out on the mailing list for questions related to the beamer export with the new exporter (although lately I have been much less active for the same reasons). Maybe I should put whatever I have on Worg so that others can work on it. I'll try to find some time in the coming two weeks. Hopefully this is a little reassuring. -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] Merge of new export framework on Wednesday
Le dimanche 3 février 2013 à 20h00, Nicolas Goaziou a écrit: I will install the new export framework along with a set of back-ends Wednesday evening (UTC). Here are a few notes to help you make the transition. That's an exciting news! Thanks for all the job already done and to be done. If the documentation is as good as this announcement, it will be great! Cheers, François Allisson
