* Org publish hierarchies and style variable
@ 2008-10-29 15:37 mdl
2008-10-29 17:59 ` Bernt Hansen
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: mdl @ 2008-10-29 15:37 UTC (permalink / raw)
To: emacs-orgmode
A question: The org-publish tutorial recommends the use of template
files for setting the relative link to the stylesheet for nested
directories to be published to html.
- http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php
E.g.,
For first level directories such as
~/org/
|- css/
| |- stylesheet.css
|- index.org
|- Emacs
| |- index.org
~/org/Emacs/index.org would contain the following:
#+SETUPFILE: ~/.emacs.d/level-1.org
which points to a setupfile with the option:
#+STYLE: <link rel="stylesheet" type="text/css"\
href="../stylesheet.css" />
My question: Instead of this method, which I find a little tedious,
I've created a hardlink to the master css directory in each
subdirectory of my project. As a result the, css files get copied to
each subdirectory in my public web directory and I only need to
specify a single style option in my org-publish-alist.
Apart from taking up extra disk space on the server (and thus being
less economical), are there any other potential problems with this
approach? I'm using org as a wiki and have a lot of org files in each
subdirectory. This approach seems easier than having to add and tweak
the SETUPFILE option for each new org file.
---
Matt Lundin
mdl at imapmail dot org
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Org publish hierarchies and style variable 2008-10-29 15:37 Org publish hierarchies and style variable mdl @ 2008-10-29 17:59 ` Bernt Hansen 2008-10-30 3:00 ` Matthew Lundin 2008-10-29 18:40 ` Sebastian Rose 2008-10-29 18:59 ` Sebastian Rose 2 siblings, 1 reply; 10+ messages in thread From: Bernt Hansen @ 2008-10-29 17:59 UTC (permalink / raw) To: mdl; +Cc: emacs-orgmode mdl@imapmail.org writes: > A question: The org-publish tutorial recommends the use of template > files for setting the relative link to the stylesheet for nested > directories to be published to html. > > - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php > > E.g., > > For first level directories such as > > ~/org/ > |- css/ > | |- stylesheet.css > |- index.org > |- Emacs > | |- index.org > > ~/org/Emacs/index.org would contain the following: > > #+SETUPFILE: ~/.emacs.d/level-1.org > > which points to a setupfile with the option: > > #+STYLE: <link rel="stylesheet" type="text/css"\ > href="../stylesheet.css" /> > > My question: Instead of this method, which I find a little tedious, > I've created a hardlink to the master css directory in each > subdirectory of my project. As a result the, css files get copied to > each subdirectory in my public web directory and I only need to > specify a single style option in my org-publish-alist. > > Apart from taking up extra disk space on the server (and thus being > less economical), are there any other potential problems with this > approach? I'm using org as a wiki and have a lot of org files in each > subdirectory. This approach seems easier than having to add and tweak > the SETUPFILE option for each new org file. I have lots of org files generating documents (some public, most not) at http://doc.norang.ca/ ,---- | Most of the public documents in doc.norang.ca have outdated | information but the 'How to use git' document might be of interest to | people on this mailing list. `---- I wrote a simple Python CGI script that picks up any HTML file in that directory and displays it on the index page. Each page uses the same CSS file. I have one entry for CSS which I share between all of my pages: ,----[ part of my org-publish-project-alist ] | ("doc-org" :base-directory "~/git/doc.norang.ca/" :publishing-directory "/ssh:www-data@www:~/doc.norang.ca/htdocs" :recursive t :section_numbers nil :table-of-contents nil :base-extension "org" :publishing-function org-publish-org-to-html :style "<link rel=\"stylesheet\"\n href=\"/org.css\"\n type=\"text/css\">" :author-info nil :creator-info nil) | ("doc-css" :base-directory "~/git/doc.norang.ca/" :publishing-directory "/ssh:www-data@www:~/doc.norang.ca/htdocs" :base-extension "css" :publishing-function org-publish-attachment :recursive t :author nil) | ("doc" :components | ("doc-org" "doc-css")) `---- I create docs in subdirectories under http://doc.norang.ca/ and each document uses the css file in the root directory. All the documents use the same CSS file and therefore look the same. You could of course specify a fixed address for the stylesheet - there's no requirement to use relative addressing for your stylesheets at all (i.e. I could have replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to use that stylesheet for any page (even stuff not in the doc.norang.ca domain) Feel free to steal it if you like it :) Maybe some of that is useful... -Bernt ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Org publish hierarchies and style variable 2008-10-29 17:59 ` Bernt Hansen @ 2008-10-30 3:00 ` Matthew Lundin 2008-10-30 10:38 ` Richard Riley 0 siblings, 1 reply; 10+ messages in thread From: Matthew Lundin @ 2008-10-30 3:00 UTC (permalink / raw) To: Bernt Hansen; +Cc: emacs-orgmode Bernt, Bernt Hansen <bernt@norang.ca> writes: > mdl@imapmail.org writes: ... >> My question: Instead of this method, which I find a little tedious, >> I've created a hardlink to the master css directory in each >> subdirectory of my project. As a result the, css files get copied to >> each subdirectory in my public web directory and I only need to >> specify a single style option in my org-publish-alist. ... > > I create docs in subdirectories under http://doc.norang.ca/ and each > document uses the css file in the root directory. All the documents use > the same CSS file and therefore look the same. You could of course > specify a fixed address for the stylesheet - there's no requirement to > use relative addressing for your stylesheets at all (i.e. I could have > replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to > use that stylesheet for any page (even stuff not in the doc.norang.ca > domain) Thanks for this very simple solution. Best, Matt ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Org publish hierarchies and style variable 2008-10-30 3:00 ` Matthew Lundin @ 2008-10-30 10:38 ` Richard Riley 2008-10-30 15:19 ` Sebastian Rose 0 siblings, 1 reply; 10+ messages in thread From: Richard Riley @ 2008-10-30 10:38 UTC (permalink / raw) To: emacs-orgmode Matthew Lundin <mdl@imapmail.org> writes: > Bernt, > > Bernt Hansen <bernt@norang.ca> writes: > >> mdl@imapmail.org writes: > ... >>> My question: Instead of this method, which I find a little tedious, >>> I've created a hardlink to the master css directory in each >>> subdirectory of my project. As a result the, css files get copied to >>> each subdirectory in my public web directory and I only need to >>> specify a single style option in my org-publish-alist. > ... >> >> I create docs in subdirectories under http://doc.norang.ca/ and each >> document uses the css file in the root directory. All the documents use >> the same CSS file and therefore look the same. You could of course >> specify a fixed address for the stylesheet - there's no requirement to >> use relative addressing for your stylesheets at all (i.e. I could have >> replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to >> use that stylesheet for any page (even stuff not in the doc.norang.ca >> domain) > > Thanks for this very simple solution. > > Best, > > Matt > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > I dont know if this is appropriate or how late I came into this discussion but I publish a web thats a few directories deep and I simply have a dummy style at each level which cascades back to the master. Something like ,---- style.css | @import url(../style.css); `---- combined with: ,---- | ("web-org" | :base-directory "~/webs/rgr/" | :publishing-directory "/ssh:rgrweb:/home/shamrock/rgrweb/" | :base-extension "org" | :publishing-function org-publish-org-to-html | :recursive t | :section-numbers nil | :style "<link rel=stylesheet | href=\"./style.css\" | type=\"text/css\">" | :auto-preamble t | :auto-postamble t | :preamble "<div id='Content'><a href='../'>Back</a> - <a href='http://rgrweb/default/'>Home</a>" | :postamble "</div>" | :author nil | ) | `---- in my org-publish-project-alist I don't know if things have barreled along so quickly that this is more patching and sticking plaster than a solid solution but it works well for me. regards richard. -- important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: Org publish hierarchies and style variable 2008-10-30 10:38 ` Richard Riley @ 2008-10-30 15:19 ` Sebastian Rose 2008-10-30 15:06 ` Richard Riley 0 siblings, 1 reply; 10+ messages in thread From: Sebastian Rose @ 2008-10-30 15:19 UTC (permalink / raw) To: Richard Riley; +Cc: emacs-orgmode Richard Riley <rileyrgdev@gmail.com> writes: > I don't know if things have barreled along so quickly that this is more > patching and sticking plaster than a solid solution but it works well for > me. That's the important thing: it has to work for you ;-) That's why I stick with the 'level-files' solution. This way it works without any server-side scripting, postprocessing, networking and simply on each and ervery host. Even when accessed through the file: protocol localy. All I need is emacs and a webbrowser to browse my notes or test publishing. But it is indeed tailored to my needs: note-taking. To do fancy stuff, we may use the either :style in org-publish-projects-alist or the corresponding #+STYLE: file-variable (e.g. in a level-file), to add arbitrary stuff to the head section. I'll just use the #+STYLE: option for readability. An other solution to use only one stylesheet, and be able to move files around (not working through the file: protocol or without network, just as Bernt's setup): #+STYLE: <base href="http://host.domain.tld" /> If Php is supported on all hosts, you may use the next snippet, to make it portable (publish on several hosts without changing anything): :#+STYLE: <?php :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />'; :#+STYLE: ?> That way _all_ the URLs in stylesheets (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are resolved relative to http://host.domain.tld. See http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4 for details how links are resolved when using the base element (HTML 4.0 is the basis for XHTML 1.0 strict). Regards, Sebastian -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: Org publish hierarchies and style variable 2008-10-30 15:19 ` Sebastian Rose @ 2008-10-30 15:06 ` Richard Riley 2008-10-30 17:32 ` Sebastian Rose 0 siblings, 1 reply; 10+ messages in thread From: Richard Riley @ 2008-10-30 15:06 UTC (permalink / raw) To: Sebastian Rose; +Cc: emacs-orgmode Sebastian Rose <sebastian_rose@gmx.de> writes: > Richard Riley <rileyrgdev@gmail.com> writes: >> I don't know if things have barreled along so quickly that this is more >> patching and sticking plaster than a solid solution but it works well for >> me. > > That's the important thing: it has to work for you ;-) > > That's why I stick with the 'level-files' solution. This way it works > without any server-side scripting, postprocessing, networking and simply > on each and ervery host. Even when accessed through the file: protocol > localy. All I need is emacs and a webbrowser to browse my notes or test > publishing. I think cascading stylesheets using relative file notation provide the same benefit. Note "think" since its been a while since I implemented my org solution for my small web. > > But it is indeed tailored to my needs: note-taking. > > To do fancy stuff, we may use the either :style in > org-publish-projects-alist or the corresponding #+STYLE: file-variable > (e.g. in a level-file), to add arbitrary stuff to the head section. I'll > just use the #+STYLE: option for readability. You need to add it to each file if its a file specific style - that's fine. But that can mix with the cascaded style method I suggested. The benefit of the simple method I outlined is that you still (or already) also have a specific style sheet for the project level or directory too. A good place to add sub web specific look and feel should you want. > > > An other solution to use only one stylesheet, and be able to move files > around (not working through the file: protocol or without network, just > as Bernt's setup): > > #+STYLE: <base href="http://host.domain.tld" /> Assuming it is a web specific style this is not necessary using cascades as I outlined and which also works with out "real host" testing. I can see this being possibly necessary when you want to borrow other peoples styles however. > > If Php is supported on all hosts, you may use the next snippet, to make > it portable (publish on several hosts without changing anything): > > :#+STYLE: <?php > :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />'; > :#+STYLE: ?> > > > That way _all_ the URLs in stylesheets > (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are > resolved relative to http://host.domain.tld. This has further ramifications I think. Namely including things relative. e.g sub dir in a web http:/web/proj1. Normally if I do not provide a full URL I want it relative. e.g "url:./images/proj1.jpg" > > > See http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4 for details how > links are resolved when using the base element (HTML 4.0 is the basis for > XHTML 1.0 strict). > > > > Regards, > > Sebastian -- important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: Org publish hierarchies and style variable 2008-10-30 15:06 ` Richard Riley @ 2008-10-30 17:32 ` Sebastian Rose 2008-10-30 17:04 ` Richard Riley 0 siblings, 1 reply; 10+ messages in thread From: Sebastian Rose @ 2008-10-30 17:32 UTC (permalink / raw) To: emacs-orgmode Org-Mode Richard Riley <rileyrgdev@googlemail.com> writes: >> That's why I stick with the 'level-files' solution. This way it works >> without any server-side scripting, postprocessing, networking and simply >> on each and ervery host. Even when accessed through the file: protocol >> localy. All I need is emacs and a webbrowser to browse my notes or test >> publishing. > > I think cascading stylesheets using relative file notation provide the > same benefit. Note "think" since its been a while since I implemented my > org solution for my small web. Yes, if all you use is stylesheet. I use paths in my setup for org-info.js too, and you could add libraries (Perl, PHP....) or something. Thanks to the level files, it's easy to move the file around. Also, they provide 'view classes'. E.g., I can change a simple file into a presentation by adding a few characters I remember, instead of changing/adding all those lines of a export template. Admittendly, I move files quite often. I split them in several files as they grow, put those files into an extra directory and so on. >> To do fancy stuff, we may use the either :style in >> org-publish-projects-alist or the corresponding #+STYLE: file-variable >> (e.g. in a level-file), to add arbitrary stuff to the head section. I'll >> just use the #+STYLE: option for readability. > > You need to add it to each file if its a file specific style - that's > fine. Just make it the value of :style in org-publish-projects-alist. #+STYLE: just overwrites that. >> An other solution to use only one stylesheet, and be able to move files >> around (not working through the file: protocol or without network, just >> as Bernt's setup): >> >> #+STYLE: <base href="http://host.domain.tld" /> > > Assuming it is a web specific style this is not necessary using cascades > as I outlined and which also works with out "real host" testing. I can > see this being possibly necessary when you want to borrow other peoples > styles however. No, not neccessary. Just one possibilty to have a stylesheet in the document root, and use just one header for all files. If you have http://host.domain.tld/main.css, all files may use <base href="http://host.domain.tld" /> <link rel="stylesheet" type="text/css" href="main.css" /> regardless of position in the directory tree. >> >> If Php is supported on all hosts, you may use the next snippet, to make >> it portable (publish on several hosts without changing anything): >> >> :#+STYLE: <?php >> :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />'; >> :#+STYLE: ?> >> >> >> That way _all_ the URLs in stylesheets >> (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are >> resolved relative to http://host.domain.tld. > > This has further ramifications I think. Namely including things > relative. e.g sub dir in a web http:/web/proj1. Normally if I do not > provide a full URL I want it relative. e.g "url:./images/proj1.jpg" That's, what the base element is for. The nice part of it is, that all _realtive_ paths are relative to the address basis (which makes them abolute, yes), which means I don't have to change them, when I move the file around. It has indeed some disadvantages: - relative links will not work for the *.org files. - file: protocol does not work. That's why I don't use it here. If I was to publish to a website, I would take it in account. No need to change any image URL in the files, when moving them from one directory to another. /Normal/ links _to_ the file will always stop working, when moving a file. That's one of the reasons, why we use databases instead of plain HTML files for real web sites. However, the relative links _from_ the moved file to others will still work, if you supply a address basis. Best, -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: Org publish hierarchies and style variable 2008-10-30 17:32 ` Sebastian Rose @ 2008-10-30 17:04 ` Richard Riley 0 siblings, 0 replies; 10+ messages in thread From: Richard Riley @ 2008-10-30 17:04 UTC (permalink / raw) To: Sebastian Rose; +Cc: emacs-orgmode Org-Mode Sebastian Rose <sebastian_rose@gmx.de> writes: > Richard Riley <rileyrgdev@googlemail.com> writes: >>> That's why I stick with the 'level-files' solution. This way it works >>> without any server-side scripting, postprocessing, networking and simply >>> on each and ervery host. Even when accessed through the file: protocol >>> localy. All I need is emacs and a webbrowser to browse my notes or test >>> publishing. >> >> I think cascading stylesheets using relative file notation provide the >> same benefit. Note "think" since its been a while since I implemented my >> org solution for my small web. > > > Yes, if all you use is stylesheet. I use paths in my setup for My comments are limited to Stylesheets at present. > org-info.js too, and you could add libraries (Perl, PHP....) or > something. Thanks to the level files, it's easy to move the file > around. Also, they provide 'view classes'. E.g., I can change a simple > file into a presentation by adding a few characters I remember, instead > of changing/adding all those lines of a export template. I think you have lost me here. The cascaded method does have level files. At a default they simply cascade to the one above if it exists. And the relative cascade works with all protocols. Possibly we are agreeing. Since I do not understand what you mean above when you talk about adding/changing lots of lines or adding a few characters to a presentation. Do you mean adding some style info? > > Admittendly, I move files quite often. I split them in several files as > they grow, put those files into an extra directory and so on. > > >>> To do fancy stuff, we may use the either :style in >>> org-publish-projects-alist or the corresponding #+STYLE: file-variable >>> (e.g. in a level-file), to add arbitrary stuff to the head section. I'll >>> just use the #+STYLE: option for readability. >> >> You need to add it to each file if its a file specific style - that's >> fine. > > > Just make it the value of :style in org-publish-projects-alist. > #+STYLE: just overwrites that. Yes : file specific as I mentioned above should you want it. With my way you can have the basic cascade and the file specifics I think. > > >>> An other solution to use only one stylesheet, and be able to move files >>> around (not working through the file: protocol or without network, just >>> as Bernt's setup): >>> >>> #+STYLE: <base href="http://host.domain.tld" /> >> >> Assuming it is a web specific style this is not necessary using cascades >> as I outlined and which also works with out "real host" testing. I can >> see this being possibly necessary when you want to borrow other peoples >> styles however. > > No, not neccessary. Just one possibilty to have a stylesheet in the > document root, and use just one header for all files. One header for all the files? Yes. But this can still use cascaded styles. > > If you have http://host.domain.tld/main.css, all files may use > > <base href="http://host.domain.tld" /> > <link rel="stylesheet" type="text/css" href="main.css" /> > > regardless of position in the directory tree. Of course : hard coded to a single style. A more flexible, I feel, approach is to use the cascaded styles and have root style include that host specific one. > >>> >>> If Php is supported on all hosts, you may use the next snippet, to make >>> it portable (publish on several hosts without changing anything): >>> >>> :#+STYLE: <?php >>> :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />'; >>> :#+STYLE: ?> >>> >>> >>> That way _all_ the URLs in stylesheets >>> (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are >>> resolved relative to http://host.domain.tld. >> >> This has further ramifications I think. Namely including things >> relative. e.g sub dir in a web http:/web/proj1. Normally if I do not >> provide a full URL I want it relative. e.g "url:./images/proj1.jpg" > > > That's, what the base element is for. The nice part of it is, that all > _realtive_ paths are relative to the address basis (which makes them > abolute, yes), which means I don't have to change them, when I move the > file around. And thus means the example I gave above is broken. I think I don't like setting the base href to be honest. It tend to think of it as less flexible. Sure SOME individual files might want to do this but to set this up as part of the project definition is losing flexibility and localization as I outlined above with my proj1 example. > > > It has indeed some disadvantages: > > - relative links will not work for the *.org files. > - file: protocol does not work. And this is a major disadvantage. And one not met with relative cascades. > > > That's why I don't use it here. If I was to publish to a website, I > would take it in account. No need to change any image URL in the files, > when moving them from one directory to another. I'm not sure I understand your meaning here. Moving image files around? Basically you seem to be advocating hard coded locations as opposed to project local locations- > > /Normal/ links _to_ the file will always stop working, when moving a > file. That's one of the reasons, why we use databases instead of plain > HTML files for real web sites. However, the relative links _from_ the > moved file to others will still work, if you supply a address basis. > > > > Best, -- important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Org publish hierarchies and style variable 2008-10-29 15:37 Org publish hierarchies and style variable mdl 2008-10-29 17:59 ` Bernt Hansen @ 2008-10-29 18:40 ` Sebastian Rose 2008-10-29 18:59 ` Sebastian Rose 2 siblings, 0 replies; 10+ messages in thread From: Sebastian Rose @ 2008-10-29 18:40 UTC (permalink / raw) To: emacs-orgmode Hi Matt, I can see no problem with the alternative you provide here. It's nice IMHO. How much space will a stylesheet take? One block, sometimes 2 - not very much. Thanks for pointing this out. There is the per file #+STYLE: setting. We should mention those alternatives in the tutorial. * Why I recommended the #+SETUPFILE option in the tutorial When moving files around, not only the path to the stylesheet is affected, but also paths to scripts, or PHP/Perl/whatever libraries and includes (which may live in the #+TEXT: line of a level file). I have 106 files and directories currently, constantly growing. And the head of the all the files just looks like this: #+SETUPFILE: ~/emacs/org/levels/level-1.org #+TITLE: Some Title Moving the file, just means to change one character (`1'), and the scripts, stylesheets, and all the rest still works. I use 6 level files for 3 levels (more to come): - 1 for startpage (No `Up' link, `Home' leads to my local homepage), - 2 for directory indexes (where `Up' means go to '../index.html', `Home' to my `sitemap.html'), - 3 for all the other files (where `Up' goes to 'index.html', `Home' to my `sitemap.html'). Images in stylesheets ('background-image:url(.....)') are resolved realtive to the stylesheets location. We should be able to add a '<base href="">' line ;-) Regards, Sebastian mdl@imapmail.org writes: > A question: The org-publish tutorial recommends the use of template > files for setting the relative link to the stylesheet for nested > directories to be published to html. > > - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php > > E.g., > > For first level directories such as > > ~/org/ > |- css/ > | |- stylesheet.css > |- index.org > |- Emacs > | |- index.org > > ~/org/Emacs/index.org would contain the following: > > #+SETUPFILE: ~/.emacs.d/level-1.org > > which points to a setupfile with the option: > > #+STYLE: <link rel="stylesheet" type="text/css"\ > href="../stylesheet.css" /> > > My question: Instead of this method, which I find a little tedious, > I've created a hardlink to the master css directory in each > subdirectory of my project. As a result the, css files get copied to > each subdirectory in my public web directory and I only need to > specify a single style option in my org-publish-alist. > > Apart from taking up extra disk space on the server (and thus being > less economical), are there any other potential problems with this > approach? I'm using org as a wiki and have a lot of org files in each > subdirectory. This approach seems easier than having to add and tweak > the SETUPFILE option for each new org file. -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Org publish hierarchies and style variable 2008-10-29 15:37 Org publish hierarchies and style variable mdl 2008-10-29 17:59 ` Bernt Hansen 2008-10-29 18:40 ` Sebastian Rose @ 2008-10-29 18:59 ` Sebastian Rose 2 siblings, 0 replies; 10+ messages in thread From: Sebastian Rose @ 2008-10-29 18:59 UTC (permalink / raw) To: emacs-orgmode Org-Mode Hi Matt, The path problem could be addressed in a nice way: #+STYLE: <base href="/" /> We may have several #+STYLE: lines, so we can add whatever we want to the <head> section: #+STYLE: <base href="/" /> #+STYLE: <?php require("some/code.php"); ?> #+STYLE: <script type="text/javascript" language="JavaScript" src="jquery.js"></script> The '<base href="" />' is _very_ interesting, all paths to stylesheets, images (plus images in stylesheets!), flash films, applets and scripts are resolved relative to this path by the browser! This way, neither #+SETUPFILEs nor hard links are needed. We could reuse the #+STYLE: option for everything related to HTML export. This would be easier on the maintainer (Carsten by now) then adding an option for each and every feature we will request for HTML publishing in the future. Why didn't I think of it earlier??? Regards, Sebastian mdl@imapmail.org writes: > A question: The org-publish tutorial recommends the use of template > files for setting the relative link to the stylesheet for nested > directories to be published to html. > > - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php > > E.g., > > For first level directories such as > > ~/org/ > |- css/ > | |- stylesheet.css > |- index.org > |- Emacs > | |- index.org > > ~/org/Emacs/index.org would contain the following: > > #+SETUPFILE: ~/.emacs.d/level-1.org > > which points to a setupfile with the option: > > #+STYLE: <link rel="stylesheet" type="text/css"\ > href="../stylesheet.css" /> > > My question: Instead of this method, which I find a little tedious, > I've created a hardlink to the master css directory in each > subdirectory of my project. As a result the, css files get copied to > each subdirectory in my public web directory and I only need to > specify a single style option in my org-publish-alist. > > Apart from taking up extra disk space on the server (and thus being > less economical), are there any other potential problems with this > approach? I'm using org as a wiki and have a lot of org files in each > subdirectory. This approach seems easier than having to add and tweak > the SETUPFILE option for each new org file. > > --- > Matt Lundin > mdl at imapmail dot org > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Email: s.rose emma-stil de, sebastian_rose gmx de Http: www.emma-stil.de ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-10-30 17:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-29 15:37 Org publish hierarchies and style variable mdl 2008-10-29 17:59 ` Bernt Hansen 2008-10-30 3:00 ` Matthew Lundin 2008-10-30 10:38 ` Richard Riley 2008-10-30 15:19 ` Sebastian Rose 2008-10-30 15:06 ` Richard Riley 2008-10-30 17:32 ` Sebastian Rose 2008-10-30 17:04 ` Richard Riley 2008-10-29 18:40 ` Sebastian Rose 2008-10-29 18:59 ` Sebastian Rose
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).