From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Riley Subject: Re: Re: Org publish hierarchies and style variable Date: Thu, 30 Oct 2008 18:04:11 +0100 Message-ID: References: <87d4hj9zvm.fsf@fastmail.fm> <873aifs2nu.fsf@gollum.intra.norang.ca> <87skqe5cvr.fsf@kassiopeya.MSHEIMNETZ> <87bpx256ps.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 1KvawY-0001jD-Nh for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 13:04:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvawX-0001iT-2V for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 13:04:22 -0400 Received: from [199.232.76.173] (port=38726 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvawW-0001iP-UA for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 13:04:20 -0400 Received: from mu-out-0910.google.com ([209.85.134.189]:31755) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvawW-0001Wg-1L for emacs-orgmode@gnu.org; Thu, 30 Oct 2008 13:04:20 -0400 Received: by mu-out-0910.google.com with SMTP id i2so636309mue.6 for ; Thu, 30 Oct 2008 10:04:18 -0700 (PDT) In-Reply-To: <87bpx256ps.fsf@kassiopeya.MSHEIMNETZ> (Sebastian Rose's message of "Thu, 30 Oct 2008 18:32:47 +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: Sebastian Rose Cc: emacs-orgmode Org-Mode Sebastian Rose writes: > 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 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: >> >> 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 > > > > > 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: >> :#+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. 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