[OS X TeX] Re: typesetting script calls and iTeXMac and wrappers

Will Robertson will at mecheng.adelaide.edu.au
Mon Apr 19 21:01:59 EDT 2004

Jérôme Laurens wrote:

> This is one example that mimics the finder. Notice that, the file 
> names should be good looking to help the user.
> At the opposite side, the UI can hide completely how the document is 
> stored, to be more "logical".
> On opening the file, the front end reads all the files related to the 
> document, merges them, replaces the "\includegraphics" commands by the 
> real image and put all this in only one window.
> On saving, the front end knowns how to split the doc and save the good 
> content at the right location.
> The end user only sees one linear document whereas there can be many 
> different files in the data model.
> In order to avoid working on large texts, we can imagine a small 
> triangle widget to collapse or expand parts of the text,
> such that when everything is collapsed, we only see the structure of 
> the document.
> A good data model will serve both solutions, and more.

If you go to far with some of this thinking, you'll end up with a LyX 
clone. No point reinventing the wheel. My point is that many of these 
features are unrelated to the fact that a TeX wrapper exists. You could 
add features to iTeXMac now to collapse sections with triangle widgets 
if you wanted, and merge documents together on opening them. Features 
like this are nice, but IMO unnecessary in talking about a wrapper. I 
imagine many purists would dislike the option to have figures displayed 
inline, and it's something that could always be added after-the-fact.

>> The data model is something that I don't really understand. TeX 
>> documents are fairly self-sufficient at the moment as it stands, so I 
>> can't see how much extra information you could cram in there.
> Consider the following as missing from the data model
> - the string encoding
> - the EOL convention
> - the language(s)
> - the list of known words
> - the typesetting engine, including the options
> - the versions of the packages used (useful when things have changed)
> - the root file when the document is splitted
> for frontends
> - the size of the editing window
> - the position of the insertion carret
> - other options
> This makes a lot of information

It does make a lot of information, but nothing that couldn't be held by 
an arbitrary XML file. Write an initial set of attributes it can hold 
and implement them; if you want to add more features later, simply 
extend the XML description. I'm not disparaging your work so far, I 
think it is fantastic. If it's just wanting to finalise your data model 
that's holding you back however, I don't think you should be too worried 
about it. You have the right to implement as you see fit, because no-one 
else has come forward to assist in a collaborative effort.

That said, you have said you've implemented some basic stuff, so you may 
be at the stage that I'm thinking of already. But I wouldn't go so far 
as saying that you need a data model before you need a GUI. Many people 
have spoken recently about the importance of designing the GUI 
top-down---work out how it looks and functions to the use and then dig 
deeper and work out the guts of the thing. (eg see John Gruber in Daring 
Fireball <http://daringfireball.net/2004/04/spray_on_usability>.)

Please see <http://www.esm.psu.edu/mac-tex/> for list
guidelines, information, and LaTeX/TeX resources.

More information about the MacOSX-TeX mailing list