[comp.text.tex] Using TeX for the UNIX man pages

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.uk

em@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.

ken@csis.dit.csiro.au (Ken Yap) (01/02/91)

The other point which is relevant only to TeXies:

In article <PCG.90Dec31155754@teachk.cs.aber.ac.uk>:
>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.

We should distinguish between TeX the program and plain TeX here. When
most people talk about TeX, they mean the plain format. TeX the program
knows nothing about font layouts. Neither do DVI files encode any
knowledge about Stanford keyboards. They just contain codes saying
things like set character NN from font XX. If someone wishes to design
a new format using non-CM fonts with characters in different positions,
that's no problem and will not upset any trip validation tests. In fact
this has been done with some approaches to using PS fonts.  So there is
no font layout mapping problem with TeX, only a problem if one wishes
to retain plain's layout. This is also why it is always a bad idea to
embed \charXX calls in user copy. Do this in macros if you must.

I could sure use a cmtt with standard ASCII mapping. Ok, ok, cmtt's
with ISO8859 mappings.

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)