⟦18b04275e⟧

TextFile

\chapter{To Do List}
% ==================
\begin{enumerate}
	\item Documentation:
		\begin{enumerate}
			\item Makefile needs to be fixed up  in the {\tt doc} and may
				be still in the {\tt man} directory.
			\item Check spelling.
			\item There is a problem with the search path for fonts which
				must include ".". This should be specified somewhere or
				worked around at least.
			\item Add documentation about {\tt pltotf}.
			\item The {\tt logo10.tfm} font may not be available everywhere.
			\item May be I should think about the installation of various
				{\tt afm} files in various directories (from the {\tt afm}
				directory).
		\end{enumerate}
	\item Driver:
		\begin{enumerate}
			\item {\tt sig.c} stuff (there is the problem with the signal
				type.)
			\item Rules, there is still a problem.
		\end{enumerate}
	\item Makefiles:
		\begin{enumerate}
			\item Declaration for signal in SunOS 4.0, SysV and probably POSIX
				is \verb+void (*)()+. Should be made an \verb+#ifdef. [sig.c]+.
			\item Make Makefiles use CC and CFLAGS and to pass them down to inferior
				makes so that gcc can be easily substituted for cc. Also easy to
				change C options globally by editing the top Makefile.
			\item Makefile for the documentation directory is still messed
				up.
			\item {\tt psrev} should be removed and {\tt dviselect} should
				be inserted instead.
		\end{enumerate}
	\item X windows. Upgrade to X11.4 should be made sometime.
	\item Pierre MacKay Email:
		And lastly, how do you get the ps-root files in ./doc/SliTeX past psrev.
		Are there several versions of psrev out there?  Should I be leaning on
		our people to get a better version of TranScript.  All I can get to is
		psrev's absolute refusal to process anything with a "non-conforming trailer"
		I made the psrev part of the makefile elective with the - flag, but that
		produced some very strange \TeX{} and PS errors.  (Come to thing of it, why
		should it have affected \TeX{} at all?)
	\item Make it a non-fatal error when a duplicate is found in the afm
		file character names.
	\item What if quote-left is missing, this seems to generate a fatal
		error. Why?
	\item Now a question: Is there any way of including the slitex part of the
		manual without psrev?
\end{enumerate}

\btex
Return-Path: <purdue!@VM.CC.PURDUE.EDU:DRIV-L@TAMVM1.BITNET>
Date:         Mon, 19 Jun 89 13:30:22 CDT
Reply-To: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
Sender: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
From: "Thomas J. Reid" <purdue!TAMVM1!X066TR>
Subject:      Max drift correction (revisited)
To: Stephan von Bechtolsheim <purdue!svb>

Last April, there was much discussion of improving the way that a driver
should handle positioning characters when the device width in pixels
differs from the rounded TFM widths.  Since that discussion, there have
been many more people sign up to this list, so I would like to briefly
review the matter:

   * DVItype spaces characters using their declared (in the GF or PK file)
     device width in pixels.  It also uses the concept of "max drift" to
     limit how far a character can drift from where the DVI file says it
     should be.  If the actual position differs by more than 2 pixels, it
     is set to be 2 pixels away from where the DVI file says it should
     fall.  Position corrections are done between words and lines.

   * Joachim Schrod and Klaus Guntermann showed that a constant value of
     2 for max drift is not always satisfactory and that a value of
     roughly 0.01in rounded to pixels should be used instead.  Also, they
     showed that the limits that DVItype uses to determine when to do a
     position correction were not quite right.  The limits that they
     suggest are:  dh >= 0.2quad, dh <= -0.9quad, and  abs(dv) >= 0.8quad
     where dh and dv give the amount of horizontal or vertical motion and
     quad is determined by the scaled design size of the current font.

   * Nelson Beebe reported on a problem which he had seen with typewriter
     output in that the rightmost column of text like

     *******************************************************
     *                                                     *
     *******************************************************

     would not align between the first and second lines.  Nelson's solution
     is to have a command line flag which allows the user to set the max
     drift limit to zero which effectively disables character drifting.

Details on these discussions can be found in the April (8904) log files
of DRIV-L.

End of review

I have implemented a method which automates Nelson's idea.  The approach
is to make max drift depend upon the font and use a value of 0.01in for
proportional fonts while using zero for mono-spaced fonts.  I do this by
examining the character widths when the font is first processed:  If all
the characters have the same width, max drift is set to zero; else it is
set to 3 pixels (for a 300 dpi device).

This technique offers two advantages:  It allows the drift correction to
continue to be used for proportional fonts; and it is automatic.

---Tom Reid

\etex

\btex
Return-Path: <purdue!@VM.CC.PURDUE.EDU:DRIV-L@TAMVM1.BITNET>
Date:         Wed, 28 Jun 89 09:52:11 CDT
Reply-To: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
Sender: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
From: Don Hosek <purdue!UICVM.UIC.EDU!U33297>
Subject:      Re: Max drift correction (revisited)
To: Stephan von Bechtolsheim <purdue!svb>
In-Reply-To:  Message of Tue,
              27 Jun 89 18:45:42 EST from <integin!svb@CS.PURDUE.EDU>

On Tue, 27 Jun 89 18:45:42 EST Stephan Bechtolsheim said:
>We never settled the question whether TFM files should
>be accessed by the driver or not (to get necessart maxdrift
>information). If we decide the answer is no then we could
>include the necessary information through \specials.

As I recall, the decision was that drivers _could_ read TFM files, but were
not required to do so. One disadvantage to the ▶1b◀special approach is that
we would need to supply needed information for EACH font used in the job (and
we would probably end up sending information for fonts NOT used in the job).

Our final decision was that for certain values that might be needed, if the
driver was not reading TFM's, it would estimate them from the design size
(e.g., a space is approximately 1/3 the design size).

-dh

    -------------------+-----------------------------------------------
    Don Hosek          | Internet: U33297@UICVM.UIC.EDU
    3916 Elmwood       | Bitnet: U33297@UICVM.BITNET
    Stickney, IL 60402 |         DHOSEK@YMIR.BITNET
    Work: 312-996-2981 | UUNet: dhosek@jarthur.claremont.edu
    ERASE * SCRIPT *   | JANET: U33297%UICVM.UIC.EDU@UK.AC.EARN-RELAY
    -------------------+-----------------------------------------------
                      Never give a gun to ducks

\etex
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦18b04275e⟧ TextFile

Derivation

TextFile
