[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Groff] Device-independence of intermediate output
From: |
Ted Harding |
Subject: |
RE: [Groff] Device-independence of intermediate output |
Date: |
Thu, 31 Jan 2002 09:11:57 -0000 (GMT) |
On 31-Jan-02 Bernd Warken wrote:
> The "Troff User's Manual" [CSTR #54, ch. 22] reads:
>
> Troff produces its output in a language that is independent of any
> specific output device, except that the numbers in it have been
> computed on the basis of the resolution of the device, and the
> sizes, fonts, and characters that that cevice can print.
> Nevertheless it is quite possible to interpret that output on a
> different device, within the latter's capabilities.
>
> The groff intermediate output language does not support this feature -
> although it is a base feature of device independent troff, on which
> groff was originally built.
I don't think I understand what Bernd is saying here.
groff intermediate output is not essentially different
from the original ditroff output: it just has some extensions.
Granted, the quote from CSTR #54 might suggest the opposite
to someone who knows groff, since there are device-specific
elements such as the "\X'...'" request which comes out
as x X ... for passing "device control" commands directly
to the device (or, more precisely, to the device driver
which can choose to pass them straight through or otherwise
process them); but these occur in the original ditroff
intermediate output as well, so nothing is new here.
Ditroff was always conceived in terms of device-specific
post-processors ("device drivers"). See CSTR #97,
"A Typesetter-independent TROFF". Intermediate output
for, say, PS could always be used to drive, say, TTY if
the TTY driver was written to be able to recognise "x T ps""
and then ignore anything relevant only to PS, and rescale
any movements and dimensions accordingly; and I believe
that this is what the above quote from CSTR #54 really
means.
So I'm wondering what Bernd means when he says that the
"groff intermediate output language does not support this
feature"
It would not be the first time that the original Sacred Texts
have been found to be not quite comprehensive.
> Fortunately, it seems to be easy to implement this feature by
> providing a scaling factor to the arguments of some arguments.
>
> This feature is quite powerful; it will be possible to run code
> written for the ancient troff devices on any modern groff device.
>
> Is there agreement on the necessity of this feature?
There already is an element in the groff/troff output
language which allows this:
x r n h v
resolution is n/inch, h = min hor motion, v = min vert motion
So, while what Bernd seems to be suggesting could be useful, as I
indicate above I think the place for it, if anywhere, is in the
drivers. The driver should already know the resolutions for
the device it is driving, and can use the "x r n h v" to
compute its own scalings if given troff output computed for
a different device.
Best wishes to all,
Ted.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 31-Jan-02 Time: 09:11:57
------------------------------ XFMail ------------------------------