LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 2 Feb 2014 22:13:26 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
Hi Paulo,

> A direct mapping from a graphical model to a code implementation is very
> interesting, but we might end up with a poor generated code, and this
> might compromise the whole project IMHO. :(

I think you have misinterpreted Sean's intention (or perhaps I have). In 
any case I wasn't speaking about a GUI that generates LaTeX document 
code, all I was talking about was a graphical representation of 
underlying templates so not really something fancy.

If you think about an independent graphical model that you manipulate 
with the cursor (or some other tool and that then magically turns your 
action into code, then I agree it will probably start out nice but 
eventually you will end up with very bad internal code once things get 
more complex and you need to cater for all the stuff you originally 
haven't foreseen.

Take headings for example, there are million ways to specify and 
manipulate portions and there is (imho) no way that a GUI could 
interpret graphical manipulations and turn them into "correct" code.

This is why I think a better way is to allow for exchangeable templates 
that implement a certain document element but may have different 
graphical features and manipulation possibilities.

For me a Designer GUI would then not much more than an easy way to 
manage such templates, select them and manipulate their bells and whistles.


Such a GUI could be part of a system like LyX but it doesn't have to.

It would also be possible to nicely combine it with (nearly) 
instantaneous realization where a given (or produced) test document is 
compiled and changes being presented more or less directly after they 
are done


> I have a couple of systems that export things to LaTeX and the way I do
> this is via templating. Roughly speaking, you merge data with model and
> get the document. Along these lines, we could have a n-layered
> templating framework, with one template for each layer of "data" and
> with a well-established interface between them.
>
> Maybe a hybrid tool that allows users fill the blanks while relying on
> templates is a good way of making people more close to L3: customers get
> what they want and a good code is available. :)

would like to see what you have done in this space but from what I 
gather it isn't so much different from what I have in mind.

> But that's just my humble opinion. :) Maybe if you could provide some
> sketches on what you were thinking, we could work on them.

that would be a great idea :-) ... and I see Sean already come up with 
some mockups

frank

ATOM RSS1 RSS2