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

[Jérôme Laurens]

Le 19 avr. 04, à 11:44, Will Robertson a écrit :

> Jérôme Laurens wrote:
>
>> Le 17 avr. 04, à 15:21, William F. Adams a écrit :
>>
>>>  I was quite disappointed that things didn't work out better w/ the 
>>> Wrapper bit.
>>
>> So was I.
>
> Make that another, but I'm still optimistic for the future.
>
>> IMHO, we need a real TeX Wrapper Structure implemented to start the 
>> discussion and gather a sufficiently wide audience.
>> I will have a very basic one implemented for TUG2004, based on the 
>> discussion on the TeX Wrapper List.
>> Maybe people will be interested and will contribute then to the 
>> project.
>
> I plan on becoming more pro-active in the future and working on 
> something like this would interest me greatly. But I can't guarantee 
> anything, unfortunately. Depends how my time goes. But that's a very 
> exciting beginning!
>
>>
>> The problem of the UI is another question: when the data model is 
>> bad, the UI cannot be good.
>> So, for a good UI, we must start with a good data model.
>> Afterwards we will focus on a good and simple UI.
>
> In my head, I can't imagine the UI side of things being that tricky if 
> you simple mirror the file structure inside the wrapper in a separate 
> window (like a mini-Finder window). To add content (images, etc) Use 
> an Import menu command or Drag-and-drop.

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.

>
> 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

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