Re: [Orgmode] Re: Org publish hierarchies and style variable
Richard Riley [EMAIL PROTECTED] 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 ___ 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
Re: [Orgmode] Re: Org publish hierarchies and style variable
Sebastian Rose [EMAIL PROTECTED] writes: Richard Riley [EMAIL PROTECTED] 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 ___ 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
Re: [Orgmode] Re: Org publish hierarchies and style variable
Richard Riley [EMAIL PROTECTED] 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 ___ 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
Re: [Orgmode] Re: Org publish hierarchies and style variable
Sebastian Rose [EMAIL PROTECTED] writes: Richard Riley [EMAIL PROTECTED] 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
