From: Sebastian Rose <sebastian_rose@gmx.de>
To: emacs-orgmode Org-Mode <emacs-orgmode@gnu.org>
Subject: Re: Re: Org publish hierarchies and style variable
Date: Thu, 30 Oct 2008 18:32:47 +0100 [thread overview]
Message-ID: <87bpx256ps.fsf@kassiopeya.MSHEIMNETZ> (raw)
In-Reply-To: <k5zlkm6s1a.fsf@development.richardriley.net> (Richard Riley's message of "Thu, 30 Oct 2008 16:06:57 +0100")
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
next prev parent reply other threads:[~2008-10-30 16:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2008-10-30 17:04 ` Richard Riley
2008-10-29 18:40 ` Sebastian Rose
2008-10-29 18:59 ` Sebastian Rose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bpx256ps.fsf@kassiopeya.MSHEIMNETZ \
--to=sebastian_rose@gmx.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).