From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: Embedding an image in base64; exporting to ascii, html, and latex? Date: Sat, 19 Apr 2014 16:37:19 -0400 Message-ID: References: <8738hc6k1v.fsf@bzg.ath.cx> <87zjjjx047.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f13ed208f64dc04f76b3b05 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wbc0p-00063Z-W0 for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 16:37:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wbc0o-0003z1-Fc for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 16:37:23 -0400 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Skip Collins Cc: Bastien , "emacs-orgmode@gnu.org" , Grant Rettke --e89a8f13ed208f64dc04f76b3b05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wrote some code that does some of this here: http://kitchingroup.cheme.cmu.edu/blog/2014/03/05/Creating-a-transportable-= zip-archive-of-an-org-file/ It doesn't do anything fancy like you describe, but it does get images and files into the zip file. John ----------------------------------- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Fri, Apr 18, 2014 at 9:27 AM, Skip Collins wrote= : > On Thu, Apr 17, 2014 at 2:49 PM, Bastien 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: > . > =E2=94=9C=E2=94=80=E2=94=80 [Content_Types].xml > =E2=94=9C=E2=94=80=E2=94=80 _rels > =E2=94=9C=E2=94=80=E2=94=80 docProps > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 app.xml > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 core.xml > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 thumbnail.jpeg > =E2=94=94=E2=94=80=E2=94=80 word > =E2=94=9C=E2=94=80=E2=94=80 _rels > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 document.xml.rels > =E2=94=9C=E2=94=80=E2=94=80 document.xml > =E2=94=9C=E2=94=80=E2=94=80 fontTable.xml > =E2=94=9C=E2=94=80=E2=94=80 media > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 image1.png > =E2=94=9C=E2=94=80=E2=94=80 settings.xml > =E2=94=9C=E2=94=80=E2=94=80 styles.xml > =E2=94=9C=E2=94=80=E2=94=80 stylesWithEffects.xml > =E2=94=9C=E2=94=80=E2=94=80 theme > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 theme1.xml > =E2=94=94=E2=94=80=E2=94=80 webSettings.xml > > An analogous structure inside a filename.orgz container might be > useful. Perhaps something like: > . > =E2=94=9C=E2=94=80=E2=94=80 orgmain.org > =E2=94=9C=E2=94=80=E2=94=80 config.org > =E2=94=9C=E2=94=80=E2=94=80 media > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 image1.png > =E2=94=9C=E2=94=80=E2=94=80 elisp > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 init.el > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 myorgmacros.el > =E2=94=9C=E2=94=80=E2=94=80 babel > =E2=94=94=E2=94=80=E2=94=80 export > =E2=94=9C=E2=94=80=E2=94=80 styles > =E2=94=94=E2=94=80=E2=94=80 output > =E2=94=9C=E2=94=80=E2=94=80 orgmain.pdf > =E2=94=94=E2=94=80=E2=94=80 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. > > --e89a8f13ed208f64dc04f76b3b05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It doesn't do anything fancy like you describe, but it does g= et images and files into the zip file.
=
John

-----------------------------------
J= ohn Kitchin
Associate Professor
Doherty Hall A207F
Department of Chemical Enginee= ring
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803<= br>http://k= itchingroup.cheme.cmu.edu



On Fri, Apr 18, 2014 at 9:27 AM, Skip Co= llins <skip.collins@gmail.com> wrote:
On Thu, Apr 17, 2014 at 2:49 PM, Bastien <bzg@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:
.
=E2=94=9C=E2=94=80=E2=94=80 [Content_Types].xml
=E2=94=9C=E2=94=80=E2=94=80 _rels
=E2=94=9C=E2=94=80=E2=94=80 docProps
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 app.xml
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 core.xml
=E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 thumbnail.jpeg
=E2=94=94=E2=94=80=E2=94=80 word
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 _rels
=C2=A0 =C2=A0 =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 document.xml.rel= s
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 document.xml
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 fontTable.xml
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 media
=C2=A0 =C2=A0 =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 image1.png
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 settings.xml
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 styles.xml
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 stylesWithEffects.xml
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 theme
=C2=A0 =C2=A0 =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 theme1.xml
=C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 webSettings.xml

An analogous structure inside a filename.orgz container might be
useful. Perhaps something like:
.
=E2=94=9C=E2=94=80=E2=94=80 orgmain.org
=E2=94=9C=E2=94=80=E2=94=80 config.org
=E2=94=9C=E2=94=80=E2=94=80 media
=E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 image1.png
=E2=94=9C=E2=94=80=E2=94=80 elisp
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 init.el
=E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 myorgmacros.el
=E2=94=9C=E2=94=80=E2=94=80 babel
=E2=94=94=E2=94=80=E2=94=80 export
=C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 styles
=C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 output
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 orgmain.pdf
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 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.


--e89a8f13ed208f64dc04f76b3b05--