[OS X TeX] Re: typesetting script calls and iTeXMac and wrappers
will at mecheng.adelaide.edu.au
Tue Apr 20 03:01:59 CEST 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
Please see <http://www.esm.psu.edu/mac-tex/> for list
guidelines, information, and LaTeX/TeX resources.
More information about the macostex-archives