LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Hans Aberg <[log in to unmask]>
Date:
Tue, 15 Dec 1998 23:00:02 +0100
In-Reply-To:
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (29 lines)
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 <mailto:[log in to unmask]>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

ATOM RSS1 RSS2