pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/06/90)
On 4 Dec 90 21:14:19 GMT, ronald@robobar.co.uk (Ronald S H Khoo) said:
ronald> rstevens@noao.edu (Rich Stevens) writes:
rstevens> Speaking of which, does anyone know the status of troff and
rstevens> man-pages for 4.4BSD ? [ ... ] or else they were going to
rstevens> reformat all the man pages in TeX and use TeX for the man
rstevens> pages.
They could ship g++ and groff; after all they already use gcc as their
compiler.
ronald> NO! PLEASE NO! Even shipping "awf" the "awf"ully slow nroff
ronald> -m(s|an) replacement written in awk by Henry Spencer would be
ronald> better than that!
Well, I agree that teX is atrocious (even if there is now a fairly good
and updated C implementation from Pat Monardo). But TeXInfo is not that
horrible, and the makeinfo and info previewers are are not that horrible
either. I have often considered myself turning all the man pages over to
TeXInfo format.
Naturally this as always leaves the problem of getting TeX to print
decently (dvidoc does not quite get it right) on any low resolution
device. I may well look into this eventually; all we need is to modify
TeX so that it does all positioning in units that are a multiple of its
fundamental resolution, just like ditroff does already.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukjeffrey@cs.chalmers.se (Alan Jeffrey) (12/07/90)
In article <PCG.90Dec6145328@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: [...] >Naturally this as always leaves the problem of getting TeX to print >decently (dvidoc does not quite get it right) on any low resolution >device. I may well look into this eventually; all we need is to modify >TeX so that it does all positioning in units that are a multiple of its >fundamental resolution, just like ditroff does already. No thanks! TeX has got to be device-independent, if you're planning to use if for serious 2000dpi typesetting, with proofs at 300dpi and previews as low as 72dpi. TeX does a pretty decent job of placing text where you want it, it's the device drivers that often can't cope. The TeX divice driver standards committee should (hopefully) sort that out, although the number of current drivers that would get the seal of approval is probably horribly small... >Piercarlo Grandi Cheers, Alan. -- Alan Jeffrey Tel: +46 31 72 10 98 jeffrey@cs.chalmers.se Department of Computer Sciences, Chalmers University, Gothenburg, Sweden
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/13/90)
On 7 Dec 90 11:53:15 GMT, jeffrey@cs.chalmers.se (Alan Jeffrey) said:
jeffrey> In article <PCG.90Dec6145328@odin.cs.aber.ac.uk>
jeffrey> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> Naturally this as always leaves the problem of getting TeX to print
pcg> decently (dvidoc does not quite get it right) on any low resolution
pcg> device. I may well look into this eventually; all we need is to modify
pcg> TeX so that it does all positioning in units that are a multiple of its
pcg> fundamental resolution, just like ditroff does already.
jeffrey> No thanks! TeX has got to be device-independent, if you're planning
jeffrey> to use if for serious 2000dpi typesetting, with proofs at 300dpi and
jeffrey> previews as low as 72dpi. TeX does a pretty decent job of placing
jeffrey> text where you want it, it's the device drivers that often can't cope.
No, this is unfortunately wrong. Currently TeX assumes an output device
of nearly infinite precision, and with all the CM fonts and symbols. The
problem is that no such device exists; for high resolution devices where
CM can be downloaded the mapping from the ideal device to the actual
device can be done in some haphazard way in the DVI driver.
The problem is tht while you can a device independent output format, you
cannot really have device independent output. For example you may use a
symbol that exists on some printers but non on others. Or, you may want
to output to a printer has has only fixed width fonts and no
proportional fonts, not to mention CM.
In order to have the best results for type of printer one must produce
different DVI files; it is no good to have a DVI file that was built
assuming the printer had CM fonts with their widths and trying to
print in Apalatino (TM) on a PostScript device. You *can* do it in the
DVU postprocessor, but the output will be ugly, as it will have to print
Palatino characters at positions determined by CM widths.
What we need for efficient printing of TeX(info) output on fixed pitch
printer is a set of font descriptions that specify constant width fonts
throughout and glue that stretches only by fixed increments for
interword and interline spacing. Dvidoc seems a start in this direction;
does anybody know of any more advanced technology?
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukem@dce.ie (Eamonn McManus) (12/19/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In order to have the best results for type of printer one must produce >different DVI files; it is no good to have a DVI file that was built >assuming the printer had CM fonts with their widths and trying to >print in Apalatino (TM) on a PostScript device. You *can* do it in the >DVU postprocessor, but the output will be ugly, as it will have to print >Palatino characters at positions determined by CM widths. > >What we need for efficient printing of TeX(info) output on fixed pitch >printer is a set of font descriptions that specify constant width fonts >throughout and glue that stretches only by fixed increments for >interword and interline spacing. Dvidoc seems a start in this direction; >does anybody know of any more advanced technology? Dvidoc requires you to input a special macro file that sets up the various fonts and dimensions to be suitable for fixed-width output. So effectively it does produce a different DVI file. Unfortunately, the commonly distributed version does not do the settings very well (e.g., the line spacing is not the same as the font height). It's possible to get over these problems with a bit of work. For something like manual pages which use a canned format and (hopefully) little direct invocation of TeX primitives it is quite easy to produce perfect output with dvidoc. I have done this on a project involving a substantial number of manual entries. One problem is that there isn't anyone working on dvidoc at the moment who might incorporate improvements like this. If anyone wants to volunteer I can send them the work I have done. It's more than a year since I was involved with it so I have forgotten all the details. , Eamonn
jeffrey@cs.chalmers.se (Alan Jeffrey) (12/20/90)
In article <PCG.90Dec12193003@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 7 Dec 90 11:53:15 GMT, jeffrey@cs.chalmers.se (Alan Jeffrey) said: > >jeffrey> No thanks! TeX has got to be device-independent, if you're planning >jeffrey> to use if for serious 2000dpi typesetting, with proofs at 300dpi and >jeffrey> previews as low as 72dpi. TeX does a pretty decent job of placing >jeffrey> text where you want it, it's the device drivers that often can't cope. > >No, this is unfortunately wrong. Currently TeX assumes an output device >of nearly infinite precision, and with all the CM fonts and symbols. The >problem is that no such device exists; for high resolution devices where >CM can be downloaded the mapping from the ideal device to the actual >device can be done in some haphazard way in the DVI driver. Well, this is true at the moment, but `haphazard' should gradually be replaced by `standard' as the device driver standard sets in. And TeX makes no assumptions (well, almost none) about the fonts you're using, it's the plain format that does. [...] >In order to have the best results for type of printer one must produce >different DVI files; it is no good to have a DVI file that was built >assuming the printer had CM fonts with their widths and trying to >print in Apalatino (TM) on a PostScript device. You *can* do it in the >DVU postprocessor, but the output will be ugly, as it will have to print >Palatino characters at positions determined by CM widths. Certainly, in order to produce perfect output you'd have to produce a device-dependent .dvi file, but at high resolutions you can't spot the difference anyway (assuming you got the right .tfm file for your fonts etc.) and you can't get perfect output out of a laser printer anyway. Why anyone would want to print a .dvi file with font substitutions is beyond me, except as a proofing mechanism, and it's not exactly TeX's fault if the result of such a massacre looks rather grotty. The problem is that TeX is designed for producing books on 1270dpi and up printers, and it's output is rather compromised for anything else. TeX views laser printers as proofing devices, and doesn't take much effort about precise spacing at low resolutions. If you want device dependent .dvi files though, it's not that hard to get them by a metafont hack that produces letter-widths and kerns at multiples of the device pixel width (see how the gray font works for details). Inter-word spacing would still be at arbitrary precision, but inter-word jumps aren't nearly as noticable as inter-letter jumps, as long as you're printing on a variable-pitch printer. If you're living with fixed-pitch, give up and use something else. TeX is designed for producing beautiful books, so it's not a question of how well the bear dances at 120dpi, but that it dances at all. >Piercarlo Grandi God Jul, Alan -- Alan Jeffrey Tel: +46 31 72 10 98 jeffrey@cs.chalmers.se Department of Computer Sciences, Chalmers University, Gothenburg, Sweden
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/26/90)
On 20 Dec 90 13:05:02 GMT, jeffrey@cs.chalmers.se (Alan Jeffrey) said: [ ... on how to make TeX produce output for a fixed pitch device ... ] jeffrey> Certainly, in order to produce perfect output you'd have to jeffrey> produce a device-dependent .dvi file, No, the device file would still be device independent -- the contents would be tailored for a specific device. Notice that DVI files are already now tailored for a specific device (device dependent in your sense) in two ways: the first is that each DVI file is for a device with a specific set of fonts, and the second is that it is for a device with 1/65k resolution. If your actual output device does not have that set of fonts or that resolution the DVI driver has to make some mapping. To assist in the mapping betwen the idealized device presumed by current DVI files and the actual one is the reason why virtual fonts exist and a standard rounding algorithm is being defined. There is another alternative, and it is to produce a DVI file that is tailored not for an idealized device but for an actual device, so that no mapping is required for that actual device. Since the DVI output would still be device independent in format, one could take the DVI file tailored for a specific device and map it onto another device, and this would be more or less successful depending on how similar the devices were. The problem with the 1/65K resolution, CM fonts based idealized device for which DVI files are currently tailored is that it is hard to map onto lower resolution actual devices, especially those that have fixed pitch characters and motions, like a CRT or a line printer. jeffrey> The problem is that TeX is designed for producing books on jeffrey> 1270dpi and up printers, and it's output is rather compromised jeffrey> for anything else. TeX views laser printers as proofing jeffrey> devices, and doesn't take much effort about precise spacing at jeffrey> low resolutions. This is the *goal*, but the actual TeX mechanism is far more general. The virtual device for which by default TeX output is currently tailored does indeed map most easily onto a high resolution typesetter, but I think that it is possible to describe to TeX different output devices. Note that all this is already true with ditroff, where you have a something (DESC) like a TFM that gives you the parameters of the intended output device. A ditroff output file is device independent, in that it can be printed on any device, but tailored (optimized) for a specific device. TeX is used as the old C/A/T troff is being used, as currently TeX DVI drivers do what psroff does, mapping a virtual (C/A/Ts are no longer manufactured :->) device onto real ones. The only advantage of the CM based, 1/65k virtual device assumed by TeX is that it is richer than the old C/A/T one. jeffrey> If you want device dependent .dvi files though, it's not that hard to jeffrey> get them by a metafont hack that produces letter-widths and kerns at jeffrey> multiples of the device pixel width (see how the gray font works for jeffrey> details). Inter-word spacing would still be at arbitrary precision, jeffrey> but inter-word jumps aren't nearly as noticable as inter-letter jumps, jeffrey> as long as you're printing on a variable-pitch printer. I am not a TeXnician, but I think this is not true. You can do fixed pitch printing with TeX, both as to fixed width letters and interword and interline spacing, e.g. for code listings. I reckon that it is time for TeX to realize its potential as a ditroff, not as a troff tied to one specific virtual output device to be mapped more or less neatly onto actual devices. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
ken@csis.dit.csiro.au (Ken Yap) (12/28/90)
In article <PCG.90Dec25224617@teachk.cs.aber.ac.uk>: ||No, the device file would still be device independent -- the contents ||would be tailored for a specific device. Notice that DVI files are ||already now tailored for a specific device (device dependent in your ||sense) in two ways: the first is that each DVI file is for a device with ||a specific set of fonts, and the second is that it is for a device with ||1/65k resolution. If your actual output device does not have that set of ||fonts or that resolution the DVI driver has to make some mapping. This is correct as far as it goes, but slightly misleading. See last paragraph. ||To assist in the mapping betwen the idealized device presumed by current ||DVI files and the actual one is the reason why virtual fonts exist and a ||standard rounding algorithm is being defined. There is a slight historical distortion here. Virtual fonts came onto the scene only recently although Knuth has bemoaned that nobody had implemented this neat and general solution sooner. Before then, people were using installation specific methods to drive phototypesetters and what have you. The standard rounding algorithm, also known as the max_drift rule, is indeed the compromise that the driver makes to adapt to the real device. ||There is another alternative, and it is to produce a DVI file that is ||tailored not for an idealized device but for an actual device, so that ||no mapping is required for that actual device. Since the DVI output ||would still be device independent in format, one could take the DVI file ||tailored for a specific device and map it onto another device, and this ||would be more or less successful depending on how similar the devices ||were. || ||The problem with the 1/65K resolution, CM fonts based idealized device ||for which DVI files are currently tailored is that it is hard to map ||onto lower resolution actual devices, especially those that have fixed ||pitch characters and motions, like a CRT or a line printer. This is true, but no changes need be made to the innards of TeX. All you have to do is force TeX, via fonts and macros, to calculate in multiple of fixed pitch spacing. The other work that needs to be done is to map characters to the closest printable representation, in the same way that nroff overstrikes o and + for a bullet. Virtual fonts can help here. Dvidoc is a start but needs a lot more work. ||This is the *goal*, but the actual TeX mechanism is far more general. ||The virtual device for which by default TeX output is currently tailored ||does indeed map most easily onto a high resolution typesetter, but I ||think that it is possible to describe to TeX different output devices. || ||Note that all this is already true with ditroff, where you have a ||something (DESC) like a TFM that gives you the parameters of the ||intended output device. A ditroff output file is device independent, in ||that it can be printed on any device, but tailored (optimized) for a ||specific device. || ||TeX is used as the old C/A/T troff is being used, as currently TeX DVI ||drivers do what psroff does, mapping a virtual (C/A/Ts are no longer ||manufactured :->) device onto real ones. The only advantage of the CM ||based, 1/65k virtual device assumed by TeX is that it is richer than the ||old C/A/T one. || ||I am not a TeXnician, but I think this is not true. You can do fixed ||pitch printing with TeX, both as to fixed width letters and interword ||and interline spacing, e.g. for code listings. I reckon that it is time ||for TeX to realize its potential as a ditroff, not as a troff tied to ||one specific virtual output device to be mapped more or less neatly onto ||actual devices. But here's the gist of my argument: Piercarlo argues about the 1/65k pt resolution of TeX's ideal device as if it were a limitation. In fact since no actual device exists with this resolution, it is misleading to say that TeX is tailored to "one specific virtual output device". In fact, no such device is likely to be made: near beginning of the TeXbook we read that 1/65k pt is a length comparable to the wavelength of light. In summary: 1. I do not see that rounding from scaled points to real device resolution is any sort of limitation so I don't see that we have to follow the ditroff path, and 2. Quantizing TeX's spacings requires only some work with fonts and macros. Character substitution should use virtual fonts of course.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/31/90)
On 28 Dec 90 00:33:06 GMT, ken@csis.dit.csiro.au (Ken Yap) said: ken> In article <PCG.90Dec25224617@teachk.cs.aber.ac.uk>: pcg> The virtual device for which by default TeX output is currently pcg> tailored does indeed map most easily onto a high resolution pcg> typesetter, but I think that it is possible to describe to TeX pcg> different output devices. [ ... ] You can do fixed pitch printing pcg> with TeX, both as to fixed width letters and interword and pcg> interline spacing, e.g. for code listings. I reckon that it is time pcg> for TeX to realize its potential as a ditroff, not as a troff tied pcg> to one specific virtual output device to be mapped more or less pcg> neatly onto actual devices. ken> In summary: 1. I do not see that rounding from scaled points to real ken> device resolution is any sort of limitation so I don't see that we have ken> to follow the ditroff path, and 2. Quantizing TeX's spacings requires ken> only some work with fonts and macros. Character substitution should ken> use virtual fonts of course. I think that we have written exactly the same thing here. Haven't we? ken> But here's the gist of my argument: Piercarlo argues about the ken> 1/65k pt resolution of TeX's ideal device as if it were a ken> limitation. Well, it virtually ensures that quantizing will be approximate, even if by very little. 1/65k of a point is an exceedingly fine resolution, and even if the real device resolution is not (as it is *very* rarely) a factor of 1/65k, the resulting error is usually negligible. Ditroff though avoids even this negligible source of errors by being parametric with respect to the actual hirzontal and vertical resolutions of the intended output device, and ensuring that all motions and sizes are in fact even multiples of these resolutions, and by declaring in its output for which resolutions all motions and sizes are meant. ken> In fact since no actual device exists with this resolution, it is ken> misleading to say that TeX is tailored to "one specific virtual ken> output device" A nit: this is is not misleading, it is entirely accurate. The one specific virtual output device is the one for which DVI files are encoded currently; historically, as I remarked (and you repeated), DVU files were tailored not just for 1/65k resolution, but also for the CM font layout (dependent on obscure Stanford conventions), and both the resolution and the font layout had to be mapped onto those for the real device. The recent introduction of virtual fonts has been motivated precisely by the desire to alleviate the font layout mapping problem, to accomodate non CM fonts more easily. Fortunately TeX can be taught about different fonts and to calculate its output so that coordinates are quantized to look good on other, real, devices, thus making it unnecessary to have DVI rounding standards (except if you are, as yopu should not, printing to a real device different from the one for which the DVI file was optimized). ken> In fact, no such device is likely to be made: near beginning of the ken> TeXbook we read that 1/65k pt is a length comparable to the ken> wavelength of light. What about using TeX to drive electron beam chip etching devices? What about a Conway&Mead set of TeX macros? Can silicon TeX compilation be that far off? :-) :-) :-) -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
ath@prosys.se (Anders Thulin) (01/01/91)
In article <PCG.90Dec31155754@teachk.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: [ ... discussion of TeX/DVI resolution deleted ... ] >What about using TeX to drive electron beam chip etching devices? What >about a Conway&Mead set of TeX macros? Can silicon TeX compilation be >that far off? > >:-) :-) :-) Thinking of providing the Bible on a chip? :-) -- Anders Thulin ath@prosys.se {uunet,mcsun}!sunic!prosys!ath Telesoft Europe AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
ken@csis.dit.csiro.au (Ken Yap) (01/02/91)
In article <PCG.90Dec31155754@teachk.cs.aber.ac.uk>: >Well, it virtually ensures that quantizing will be approximate, even if >by very little. 1/65k of a point is an exceedingly fine resolution, and >even if the real device resolution is not (as it is *very* rarely) a >factor of 1/65k, the resulting error is usually negligible. > >Ditroff though avoids even this negligible source of errors by being >parametric with respect to the actual hirzontal and vertical resolutions >of the intended output device, and ensuring that all motions and sizes >are in fact even multiples of these resolutions, and by declaring in its >output for which resolutions all motions and sizes are meant. Perhaps, but ditroff format (at least the one I worked with) has its limitations too. When I wrote the ditdvi converter I rediscovered that widths have to under 256 because they are stored as one byte in the fontdesc file. This means that everything has to be scaled so that the widest character is under 256 units. This is another source of quantization error when adapting to real-world devices. In practice I have found TeX's spacing and placement decisions to be superior to *roff's. So I'm biased. :-) Again, the real point is that there is no technical hindrance to using TeX for man pages. Somebody just has to put in the work in macros and backends.
clewis@ecicrl.UUCP (Chris Lewis) (01/03/91)
In article <1991Jan2.000547.15295@csis.dit.csiro.au> ken@csis.dit.csiro.au (Ken Yap) writes: >In article <PCG.90Dec31155754@teachk.cs.aber.ac.uk>: >>Ditroff though avoids even this negligible source of errors by being >>parametric with respect to the actual hirzontal and vertical resolutions >>of the intended output device, and ensuring that all motions and sizes >>are in fact even multiples of these resolutions, and by declaring in its >>output for which resolutions all motions and sizes are meant. >Perhaps, but ditroff format (at least the one I worked with) has its >limitations too. When I wrote the ditdvi converter I rediscovered that >widths have to under 256 because they are stored as one byte in the >fontdesc file. This means that everything has to be scaled so that the >widest character is under 256 units. This is another source of >quantization error when adapting to real-world devices. True, but a trifle misleading. Normally, the width entries in the width tables is the width of the character in the printer's resolution at a given size. Eg: width of character in 1/300's at 10 point. Given that the printer is probably going to insist on integral pixel widths anyways (and integral pixel glyphs for certain), you won't get much in the way of quantization errors. ditroff is usually running in the same resolution as the device, and since the widths are in that same resolution, characters start on pixel boundaries and things usually look pretty good. In contrast, severe braindamage can result if you scale bitmap fonts to sizes other than what they were designed for. Only on high resolution devices (>= 2000 DPI perhaps) is the 255 limit likely to be a problem. >In practice I have found TeX's spacing and placement decisions to be >superior to *roff's. So I'm biased. :-) Which is certainly true. Another niceish thing is that TeX doesn't automatically assume that a 12 point font is twice the width of a 6 point one. This means that you can deal with fonts that don't scale linearly (eg: you've collected a font at it's various sizes and there's roundoff error). Still, troff does do a quite reasonable job. >Again, the real point is that there is no technical hindrance to using >TeX for man pages. Somebody just has to put in the work in macros and >backends. No real technical hindrance, just disk space, CPU cycles, compatibility and learning curve. -- Chris Lewis, Phone: (613) 832-0541 UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)