Ivoatex

[Francoise Genova]

Dear Markus,

It is good anyway that the IVOA community knows that this proposal is 
upon the table. For the non-techies like me, it would be useful to know 
the consequencies in their everyday life if any, since even people like 
me can have to produce IVOA documents. But at this stage the discussion 
can move elsewhere.

Also, the Document Coordinator should be involved I think, but obviously 
not through interop at ivoa.

Cheers

Francoise

Le 13/08/2014 16:04, Markus Demleitner a écrit :
> 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