groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Devps unmatched metrics


From: Tadziu Hoffmann
Subject: Re: [Groff] Devps unmatched metrics
Date: Thu, 1 May 2008 18:12:11 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

> [...]; and, OTOH, hack them.

Well, yes, but I'm not actually hacking the fonts (maybe one
of these days...), at least not in the particular example I
was describing.  Let me explain:

We have to distinguish between two types of metric information
because they are fundamentally and qualitatively different:
(a) character widths and (b) kerning.  For groff, the former
type is purely informative -- it tells groff what the device
actually does (by itself) [*] --, whereas the latter specifies
actions that have to be explicitly requested of the device.
Since positioning the point after drawing a string is done by
the device, the character widths in the font description files
*have* to be those of the font actually used by the device,
otherwise groff's view of the page will be different from
the device's view. [**]

The kerning information, however, can be modified without
a new font being created, because it is something the font
doesn't "know" about.  [Don't know what the situation is with
OpenType.]  It is something that groff specifically has to tell
the device to do, and with the kerning information in groff's
font description file we tell groff how we want this done.
("In this particular font, I want groff to put so-and-so much
extra space between characters x and y.")

[*] In Postscript-speak, this is because we're using the
"show" operator to display the text, so groff's idea about
where the "currentpoint" is has to exactly correspond to where
the device actually puts it.  In other words, the character
width information in groff's font description file must be
identical to the character widths of the Postscript font used.
(If we were to place each character individually without
using "show" on an entire string, then we could also have
the character widths be a "want" item instead of an "is" item.)

[**] This is exactly the point Denis was making.  I only took
exception to his proposed solution because he was not actually
using Times, and I thought it unwise to fudge the metrics
of "Times-Roman" to match those of "NimbusRomNo9L-Regu".
I'm not at all opposed to using other fonts with groff --
I do this all the time, and hardly ever use the default
"builtin" fonts -- but I think we should refer to fonts
by the same names as the device does.

Groff runs out of the box on a multitude of different machines
and operating systems without requiring the font files at all
(only the metrics), and groff does not need ghostscript to work.
(Of course we all use ghostscript, but it's still optional.)
I prefer the default installation of groff to remain that way.

Furthermore, groff as distributed has no way of knowing where
your fonts are and which of those you want to use with groff,
so building metrics files from the local fonts is more of a job
for yourself or your Linux distro than for the groff package.
My vote therefore is: (1) make it easy for users to use other
fonts with groff by perhaps providing a font installation
script, (2) educate users about how fonts selection works in
groff, and (3) leave the default groff installation as it is.


> For example, if I type a business letter [we all use groff for
> our business letters, don't we?] I really don't care if groff
> sets it in Adobe's version of Times, gv renders it in URW, and
> my laser printer prints it in Who-Knows-What.
> 
> However, if I play around with micro-typography, for example,
> using the "Up a bit, Down a bit" manipulations of the s and H
> registers, then I really do want a **particular version** of
> Times to be used in all three applications. This, I think I
> can achieve by copying and renaming the "standard" fonts and
> then calling the renamed fonts, which should force the exact
> font I call to be embedded into the postscript output.

Exactly.  The cool thing with Postscript is that you don't even
necessarily have to change the name of the font as long as it's
included in the file sent to the device, because the embedded
font will "shadow" the builtin version of the same name.
(E.g., "Courier" version 3.0 .ne. "Courier" version 4.0 --
who knows which version is the one the device has built in?
That's why Adobe now recommends that even the standard fonts
be embedded in PDFs.)

(In a way, this can be construed as being contradictory to [**]
above, since if I can call any font "Times-Roman", then why not
"NimbusRomNo9L-Regu"?  Well, sure you can, but groff shouldn't
be tied to ghostscript, so if you want to do this it's more the
ghostscipt package's business than groff's.)

(Incidentally, this also means that ghostscript does not have
to use the URW fonts.  It can instead use the Adobe fonts from
the Acrobat reader installation.)


> BTW, Ted Harding whose post to this mailing list introduced me
> to "The \s'-360u'\H'+360u'quick\H'0\s0 brown fox" should be
> taken out and publicly flogged. Ted, do you realise how much
> time you have cost me with that little gem?

What is the significance of the number 360?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]