[OS X TeX] TeXShop's %& ugly bug
jerome.laurens at u-bourgogne.fr
Tue Sep 14 11:48:13 CEST 2004
Le 13 sept. 04, à 19:07, Curtis Clifton a écrit :
> On Sep 13, 2004, at 9:03 AM, Jérôme Laurens wrote:
>>> What configuration files? All that is required is a single XML file
>>> with some properly defined schema for:
>>> - File encoding
>>> - Intended typesetting script
>>> - Master file
>>> - Daughter files (I can see a possible advantage, but not strictly
>>> Is there even anything else required?
>> I already have presented XML file spec for this, in TUG2004
>> except that it does not cover the "Intended typesetting script" too
>> but adds an "End of line" and language support
> How can "intended typesetting script" be too complex to include in an
> XML file? XML can represent arbitrary directed graphs.
Yes, of course, you can implement easily the %! program = feature
TeXShop implements. But this is extremely limited.
How would you encode the BibTeX options the german user prefer?
How do you encode the engine used for the bibliography (there is a
forthcoming MLBibTeX which extends BibTeX)?
This "typesetting script encoding" should not be TeXShop centric, nor
even mac centric: this must fit the widest range of frontends whatever
system is used.
> Is your TUG paper available on-line?
See my TeX Wrapper Structure mail.
>> All the frontend specific data have nothing to do with that and must
>> live somewhere else
> Why couldn't the XML schema for the project be extensible to include
> front-end specific elements? It would be simple to require that
> front-ends ignore elements that they do not understand. This way
> iTeXMac and TeXShop specific data (for example) could live in separate
> branches of the XML tree without interfering. One could also use
> attributes attached to a "frontend" element:
- well XML files are not suitable for everything.
- If you only need the information stored in a subtree, you must manage
the whole tree
- if 2 apps want to manage their own data (for example a text editor
and a pdf viewer), they might have to write concurrently the same
files. it may lead to synch problems...
- The file system already has a tree structure.
So if the information follows a tree structures, some subtrees might be
stored as xml file, some leaves might be stored as single files and
other subtrees as directories. For some data, the single XML file is
more suitable, for other kind of information, a mixed mode seems more
Moreover, having a metadata folder in which you can put any kind of
thing is much more comfortable than a xml tree, for example the TeX
engine knows about the file system, but does not know anything of XML.
We can imagine to create a smart copy of the tex sources in the meta
data folder: duplicate the file hierarchy as smart links and run TeX
against the links. All these aux files are created in the smart
hierarchy and the original folders are left untouched. This would be
consistent because these aux file are just cached data, another kind of
--------------------- 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>
More information about the macostex-archives