X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1426" "Tue" "15" "December" "1998" "23:00:02" "+0100" "Hans Aberg" "haberg@MATEMATIK.SU.SE" nil "29" "Re: portable LaTeX" "^Date:" nil nil "12" nil nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.8/8.8.8) with ESMTP id XAA27792; Tue, 15 Dec 1998 23:00:11 +0100 (MET) Received: from lsv1.listserv.gmd.de (192.88.97.2) by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <0.1AF80693@listserv.gmd.de>; Tue, 15 Dec 1998 23:00:00 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 413985 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 15 Dec 1998 22:59:52 +0100 Received: from mail0.nada.kth.se (mail0.nada.kth.se [130.237.222.70]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA19232 for ; Tue, 15 Dec 1998 22:59:43 +0100 (MET) Received: from [130.237.37.97] (sl40.modempool.kth.se [130.237.37.60]) by mail0.nada.kth.se (8.8.7/8.8.7) with ESMTP id WAA11018 for ; Tue, 15 Dec 1998 22:59:41 +0100 (MET) X-Sender: su95-hab@mail.nada.kth.se References: <199812151808.MAA19057@dcdrjh.fnal.gov> <13938.39518.68424.927988@fell.open.ac.uk> <199812092035.VAA16014@na6.mathematik.uni-tuebingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <4.1.19981215153705.00aea0a0@tiac.net> Date: Tue, 15 Dec 1998 23:00:02 +0100 From: Hans Aberg Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: portable LaTeX Status: R X-Status: X-Keywords: X-UID: 3165 At 15:40 -0500 1998/12/15, Y&Y, Inc. wrote: > You can't sell a printer to a significant number >of people *unless* it has this kind of support for major operating systems. >The application should *not* have to worry about this. There should >not be a need for a DVILJ, DVIPS, DVIXYZ DVIEpson, DVIFax driver. >There should be *ne* driver. Systems that have M applications and N >resources, can then be dealt with using N + M software modules >rather than N * M. I think this is the argument for developing such a "graphical bytecode". In the generalization, I think this is why object orientation and the layering of computer structures (such as languages and various interpreters) are important: If these components interface, one needs only a few of them; otherwise one needs one for each possible combination, which quickly rises to a prohibitively large number if the number of components is large. So with links stuff, which survives the DVI and PS special command into PDF, it is just a patch: If one would be forced to do such a patch with every new feature one wants to use from TeX, then it would be cumbersome. So it is better to let TeX expand directly into some more advanced extended DVI. Hans Aberg * Email: Hans Aberg * Home Page: * AMS member listing: