* 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 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
* 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 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 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 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: 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
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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.