LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Tue, 28 Jan 2014 23:00:55 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (123 lines)
Am 27.01.2014 19:02, schrieb Sean Allred:
> Hello everybody,
> I recently asked a question on TeX.SX about potential graphical
> interfaces for document authors/designers with the new layering system
> of LaTeX3, but Joseph pointed out that it was probably more suited for
> this list.

well, as SX draws some interest around expl3 and LaTeX3 architecture and 
ideas and has a fairly broad audience it is not necessarily the wrong 
place to record what has been thought on those topics in the past.

However, it is clearly not suited as a discussion forum

> I reproduce it below:
>> With the separation of document authorship, design, and
>> implementation, is a graphical tool for the end-user within reach?

yes (well depends on what is called within reach :-)

>> LyX tries to do this today, but LaTeX2e is not well-designed for such
>> an approach.  In essence, this is what LaTeX3 tries to fix: authors
>> must not be concerned with how their document looks in contest with
>> the actual content of their work.  While LaTeX2e did successfully
>> separate markup from implementation, it could not cleanly separate the
>> *design* from its implementation (and everyone and their mother has a
>> word to say about design---this isn't going to change).  The layers of
>> LaTeX3 are designed to separate the implementation/coding from the
>> design from the content.  The amazing work so far on LaTeX3 is proof
>> enough that many people believe this separation is possible---myself
>> included.

that makes at least 2 :-)

>> Given this ideal of separation, will it be feasible for there to be
>> environments in which to author and design LaTeX documents in a way
>> that will put the power of LaTeX and `expl3` in high demand?
> So there you have it---given that the entire LaTeX3 system (looking also
> at `xtemplate`) seems to be going toward an system that has entirely
> different interfaces for more well-defined roles, has a truly graphical
> front-end (*not* a front-end such as LyX) been brought up?

if brought up in the sense of a wider discussion, then no, but it was 
definitely at our minds (mine for a start) when attempting experiments 
with xtemplate and LDB

> The `expl3` underworkings of the system must still be used directly as
> text---it doesn't make sense any other way---but there should be no
> reason an author should see this.  The simplicity of `xtemplate`s
> interface would allow for easy parsing, and graphical interfaces to
> objects/templates might be feasible.

exactly, even if xtemplate as it is now has its fault and should not be 
the final model, but (most of) the underlying ideas could.

What I have in mind here is something a bit in the spirit of "Batch 
commander", see

Basically, if you think in terms of current xtemplate then templates 
define objects and within some limits support modifying their 
representation by setting layout parameters that turn such a generic 
template into an "instance" with a fixed presentation.

Now what one could think of a template being a configuration spec that 
defines the boundaries (what parameters are available, what the value 
space is (eg limits, type of values), and some explanation what it does, 
default values (if any).

That kind of configuration could be read in by a GUI program that then 
supports via sliders and what have you turning a generic template into 
an instance.

One step further, the idea or say the realization is, that you can't 
really have "monster templates" that do everything, but that instead if 
the material gets complex enough, say headings, then you will end up 
with a bunch of templates all implement headings of some sort and all 
being interchangeable but all generating very different layouts.

To follow up on this idea, an intermediate step of such a GUI could be 
to allow for selecting a template or replacing a template with a 
different one (for the same object type) thereby changing the underlying 
set of parameters.

In summary:

   - The GUI could read in an existing "class instance" which is

       - a spec of "document class definition layer" spec (abstract) [1]
       + plus its realization with a bunch of templates and their chosen 
values turning the templates into instances

   - The Designer/(or the author acting as one) could then modify 
parameter values, or could do more drastic steps, by selecting a 
different template for some object and then getting potentially 
different parameters to set or change (from their default)

   - upon save, what gets written back is a new/modified "class 
instance" which is directly executable by L3 (ie with the current model 
a bunch of \DeclareInstance  jadajada

  - alternatively one could read in "just" a "document class definition 
layer" spec [1] in which case the GUI would display available templates 
to chose from for realization

now there is the small issue of LDB ideas which somewhat complicates or 
changes this picture a bit but on the whole this is what I think it 
should look like eventually.

Now the template stuff is perhaps not formal enough yet, but it was day 
one written with this kind of idea in mind


[1] for those who wonder what the hell a document class definition layer 
is .. see for example