Ivoatex

[Markus Demleitner]

Dear VO community,

On Wed, Aug 13, 2014 at 01:14:10PM +0100, Norman Gray wrote:
> [Replying to interop at ivoa.net -- should discussion of this take place here?]

No, I think we should move this discussion.  Since I couldn't see a
good place on existing IVOA lists, I've created a temporary list you
can subscribe to at

http://lists.g-vo.org/cgi-bin/mailman/listinfo/ivoatex-adhoc

This is really intended to be only active until we've sorted out
ivoatex.  If we find out that some continuing structure is desirable,
we'd move this to ivoa.net in some way, I guess.

I'm setting this mail's reply-to to the new list and would ask
everyone to continue the discussion there -- interop@ is really the
wrong place.


Just briefly on Norman's points:

> On 2014 Aug 13, at 11:11, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> A couple of random remarks:
> 
>   * \documentclass{ivoatex/ivoa}
> 
> It looks weird having a directory specifier in there.  Better might
> be to have the document class be simply {ivoa} and have the LaTeX

I had initially planned to try and not rely on kpathsea, which is
how that went in; the advantage would have been that people can just
write pdflatex file on their shell and things just work.

That changed when I briefly considered including some additional
resources for TeX in ivoatex, which is when this went in:

> 
> > TEXINPUTS=.;ivoatex
> 
> ...which is a Windows-style setting of this environment variable.
> The more usual one would be 

Oh, kpathsea treats semicolons as colons on unix-like systems, and
somehow I got into using them in kpathsea paths.  But a trailing
(semi)colon was missing, as was an export to make make put the stuff
into pdflatex's environment.  This is going in in rev. 2704.  And
since I'm going through all this trouble and I realise that
hardcoding the paths would make a later "system-wide installation"
option a major pain, I'm no longer using relative paths in the
template as of that revision, too.

> > TEXINPUTS=ivoatex:
> 
>   * \input ivoatex/tthdefs
> 
> That looks weird in a LaTeX document (which in any case doesn't
> acknowledge the existence of \input without {...braces...}.  It
> might be neater to rename tthdefs.tex to tthdefs.sty and include it
> with \usepackage{tthdefs}.  Also, why can't this be simply
> incorporated within ivoa.cls?

No -- that's tth magic.  tth, the program that makes html from the
TeX source, ignores LaTeX-style includes and in particular
non-standard class definitions.  So, this contains the special code
for HTML generation (hidden from pdflatex through some magic inside
tthdefs).

It sounds a bit daring, but I've found this to be fairly good to work
with.  Of course, you'll have to implement each feature in TeX and
HTML separately, but the effort is still moderate, the repeated code
minimal, and if there really was substantial shared code, it's not be
hard maintain that in a joined file.

> > * images: For now, we only really support pixel images; vector formats 
> > 	wouldn't be hard except for possible dependencies.  Talk to the authors
> > 	if you have a use case.  Otherwise, it's standard graphicx; there's
> > 	an example with the architecture diagram in the document template.
> 
> I presume this is a tth limitation, yes?

Well, as always it's a question of making things work both in the
browser and in whatever produces the PDF; I expect eps would almost
just work (package building would probably need to be fixed).  

My personal preference would be to author vector graphics in svg
(rather than eps or pdf), however; that's certainly not supported out
of the box, but I suspect it wouldn't be too tricky to make it
happen.  It would require changes in the makefile, though, and
probably some minor magic with tth, and some svn renderer as an
additional dependency.

Cheers,

         Markus