[OS X TeX] TeX wrappers

[Jérôme Laurens]

Le 14 sept. 04, à 16:20, Bruno Voisin a écrit :

> Le 14 sept. 04, à 15:17, Massimiliano Gubinelli a écrit :
>
>>  The issue of extracting the pdf should be considered, from the point 
>> of view of a user interfaces, as a conversion from .texd  to .pdf. 
>> Something like "Extract PDF To File..." or "Write PDF To file...".
>
> For those that did use Textures on earlier Mac OSes, this is exactly 
> how things worked from the user point of view: a Textures document was 
> a single file, containing the input text (the .tex file) in the data 
> fork and TeX's output (the .dvi file) as separate resources (one per 
> page) in the resource fork. Opening the file opened two windows, one 
> containing the input text and the other containing the output view; 
> using Save saved the file with this structure, while Save As had 
> allowed selection of DVI format: in that case a standard .dvi file was 
> created, that could be transferred to other platforms.

The difference is that a filter need not be tied to any application and 
can be just a system service.

>
> This wasn't specially well suited for LaTeX, which still required 
> separate input files, some of them having then purposeless DVI 
> resource forks, but Textures was really designed with plain TeX in 
> mind.
> For this, bundles (or wrappers), as allowed by OS X, would provide 
> superior integration and user experience. The only thing I fear is 
> that, by looking at something very wide-ranging and ambitious, 
> integrating projects, CVS, and more, the initial simplicity of the 
> Textures-like interface (Open, Save, Save As, a Pictures window for 
> importing images, etc.) would be lost. That would be a pity.

There is now a a paradigm named MVC for Model-View-Controller suitable 
for GUIs

The model answers the questions
- what is the information?
- how is it stored?

The view answers the question
- how the information is displayed?

The controller simply makes the link between them and is the most 
delicate part.

The view doesn't care about how information is stored or organised, the 
model doesn't care about how the information will be displayed.
Both live their own life. All the real  job is made by the controller 
(and the programmer who designs the controller indeed).

The view can decide to display less information that is available in 
the model, for the sake of simplicity.
A good data model allows at the same time simple GUI for newbies and 
advanced ones for experts.

As we are mainly discussing the data model, so you should not be afraid 
of the User Interface...

But all this is theoretical... :-(

BTW, Cocoa and MVC go rather well together...

>
> Back to Textures, the resource fork was also the repository for 
> document-specific metadata such as encoding, font and font size for 
> the input window, position of pointer the last time the document was 
> saved, position of page and magnification for the input window, window 
> size and position of windows on screen, etc. It would seem more 
> natural to keep the same structure, i.e. a separate meta-data file as 
> opposed as cryptic informations in the main .tex input file, for a 
> bundle structure.
>
> On related matters, I agree with Ross Moore that trashing auxiliary 
> files may be a bad idea: there are some old .tex files of mine that I 
> would like to print again now, but I can't, because I hadn't created a 
> .ps or .pdf out of them then, and unfortunately I can no longer use 
> their .dvi or .tex content because they required special fonts or 
> versions of packages that are no longer available. Bundles would 
> eliminate this kind of disagreement, while still keeping the auxiliary 
> files hidden which I think is a bonus from the user point of view: for 
> those of us that aren't developers and that have grown, computer-wise, 
> with the Mac, it feels unnatural and ugly to have, for each document, 
> directories containing several files, some of them with identical 
> names and different extensions, instead of (something appearing as) a 
> single file.

AFAIK, one reason TeX has not evolved since years is that kind of 
compatibility problem.
But the problem is there and has moved to macro versioning and fonts.
The technical question is:

is the log file sufficient to retrieve the correct environment?

The problem with the log file is that it cannot be parsed automatically 
with 0% error due to its lack of syntax.
This can pose problems to newbies, and unfortunately, we cannot expect 
everyone leaving sometimes the newbie TeX level...

There can be also the output of some file I/O tracking made by tex with 
an appropriate option.

--------------------- Info ---------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
           & FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Post: <mailto:MacOSX-TeX at email.esm.psu.edu>