karl@dartvax.UUCP (Karl Berry.) (06/23/85)
I believe that TeX doesn't have graphics capability only because TUG, or some other body, hasn't agreed on a standard yet. Certainly the program can handle it. Also, although it is no doubt possible to write a format to generate output on CRTs, as Rusty Wright suggests, it would perhaps be simpler to write a dvi driver. For example, on Unix* systems, this would allow considerably simpler access to screen routines for the output, and a dvi2screen program can handle font changes as well as a format. dartvax!karl karl@dartmouth.csnet
rusty@sdcarl.UUCP (rusty c. wright) (06/24/85)
>I believe that TeX doesn't have graphics capability only because TUG, or >some other body, hasn't agreed on a standard yet. Certainly the program can >handle it. > >Also, although it is no doubt possible to write a format to generate output >on CRTs, as Rusty Wright suggests, it would perhaps be simpler to write a >dvi driver. For example, on Unix* systems, this would allow considerably >simpler access to screen routines for the output, and a dvi2screen program >can handle font changes as well as a format. > >dartvax!karl karl@dartmouth.csnet I don't think that it's that simple (to just write a dvi2tty program). You have to modify TeX as well (the plain.tex file). For example (the obvious one to me), if the user specifies using a font that is 36 point (for example) then TeX is going to use both vertical and horizontal spacing for 36 point letters while that font is in effect (it derives this spacing from the .tfm file and the specified magnification). When the dvi2tty program prints the chars every one in the file/document is going to be printed at the same size, about 10 point, (because they are on a crt, line printer, etc.) and the spacing is going to look funny in those places where the user changed the point size (magnification). It just occured to me that there are really two problems; changing fonts and changing the magnification. In TeX you can get a different sized font by either loading that font, for example cmr12 (computer modern roman, 12 point), or instead you could load cmr6 magnified to 12 point (there is an issue of design size that i'll bypass here). You can also set a global magnification that causes the entire document to be magnified (so that you can subsequently photo reduce it). I guess you'd have to modify the plain.tex file to perhaps ignore magnification requests. As i said in my previous note, i haven't really thought a lot about this. When i think about it i tend to think about what nroff does when handed troff input. I suspect that part of the reason that the TeX project isn't too hot about the idea is because one of the nicest things about TeX is that your output is always the same regardless of where you produced it; you can run your input through TeX on an ibm pc, a vax running vms, a vax running unix, an ibm mainframe, a 68000 based sun, etc. and they'll all produce identical output. Once you start using a TeX that can produce output for a tty then you suddenly break that uniformity. I have personally been in the situation where we didn't have a laser printer for many years and only had a diablo (daisy wheel) printer and always used nroff. When we got our laser printer we had to go through all of the stuff we had produced with nroff and fix it up so that it would look right with troff instead of just with nroff. When you only use nroff you inadvertently and unknowingly wire into your document nroff specific stuff. Even to this day i have gotten documents that have parameters in them that are tuned to that place's particular printer. Also notice that troff/nroff support conditionals that say "do this if we're troff" and "do this if we're nroff". And this is what i think the Stanford TeX group doesn't want. They want complete, homogenous uniformity. This is why there has been such venom from David Fuchs (one of the Stanford TeX bigwigs) over Imagen distributing an old version of the Computer Modern TeX fonts (Imagen claims that it is too much hassle to keep up with the shifting sands of Computer Modern and when it solidifies then they'll distribute that final version). -- rusty c. wright {ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!rusty
furuta@uw-beaver (Richard Furuta) (06/27/85)
I have seen one program, written by folks at Ohio State University for Tops-20, that dumps DVI into a file. What they do is to round off the DVI file's notion of where the character goes to the resolution of the fixed width character set that they assume is being used to print out the file. If there already is a character in that position on the file page then they discard one or the other (I don't recall which). In other words, they throw away font and size distinctions. The result is a pretty jumbled up sequence with missing characters, etc., but it's vaguely readable and is useful when you're trying to figure out alignments and page breaks without printing an actual copy. If you set the DVI file with a fixed width type face, of course, things would probably work out pretty well. The other possibility would be to do something like David Fuchs' DVI to Epson driver on the PC. Scan through the DVI file, dumping characters when you see them. A useful extension would be to put in the line breaks. This'd allow you to at least read little parts of the DVI file. Both of these sound like they'd be potentially simple modifications of DVItype. What I really want is for someone to write me a screen previewer for the Macintosh. At that point, I'd claim that bitmapped screens *were* generally available for everyone and that these hacks didn't require more attention. --Rick
percus@acf4.UUCP (Allon G. Percus) (06/28/85)
> What I really want is for someone to write me a screen previewer for the > Macintosh... I believe this has been done by someone at SARA in the Netherlands. Offhand I don't know who, but I can check. A. G. Percus (ARPA) percus@acf4 (NYU) percus.acf4 (UUCP) ...!ihnp4!cmcl2!acf4!percus
pjg@unrvax.UUCP (Paul Graham) (06/29/85)
<> In article <1346@uw-beaver> furuta@uw-beaver.UUCP (Richard furuta) writes: >The other possibility would be to do something like David Fuchs' DVI to >Epson driver on the PC. Scan through the DVI file, dumping characters when >you see them. A useful extension would be to put in the line breaks. >This'd allow you to at least read little parts of the DVI file. > >What I really want is for someone to write me a screen previewer for the >Macintosh. At that point, I'd claim that bitmapped screens *were* generally >available for everyone and that these hacks didn't require more attention. > > --Rick What *I* really want is a clean, portable DVI to moderate resolution dot matrix printer. Admittedly Macs are cheap but an FX-85 is quite a bit cheaper. After all an important motivation for acquiring TeX is the tremendous benefit/cost ratio which implies that many of the sites using TeX won't have a double-handfull of Macs around for people to use for previewing. I might feel better if the target was an IBM PC rather than the Mac. -- Thanks for your time. Paul Graham 702/784-6007 {seismo, ucbvax!menlo70}!unr70!unrvax!pjg unr70!unvax!pjg@seismo.ARPA
furuta@uw-beaver (Richard Furuta) (07/04/85)
>> What I really want is for someone to write me a screen previewer for the >> Macintosh... > >I believe this has been done by someone at SARA in the Netherlands. >Offhand I don't know who, but I can check. The SARA previewer is for the older version of TeX and DVI files and doesn't fit the current need. I believe it also uses it's own, nonstandard, set of fonts. There are a number of issues that need to be thought about in order to do this right. The SARA previewer, for example, expects to find the DVI file on the Mac disk. I'm not sure that this is the proper approach, lacking a TeX for the Macintosh, since that requires that you be able to do binary file transfers from your host computer to the Mac, requires that you transfer the entire file to see a few pages, and limits the overall size of the DVI file to 400 K. --Rick
jmsellens@watmath.UUCP (John M Sellens) (07/05/85)
In article <369@unrvax.UUCP> pjg@unrvax.UUCP (Paul Graham) writes: >What *I* really want is a clean, portable DVI to moderate resolution dot >matrix printer. Admittedly Macs are cheap but an FX-85 is quite a bit >cheaper. ... I might feel better if the target was an IBM PC rather than >the Mac. I thought that someone would say this, but no one has yet: There are several implementations of TeX for the PC that print on Epson printers. In fact, there is one that is very reasonbaly priced - we're getting 10 licences (i.e. only 1 set of disks and docs) for about $75US each(?). John
percus@acf4.UUCP (Allon G. Percus) (07/05/85)
> The SARA previewer is for the older version of TeX and DVI files and doesn't > fit the current need. Oh. A. G. Percus (ARPA) percus@acf4 (NYU) percus.acf4 (UUCP) ...!ihnp4!cmcl2!acf4!percus
root@bu-cs.UUCP (Barry Shein) (07/06/85)
Just to throw my 2c in, ya oughta see what Xerox is doing with their systems: What you see is what you get editors (full font on 1K X 1K bit-mapped screens), ethernet print servers, integrated graphics and a lot more though last I saw they were *not* up to speed on technical typing (should be easy for them, there are some glimmers in the latest release of this happening.) Also, integrated text/research data-bases (ask about NoteCards.) My experience is on their Dandelions. I personally think that batch oriented text processors are on their way out rapidly (except maybe as intermediate languages.) Use troff/nroff if you need preview till your real system arrives. As the expression goes, you're probably kicking a dead whale up the beach. (hey, Fortran was great in its time also.) -Barry Shein, Boston University Usual disclaimers.