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

J"org objections


J"org Knappen's objections to atomic fonts


 >       I just want to point out, that atomicness could be
 > as well achieved via _real_ fonts. Such a scheme is
 > halfway implemented in the fc fonts, where the upper 128
 > characters are generated only on demand, i.e. if their
 > code is known to METAFONT. Another example are Tom
 > Ridgeway's wnri fonts.

      Might I paraphrase the first sentence as:

<< The notion of *atomic* characters can be exploited within a
metafont setup for efficiently generating several font series of
the cm typeface like the dc fonts (Cork=T1 encoded, author N.
Schwartz) or the fc (african) fonts of J"org Knappen, not to
mention the original cm series. >>

     Incidentally this does not require any encoding
whatever for the atomic glyphs; rather it would be a 
substitiute for it.

     Atomism is an ancient notion that has myriad uses.  Does
J"org's use have anything to do with the uses I had in mind
for an atomic latin glyph encoding, namely:
    (i) a general and portable standard .dvi format for
scientific articles.   (Knuth's CM face is the one typeface
for which this could and should be realized immediately.)
    (ii) a "raw" encoding standard for vf's.

     Well, J"org's idea certainly has little to do with (ii)
except that if metafont and Postscipt Type 1 together kill
Knuth's virtual fonts, then (ii) becomes irrelevant.  I feel it
would be folly to neglect any one of these three techniques.

      Does J"org's idea achieve aim (i)?

      A first step is OK (as envisaged by J"org)

 --- for the CM face of Knuth (for a start) create a 
metafont generation setup that generates many font
encoding classes: AT1 (atomic), DC=T1, FC=T?, etc. 
And "etc" should be a discipline for indefinite extension.

This seems both feasible and desirable. I certainly
would be happy to see it come about.

  But what of J"org's contention that if we neglect atomic
.dvi's and the corresponding use of dvicopy to to reduce
Tn encodings to the atomic encoding, then aim (i) 
can still be achieved as follows??

 > One only has to store the different tfm files and use a
 > dvi driver which generates the needed pk files on the
 > fly. No tools like dvicopy (has someone ported it to
 > VMS ?) or virtual fonts are necessary.

     This works --- as Rokicki's dvips system proves.  

     But it works only under the best-equipped TeX
implementations; chiefly those with the full dvips with metafont
and "automagic".  Workstations give the best results here
--- but even here I note that, of the generous handful of
sun stations I visit, only one has well-working
"automagic". Rather elitist I would say.

     Note that an atomic .dvi can be previewed and printed
at "minimal" TeX sites *without metafont*. Further the
recipient of an atomic .dvi does *not* need dvicopy.
Hopefully only the archive administrator (or the author)
needs access to dvicopy so it is not tragic if dvicopy is
still unavailable under VMS. The author is *not* required to
use virtual fonts; instead he can use pk fonts or Postscript
type one fonts --- provided he uses some standard Tn
encoded metrics for CM face fonts that the archive is able
to "atomize" using dvicopy or equivalent.

     With J"orgs approach, slowness has to be traded off
against file numbers and bulk. There is a tendency to
require more and more resolutions: at least two for
previewing, and more at sites with screens of various
resolutions.  Several even for one Laserprinter of the
current generation printing at 300, 400 and 600 dpi. I have
lived through this and find it most tiresome.  Atomic fonts
would keep the problem down to the known and relatively
moderate proportions it has for Knuth's original CM fonts.

     J"org implies, wrongly I believe, that the "atomic encoding" 
would be non-extendable.
    
 > Also, the number of `atoms' can be easily increased
 > [with an all-metafont approach], there is
 > no need to meet just another 256 restriction.
 > Think of expert ligatures, medium caps, oldstyle digits, 
 > swash letters.

I claim that an atomic character encoding scheme is extendible.
Indeed, if the atomic 256 character encoding AT1 is ever filled
(let's not hurry!) one can just go on and start AT2, AT3, ...
There is in principle no problem whatever in using these along
with AT1, and there is no limit.

     This indefinite expansibility raises the question whether
standardized atomic glyph encodings might be of use for other
alphabet families such as arabic, sanscrit etc. Perhaps virtual
encodings could be created on-the-fly...; they never need appear
in an exported .dvi file.

     (There are incomparably greater problems in exploiting more
than one of the currently envisaged text series T1, T2, ... in the
same manuscript: lack of kerning and ligature abilities between
fonts; futile duplications of hyphenation tables and characters,
heavy switching macros; LaTeX fragility.)

     To be realistic however, I add that I did not propose an
"atomic encoding" standard as a panacea. TeX itself is no panacea;
it earns respect for specialized things it does outstandingly
well. I would be quite content if the atomic encoding helped to
let Knuth's CM face support a convenient and reasonably general
form of public domain electronic paper.

     Laurent Siebenmann