Suggested feature: Portable document archive

[Zdenek Wagner]

Hi all,

as already noted, such a scheme offers just basic possibilities. The
first problem is that you support two platforms only which means that
it is not portable. Looking at my everyday work I have to work in
Linux and cooperate with coauthors using Mac and Windows. My project
consist of a main file and one file per chapter, a custom package
file, bibliography file, sometimes custom bibliography style and an
index style for makeindex or a module for xindy. I need source files
for gnuplot, sometimes source files for octave, sometimes source files
for metapost, asymptote etc. I also need ICC profiles for colour
conversion. And, of course, I need processing by
perl/sed/awk/grep/bash. Most of it is portable if shared via
versioning systems.

A few years ago I was asked to prepare a package implementing a
graphical design for one company. They wanted to use it in MiKTeX and
Scientific Word. They also asked me for help with typesetting. I knew
how to do it in TeX, I have no experience with Scientific Word because
I use Linux. It lead the company to stop using Scientific Word because
they understood that work with vanilla TeX is easier and more
flexible.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

po 30. 12. 2019 v 23:04 odesílatel Barry MacKichan
<barry.mackichan at mackichan.com> napsal:
>
> I can provide another data point for this discussion.
>
> Scientific Word and Scientific WorkPlace use a scheme quite like this. The “native file type” extension for our documents is .sci, but in fact a .sci file is just a zip file under another name. By changing the extension we can change the default operation selected when the user double clicks on it.
>
> It is possible, by making some changes in the Windows registry, to make the .sci file behave like a zip file in some occasions and like a document in others. In particular, in the Windows file browser which shows the directory tree in one pane on the left and the directory contents in the other, the user can launch the program by clicking on the file on the right, or can open and explore the contents of the zip file by clicking on the right. The special treatment of zip files in Windows applies to .sci files as well.
>
> Here is what we keep in the .sci file:
>
> One or more xhtml files, a directory of css files, and a directory of graphics files — mostly these don’t apply to this discussion.
>
> A directory that contains a tex file generated by our program from the xhtml version of the document and temporary copies of the intermediate files generated by running TeX.
>
> Three directories that can contain graphics files which hold the original copy of a graphic imported by the user. If that graphic can’t be displayed in a browser, we run a conversion program to make a displayable copy. If neither of those can be imported into TeX, we also make a TeX-compatible copy. Thus there may be three copies of a graphic in some cases. The final PDF is also contained in the zipped package.
>
> We make no attempt to include any LaTeX package files or utility programs (we install some, but these are part of the installation and not part of the document). So the only guarantee is that the document can be compiled on an installation of our program on OSX or Windows, with a complete TeXLive installation. Smaller TeX installations usually work, but there is no guarantee that you won’t have to install a bit more.
>
> There is a command in our program to trim the fat in the .sci file. It removes temporary files, and depending on preferences, it might also remove the generated PDF and the conversions of the graphics and even the TeX file. I.e., it can go back to the minimum required to regenerate everything.
>
> The .sci file is agnostic about the TeX compiler used and so works with PDFLaTeX, LuaLaTeX, and XeLaTeX.
>
> The Mac version could easily have used OSX packages instead of zip files, but we decided it Was more important to be able to drag a file from Windows to a Mac and have everything work.
>
> —Barry MacKichan
>
> On 29 Dec 2019, at 3:25, Mojca Miklavec wrote:
>
> Dear Simon,
>
> On Sat, 28 Dec 2019 at 21:29, Simon Heisterkamp wrote:
>
> I'm the author of the MikteX feature suggestion 424: https://github.com/MiKTeX/miktex/issues/424
>
> ...
>
> I am open to contributing to the effort but would likely need substantial support from experience developers of tex-live.
>
> ...