From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Rose Subject: Re: Re: Org publish hierarchies and style variable Date: Thu, 30 Oct 2008 18:32:47 +0100 Message-ID: <87bpx256ps.fsf@kassiopeya.MSHEIMNETZ> References: <87d4hj9zvm.fsf@fastmail.fm> <873aifs2nu.fsf@gollum.intra.norang.ca> <87skqe5cvr.fsf@kassiopeya.MSHEIMNETZ> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvaPg-0003Ek-8C for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 12:30:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvaPd-0003DG-Ht for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 12:30:22 -0400 Received: from [199.232.76.173] (port=59768 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvaPd-0003DD-Bz for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 12:30:21 -0400 Received: from mail.gmx.net ([213.165.64.20]:40835) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KvaPd-0001IT-9r for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 12:30:21 -0400 In-Reply-To: (Richard Riley's message of "Thu, 30 Oct 2008 16:06:57 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode Org-Mode Richard Riley 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: > > 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 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: > :#+STYLE: echo ''; >> :#+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