On Thu, Apr 17, 2014 at 2:49 PM, Bastien <b...@gnu.org> wrote:
> How would that be different that zipping org files along with pictures
> and related needed content?
Not different at all. Integrating the zipping into org-mode itself
could standardize the process and make it more
repeatable, portable, and convenient. Microsoft Word .docx files have
something like this structure inside:
.
├── [Content_Types].xml
├── _rels
├── docProps
│ ├── app.xml
│ ├── core.xml
│ └── thumbnail.jpeg
└── word
├── _rels
│ └── document.xml.rels
├── document.xml
├── fontTable.xml
├── media
│ └── image1.png
├── settings.xml
├── styles.xml
├── stylesWithEffects.xml
├── theme
│ └── theme1.xml
└── webSettings.xml
An analogous structure inside a filename.orgz container might be
useful. Perhaps something like:
.
├── orgmain.org
├── config.org
├── media
│ └── image1.png
├── elisp
│ ├── init.el
│ └── myorgmacros.el
├── babel
└── export
├── styles
└── output
├── orgmain.pdf
└── orgmain.html
A little elisp wizardry could ensure that invoking
emacs filename.orgz
would actually open and edit orgmain.org inside filename.orgz.
Much of the tree structure could be optional, only included when
certain features are used. Obviously, it would be necessary to put
exported files outside of the .orgz file. But optionally including a
copy inside could be useful. More important would be the inclusion of
all non-standard input files needed to generate the output, things
like images, elisp files, latex and html style files, etc. Maybe even
a copy of the Emacs initialization file used when saving the container
file. Finally, a standardized format for config.org would include
things like Emacs version, Org version, creation date, modification
date, a list of manually included files, etc.
