=========================================================================
Date: Thu, 3 May 90 16:49:00 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: "Heiko as UK85@DKAUNI2.BITNET" <UK85@DKAUNI2.BITNET>
Subject: DVI-Driver for CANON LBP-8II(I) PRINTER - Where ?
Hi,
I'm writing the first time to this list, so I don't know if this
has still occured :
I'm searching for the C-Source code for a .DVI-Driver for a
CANON LBP4 or LBP8II or LBP8III-laser beam printer which I could
compile on a IBM-Clone and perhaps also compile for some other
computers.
Does anybody know where I can get this driver from and HOW ?
Please send the answer directly to me as I'm not always subscribed
to any list
-Heiko
UK85 @ DKAUNI2.BITNET
=========================================================================
Date: Tue, 8 May 90 15:13:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: That level 0 DVI driver standard
Later tonight I'll be typing up a complete draft of the thing.
Since I've been foot-dragging a bit on the administrative side,
the voting on this particular issue will be those people who were
on the original list that Robert McGaffey drew up and are still
around and e-mail accessible. I'll be contacting each of you by
mail until I have your votes. Further details will be included
later.
The standard for level 0 will be only a draft so that we have
something to present at Texas A&M next month (eek).
I'll also put together a simple graphics inclusion standard for
our consideration as well.
-dh
=========================================================================
Date: Tue, 8 May 90 15:05:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: Re: driver comments
I received the following in my mail today; the message below is
complete with my comments interspersed (the lines of the original
message are all preceded with >'s)
>Date: Tue, 8 May 90 09:15:59 CDT
>From: rick%geovx3@hub.SINet.SLB.COM
>Subject: driver comments
>To: dhosek@HMCVAX.CLAREMONT.EDU
>I'm not sure if the driver group ever came up with a recommended driver
>directory structure so I would like to express the things I would like
>to see as a installer and support person.
>First, the .tfm files are in [tex.fonts] and the .pk, .pxl or whatever
>aren't. Some current drivers seem to expect to find everything in one
>directory. This might be ok for a site with only 1 type of output device
>but most of my sites have at least 2 different output devices. TFM files
>are the same for standard fonts and therefore should be in the standard
>TeX directory. The pixel files are unique for different devices and
>belong in a separate clearly defined directory.
>The pointer to the pixel directory (and any other required directories
>for the driver) should not be hard coded in the driver but located by
>a logical assignment of some support. I realize that some operating
>systems don't support this (perhaps they could read a standard file
>in the directory containing the executable or some such), but those
>that do should take advantage of this feature. This would allow
>installers to place pixel files on different disks, share pixel files
>between printers with similar print engines, or use common pixel files
>for screen previewers. You might think this is already done by everone
>but I have a driver for a laser printer where the directory is hard
>coded in the Web file with no documentation on where or how to change
>it. Not everone has the compilers or knowledge of how to make the
>necessary changes to move the directory.
In the driver group's discussions, the consensus was that drivers
should read an external file which had information in it
concerning the location and structure of TFMs, PKs, and GF files
as necessary. This file would allow system managers to configure
whether rasters had their magnification encoded in their
directories or in their extensions, etc.
>I would like to see the various magnifactions of the pixel files in
>separate subdirectories. Some drivers currently place all the pixel
>files in one subdirectory with differences in file extensions to
>separate the various magnifications. I think it is better to place
>different magnifications in there own subdirectory for two reasons.
>First, some operating systems only allow 3 characters for file
>extentions. It is probably better to allow magnifications to be
>4 digits in length (i.e. 1000 times the magnification). The Second
>reason is that I think like in structured programming where a subroutine
>should be much more than a page, I believe it should also apply to
>directories. As I normally keep around a hundred pixel files on my
>system for each driver, I prefer not to have them all in one directory.
The consensus of the group was that it would be better to leave
this decision up to the local manager. I personally prefer the
flat structure where possible. In particular, this allows me to
more conveniently segregate fonts like the old AMS fonts or KST
fonts which are available only as rasters.
>Another thing I would like to see is that the formula for calculating
>the magnification be explicitly stated in the document. The reason
>for this is because of some drivers were originally written several
>years ago when only 200 dpi fonts were available from Stanford. This
>200 dpi font resolution was hard coded in dvitype and copied into
>several drivers. Some of these drivers are still around with the 200
>still hard coded. Now that metafont is widely available, most people
>have fonts available at their printers resolution. I still have a
>driver at my site that has the 200 hard coded. Since the printer is
>300 dpi it looks in the 1500 directory (300/200) for its unmagnified
>fonts. I called and tried to explain that the 200 should not be hard
>coded to the author but he insisted that I was wrong, the 200 was in
>dvitype and that was the standard. He had generated fonts at 300 dpi
>for the printer but would store the fonts beginning in the 1500 directory.
>I believe the unmagnified fonts should be in the 1000 directory if the
>fonts where generated at the same resolution as the device.
>As I gave up on him, I haven't looked recently to see if dvitype still
>has the 200 hard coded or has changed it to a parameter like FONT_RESOLUTION
>which reflects the resolution that the fonts where actually generated at.
>Therefore, I would like to see the equation formally listed in the document,
>since most driver documentation doesn't explain how the driver finds the
>fonts. It might also be the place to put a recommended rounding
>function to handle that problem.
Well, actually, he was right. There are two different sets of
numbers used with TeX fonts to indicate their magnification and
resolution. The PKs and GFs use resolution*magnification
(magnification=1 is normal-sized) to determine this number. Thus
cmr10.300pk is cmr10 at 10pt for a 300dpi device etc. PXL files
use resolution*magnification*5 for the historical reasons that
you've noted. However, since resolution is still part of the
coding, a font at TeX's magnification 1200 for a 300 device will
end up in the 1800 directory (1.2*300*5=1800). The PK/GF
convention is built into and described MF; the PXL convention is
described in PXtoPK and PKtoPX.
However, part of the level 0 standard being constructed is the
requirement that drivers be able to handle fonts with up to 256
characters in them; PXL files have hard-coded into their format a
limitation of 128 characters, thus PXL files will finally be a
thing of the past (which is OK since on the average a PK file
runs around a third the size of a PXL file).
>Since most of this assumes a tree structured directory system I believe
>we should also solicit input from the people who have flat file systems
>and have a recommended flat file layout also.
>Rick Caldwell
-dh
=========================================================================
Date: Tue, 8 May 90 16:57:23 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Pierre MacKay <mackay@CS.WASHINGTON.EDU>
Subject: delayed answers to mail
I am temporarily unable to answer your messages in a timely manner.
If you are interested in getting TeX 3.0 in a normal distribution,
please send your request to
elisabet@max.acs.washington.edu
If you have technical questions about the distribution, or about
compilation etc., forward your message to the same address, and
Elisabeth will relay them to me.
I must ask you please not to overwhelm Elisabeth with messages.
My mail has been averaging 150 messages a week, which is one of the
reasons I must take this slightly drastic step.
Email: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computer Support Center TUG Site Coordinator for
Lewis Hall 35F, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
=========================================================================
Date: Wed, 9 May 90 10:03:04 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Bart Childs <BART@CS.BITNET>
Subject: Driver Comments
The message from Rick Caldwell with notes from Don Hosek just
reached my desk. I offer my agreements and DISAGREEMENTs.
The tfm files should in in a directory that contains nothing
else except for a status file, _READ_ME_ or whatever.
Pixel files certainly should not be there because we are
just beginning to see some really different marking technologies.
There has been plenty reported in TUGboat and the lists about
needing slightly different pixel maps for different versions
of the same engine.
Drivers should not have a hardcoded search path for pixel files.
The second best choice that is the one that should be the
default implementation is to read a local or global file
that gives a search path for resolution. The omission from
the previous note is that it SHOULD start with the local
directory and the user should always be able to ``roll his own.''
The reason for allowing the local directory, is that the
user should be able to test a new font without system privileges
of placing font files in the ``system directory.''
The best way of doing this is to have a real operating system
with a true ``searchlist.'' Then the driver is simplified a
bunch. Searchlist is available on VMS, as a DOS extension,
and AOS. The DOS and unix PATH don't generally work for
data files. The reason it is better is that it makes a far
cleaner driver and it is faster. The system hashes the directories
only once. Don Knuth's note in his WEBs about the lack of
a othercases statement and compiler writers applies in spirit here.
I disagree in the STRONGest possible terms with the concept of
separating the pixel files by magnification. Because my name
and phone number were so easily found when I was TUG president,
I got many phone calls from the uninitiated. One of the most
common ones was why things don't work at a given magnification?
I think that it is also brain damaged to call a directory of
magstephalf fonts DPI329 because it certainly is not 329 dots/inch.
I have previously suggested using 0pk, hpk, 1pk, ..., 9pk for
denoting PacKed files at 0 mag, half, ... Secretaries can
issue a VMS or DOS like command of:
DIR cmr8.*pk
and find which sizes they have. The discomfort is that when
these names are sorted, half does not come between 0 and 1.
Tom Rokicki's drivers will run MF and generate a size if needed.
This is nice, but it should logically affect about 0.1% of the
use of TeX or less. It could be an effective way to minimize
use of disk space and then it would affect a lot more jobs.
The hashing algorithms on most systems give you wonderful
performance with 150 to 500 files in a directory. Spawning
directories all over the place does not make sense to me.
I DISAGREE that this should be left to the local! If TeX
is the same everywhere, then it sure would be nice if training
on the use of TeX could be similar too. Systems with
different directories for different magnifications should
come with a utility to list all magnifications for a given
font.
There is no need for a driver to read more than one format of
pixel files. I have selected the PacKed format because of
economy. A TeX system should always have gftopk, pxtopk, and
whatever else is needed. They are available and this simplifies
the driver and again makes life better.
On the rounding of the resolution, agreed that is a problem.
In my drivers I have taken the following approach. The numbers
like 300, 329, 360, ... are in an array, valid_mags.
I find the closest and give a warning if the number is more
than, say, 2% different. I plan to add, if the pixel file
does not exist, keep going down until you find one.
This is a form of SUBSTITUTION and ALL DRIVERS should always
output the position before outputting a SUBSTITUTED character.
They should also give the user more than one simple message
that a substitution has been made, it should probably indicate
that the user is a candidate for a meal in November. (This
does not apply to Virtual Fonts.)
I agree with the level 0 requirement of accomodating 256 character
fonts. An implementation strategy that has some merit is to
treat any font with more than 128 as two fonts. This requires
an extra if in the set_chr routine (and put_chr). Some printers
will have rather arbitrary limits on the number of characters
that a font can contain. For example, you can't download in
positions 0..31, 128+0..128+31, 127, and 255 in at least one.
Sometimes it is handy to log exactly which characters are used.
If most fonts have not more than 128, then the logging is
more wasteful than it has to be. I am not sure what the
effects of virtual fonts will be here.
I will try to make a complete note soon and submit it on how
I have handled this for the Cray CTSS OS. It has a flat
file system and file names can be as long as you want if
you don't like more than 8 characters in a file name.
They are cAsE sensitive file names ....
=========================================================================
Date: Thu, 10 May 90 19:10:01 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: XITIJSCH@DDATHD21.BITNET
Subject: Re: Driver Comments
A few comments to Bart's reply:
> The tfm files should in in a directory that contains nothing
> else except for a status file, _READ_ME_ or whatever.
> Pixel files certainly should not be there
ok
> Drivers should not have a hardcoded search path for pixel files.
> The second best choice that is the one that should be the
> default implementation is to read a local or global file
> that gives a search path for resolution. The omission from
> the previous note is that it SHOULD start with the local
> directory and the user should always be able to ``roll his own.''
> The reason for allowing the local directory, is that the
> user should be able to test a new font without system privileges
> of placing font files in the ``system directory.''
>
> The best way of doing this is to have a real operating system
> with a true ``searchlist.'' Then the driver is simplified a
> bunch. [...] The system hashes the directories
> only once. Don Knuth's note in his WEBs about the lack of
> a othercases statement and compiler writers applies in spirit here.
Well, but I think it's more usual to be able to alter source of the
compiler (which is just an application) than the source of the
operating system! Therefore this argumentation does not hold for me
-- but anyhow, using the concept of a searchlist is ok. (Everybody
programming under UNIX should have a short library routine available.)
> I disagree in the STRONGest possible terms with the concept of
> separating the pixel files by magnification. Because my name
> and phone number were so easily found when I was TUG president,
> I got many phone calls from the uninitiated. One of the most
> common ones was why things don't work at a given magnification?
> I think that it is also brain damaged to call a directory of
> magstephalf fonts DPI329 because it certainly is not 329 dots/inch.
> I have previously suggested using 0pk, hpk, 1pk, ..., 9pk for
> denoting PacKed files at 0 mag, half, ... [...] The discomfort is that when
> these names are sorted, half does not come between 0 and 1.
But these names do not fit in all circumstances. I have often created
fonts with \mag=7200 (e.g. for posters), what would this be? The above
naming scheme just goes up to magstep 9, that's not enough!!
> The hashing algorithms on most systems give you wonderful
> performance with 150 to 500 files in a directory. Spawning
> directories all over the place does not make sense to me.
> I DISAGREE that this should be left to the local!
I AGREE that this should be left to the local and I AGREE in the
STRONGest possible terms with the concept of separating the pixel
files by magnification. If things don't work at a given magnification
that has nothing to do with directory structures but with missing
fonts! And this case should be handled by the driver and explained in
the documentation (as said below)!
I don't know if you works sometimes under DOS (I am forced to), but
if you must handle a directory of 500 files with this damned
command.com which is not able to use usual wild cards you do not say
any more that someone is able to type the command `DIR cmr8.*pk'. By
the way, not all systems use hashing algorithms good enough to handle
500 files efficient. (By the way, we distribute about 800 fonts with
our drivers -- in my opinion the user gets no overview if he has all
those files in one directory!)
> There is no need for a driver to read more than one format of
> pixel files.
Well, but if it's implemented it's ok. It's nice to use GF files
directly if you are playing with MF!
> On the rounding of the resolution, agreed that is a problem.
> In my drivers I have taken the following approach. The numbers
> like 300, 329, 360, ... are in an array, valid_mags.
What if you have magsteps not within your array (like \mag=7200 or
magstep 10)? I think the closest magstep should be find in the
available fonts (i.e. over a wildcard search!)
> I find the closest and give a warning if the number is more
> than, say, 2% different. I plan to add, if the pixel file
> does not exist, keep going down until you find one.
> This is a form of SUBSTITUTION and ALL DRIVERS should always
> output the position before outputting a SUBSTITUTED character.
> They should also give the user more than one simple message
> that a substitution has been made, it should probably indicate
> that the user is a candidate for a meal in November. (This
> does not apply to Virtual Fonts.)
How do you specify the position? In inchs? Remember that there are a
lot of people not measuring in inchs.
What do you do with the margins which is left by the printer? If
the driver reports a position of (1in,1in) it is not really the
position on the paper sheet in most cases and often does not mean the
same on two sheets output by one printer! How does the user measure
this?
What do you with previews? I think TeX systems without previews are
not usable so we should take a strong look that we take them into
acount.
> I agree with the level 0 requirement of accomodating 256 character
> fonts. An implementation strategy that has some merit is to
> treat any font with more than 128 as two fonts. This requires
> an extra if in the set_chr routine (and put_chr). Some printers
> will have rather arbitrary limits on the number of characters
> that a font can contain. For example, you can't download in
> positions 0..31, 128+0..128+31, 127, and 255 in at least one.
> Sometimes it is handy to log exactly which characters are used.
> If most fonts have not more than 128, then the logging is
> more wasteful than it has to be. I am not sure what the
> effects of virtual fonts will be here.
The implementation note is interesting but should of course not go
into the standard. Bart, if a programmer implements the scheme above
why he should not use a free mapping in any case which can be realized
with a hash table (generic moduls for hash tables are available in
many languages).
> I have handled this for the Cray CTSS OS. It has a flat
> file system
Is this one of the reasons why you vote against directory structure
(no personal attack, Bart:-)
I FULLY AGREE with Don Hosek that we should let the choice of
directory structures to the installer -- the driver should be able to
support both.
> and file names can be as long as you want if
> you don't like more than 8 characters in a file name.
> They are cAsE sensitive file names ....
But they *should not be* longer than 8 characters. Ken Yap once said:
``Use a computer which is able to'' but this choice is not always left
to us.
If the names are longer they should differ in the first 8, at least
in the first 14 characters. We had problems a few years ago loading
the UNIX tape from Pierre MacKay on machines with UNIX V because there
were a lot of files which has names equal in their first 14 characters
-- but UNIX V does not allow more! (By the way, this is the reason why
I say that it's an BSD tape not an UNIX tape. TUG does not have a real
UNIX tape which may be loaded on all UNIX systems...)
Joachim
=========================================================================
Date: Thu, 10 May 90 20:40:07 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: "Nelson H. F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: Some remarks on DVI drivers and directory structures
In a recent TUGboat editorial, I noted that I'd like to assist in
the standardization of TeX file directory structures, and that
I'd done a reorganization here to accomplish that so that apart
from syntactic sugar, the directory tree is identical on UNIX
(BSD and System V), TOPS-20, VAX VMS, PC DOS, and would be
acceptable on Atari DOS as well. I also asked TeX implementors
to send me a short summary of their current tree structure; so
far, I've only had one reply.
While Bart's scheme of 0, h, 1, 2, 3, etc for naming is compact,
it breaks down when fonts are used with magnifications that are
not powers of sqrt(1.2). Recall that the original LaTeX
lplain.tex file used different numbers, but was later changed to
stick to the magstep family.
One of my correspondents suggested that the magnification should
be separated from the dots/inch value, so that instead of using
the cmr10.329gf that METAFONT generates, the file would be
renamed to something like /dpi300/1095/cmr10.pk (/ is a directory
separator; substitute your favorite variant). The idea is
possibly of merit, but all files produced by METAFONT would have
to undergo a name rearrangement, as would most TeXware (mostly
DVI drivers) that read font files. His argument was that the
magnifications would then be clearer (1095 = int(sqrt(1.2) *
1000)), a goal that Bart has espoused as well.
I therefore conclude that we will have to use numbers for
magnifications, because they might not be in a magstep family,
and drivers have to be prepared to be flexible in turning a
combination of font name and magnification into a file name.
In my latest 3.0 development, all files can be found in
user-provided search paths on all systems (TEXINPUTS, TEXFONTS,
DVIINPUTS), and the names formats can be controlled by the user.
Part of the `manual page' is included below for more details.
My drivers are in use at thousands of sites, and if one thing has
become clear, it is that people will find a way to do things
differently. Some people have font paths that encode the
magnification or name more than once! The scheme described below
handles that; the old 2.10 drivers did not.
I feel strongly that drivers should support at least PK, GF, and
PXL formats, precisely because there are sites that will have
only the kind you don't support if you don't support all of them.
The convention at Stanford was that all fonts (.tfm, .pk, .gf,
and .pxl) got lumped into a single directory, and that practice
has been followed at many sites. It breaks down as soon as one
must support multiple output devices with different METAFONT
\mode parameters (e.g \mode=imagen and \mode=ln03). In such a
case, it then makes sense to separate the .tfm files, which are
independent of \mode, into a single directory, and to place the
corresponding pk, gf, or pxl in a separate directory. Many
drivers don't need the .tfm files (mine did not until I began to
add support for composite (a.k.a. virtual) fonts), and TeX itself
doesn't need the pk, gf, or pxl files, so there is no compelling
reason to keep them together, and smaller directories do reduce
the search time on some systems. At Utah, we have now several
different font families available, and consequently, I've
subdivided the single font directory into multiple ones:
ams AMS ms* fonts
ap Kinch AP-TeX (Adobe PostScript) fonts (proprietary)
cm Standard Computer Modern
cm-misc Miscellaneous Computer Modern
concrete Concrete Roman
euler AMS Euler fonts
greek Silvio Levy's Greek fonts
imagen Imagen proprietary fonts
music Music fonts
pandora Neenie Billawala's Pandora family
ps tfm's for Adobe resident fonts
vf eventual home of virtual fonts (currently empty)
The rounding of magnifications to the integers that get
incorporated in font names is subject to variability, so my 3.0
drivers support the specification of a magnification list
(FONTMAGS), and provide for substitution of the nearest one when
a font is missing. Bart suggests that this should elicit a
warning message that includes the page position; I currently give
one warning when the font is opened, and will add a debug option
to make the (potentially voluminous) page positions available.
I apologize for this being somewhat rushed. It is 19:25, and
I've got to get home and pack so I can catch a morning plane to
France; I won't be back until the end of the month, so I won't be
able to respond to further comments on this list until June.
Here finally is the documentation excerpt:
FONTFMT For each operating system, there is a
built-in list of font file formats; they can
be overridden at run-time by this environ-
ment variable. Its value contains one or
more format strings, separated by semi-
colons, that define how the font file names
(not including the directory paths) are to
be constructed. For example, on TOPS-20,
the default format list is
%n.%dpk;%n.%dgf;%n.%mpxl
A semicolon separates formats in the list.
These format specifications are recognized:
n Substitute the font name.
m Substitute the magnification in old
Metafont style (1000 means 200
dots/inch).
d Substitute the magnification in new
Metafont style (dots/inch).
#p # is a digit string; substitute the
first # characters of the font name.
This facilitates subdividing large col-
lections of fonts into subdirectories
named by #-character prefixes of the
file names.
In each of these, the format letter may be
in either lower or upper case.
With the above example, the font cmr10 at
normal magnification for a 300-dpi laser
printer would yield the list of names
cmr10.300pk, cmr10.300gf, and cmr10.1500pxl.
By changing this variable, you can alter the
preferred font file format search order, or
restrict the types of fonts that will be
used. The default built-in values in the
drivers always include PK, GF, and PXL file
types in that order; you can save a little
driver run time by excluding types that you
don't have.
When fonts are looked up, the search order
is to try each directory in the TEXFONTS
list before attempting the next format in
the FONTFMT list.
If you specify a value for this variable in
a PC DOS .bat file, you must double each
percent character, since PC DOS uses percent
as an argument escape character.
FONTMAGS When font magnification, or substitution, is
called for, the drivers need to be able to
find neighboring members of the magnifica-
tion family. Each driver has a built-in
list of magnifications suitable for its out-
put device, but this list is larger than
most installations have, and consequently,
the drivers may spend a little extra time
doing file system lookups for non-existent
files. The FONTMAGS variable can enumerate
the available magnifications as a list of
decimal integers separated by whitespace or
punctuation characters (:;,./). These mag-
nifications must be according to the conven-
tion of 1000 meaning 200 dots/inch, as used
in PXL file naming. GF and PK files are
named with a magnification in dots/inch,
converted from the PXL magnification by the
formula dpi = floor(((double)pxlmag +
3.0)/5.0). Because of the rounding, it is
not possible to uniquely determine a pxlmag
value from the dpi value, so if you have
only GF or PK fonts, you will have to work
out the corresponding pxlmag values your-
self. For example, if you have magnifica-
tion steps 0, 0.5, 1, 2, 3, 4, and 5 of a
300-dpi font family, you could set FONTMAGS
to the list 1500, 1643, 1800, 2160, 2592,
3110, 3732. This corresponds to dpi values
of 300, 329, 360, 432, 518, 622, and 746.
At some sites, GF and PK font files have
been found named with magnifications that
are incorrectly rounded from the pxlmag
values; you can create values in the
FONTMAGS variable that will match these,
using the equation given above. The drivers
will choose the closest match to the needed
magnification.
-------
=========================================================================
Date: Thu, 10 May 90 19:36:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: The Level 0 standard (draft 001)
The following represents a minimal standard (level 0) for DVI drivers. The
complete standard will be presented as a series of "tiers" requiring
increasingly stringent control over the output of DVI drivers. A trip test for
DVI drivers will be created which will allow developers of DVI drivers to
insure that their drivers meet the standards developed here. The specifications
here should be considered minimal and driver developers are encouraged to write
drivers whose capabilities are beyond these specifications.
This version of the level 0 standard presented here is draft #001. The final
version will not be released until after it has been reviewed by the driver
standards committee and the TUG membership at large. A revised version of this
will be presented at the TUG 90 meeting at Texas A&M.
I. The DVI file.
As a rule, DVI drivers should be able to interpret any DVI file
which falls within the following limits. These specifications are
a _minimum_; good drivers will probably be able to handle DVI files
exceeding these limits (DVI files which exceed the limits are likely
to be rare, but might still occur).
A. DVI commands.
The driver should be able to interpret every DVI command listed
in section 15 of the DVItype program.
B. Characters.
1. Number of characters in a DVI font.
The driver should be able to handle fonts which have characters
at any code in the range 0<=c<256. Some output devices will
require DVI fonts with more than a given number of characters
to be broken into two or more device fonts when downloaded to
the printer.
2. DVI character size.
The driver should be able to print any character up to a
size of 600pt (h) by 800pt (v). Note that some output devices
will require breaking down such a character into smaller
pieces or drawing the character in graphics mode.
3. Number of DVI characters per page.
The driver should be able to print a page containing as many as
20,000 DVI characters.
C. Rules.
1. Rule size.
The driver should be able to print rules of any size up to
600pt (h) by 800pt (v).
2. Number of rules per page.
The driver should be able to print a page containing as many
as 1000 rules.
D. Stack.
The driver should have, as a minimum, a stack depth of 100 for
DVI push and pop commands.
E. Positioning on the page.
1. Changes in position due to characters.
The driver should accurately track movement using the pixel
width from the font file and the TFM width from either the
font file or TFM file.
2. Limits to movement.
The driver should be able to handle movements in the DVI file
up to a total of $2^31$ DVI units in any direction from the
origin.
3. Objects off of the page.
Any printable object which would lie entirely off the physical
page should not be printed but any changes to positioning should
still be taken into consideration. Any printable object which
would lie partially off the physical page should either be clipped
so that portion of the object that lies off the page is not printed
or omitted entirely.
F. Fonts
1. Font numbers.
The driver should be able to accept font numbers (the
parameter k given by the fnt_def command) in the range
0<=k<256.
2. Distinct DVI fonts.
The driver should be able to handle any document 64 or fewer
distinct DVI fonts on a given page. The driver should also
be able to handle up to 128 distinct DVI fonts in a document.
(If the driver supports printing of selected pages of a DVI
file, the minimum applies to that portion of a DVI file
actually printed--this allows documents containing more than
128 distinct DVI fonts to be printed by selecting portions
of the document).
3. Font formats.
The driver should be able to read PK fonts with the location
and naming specified by an external file. GF support is
optional and PXL support is discouraged.
G. Specials.
The level 0 standard requires no support for specials. Specials
not officially defined by the DVI driver standards committee
should be flagged with a warning upon their first appearance in
the DVI file. If any specials are ignored by the driver, the driver
must issue a warning message.
II. Configuration file.
The driver must have a configuration file read at run-time which
contains in it a model for where the driver will look for any files
it uses. The driver should support reading fonts from both a tree
structure, where the magnification and resolution are incorporated
into the directory where the font resides, and a flat structure,
where the magnification and resolution are incorporated into the
font's extension.
III. Font files.
A. The scaling number.
The magnification and resolution of a font are incorporated into a
scaling number of one of two types:
1. Magnification number.
This number is given by 5*resolution*magnification where the
resolution is given in dots per inch (on devices with a non-unit
aspect ratio, the horizontal resolution should be used) and a
magnification of 1 indicates no magnification.
2. Resolution number.
This number is given by resolution*magnification where both
values are as above. This is the preferred specification for
GF and PK files.
B. Magnifications.
1. Minimum magnifications.
At the minimum, the driver should be able to load fonts at
the following magnifications of its target resolution:
1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44
(magstep2), 1.728 (magstep3), 2.074 (magstep4), 2.488
(magstep5), 2.986 (magstep6), 3.583 (magstep7), and
4.300 (magstep8).
2. Margin of error.
If a DVI file requests a magnification within 2% of an
existing magnification, the driver should use that font
without warning.
C. Missing fonts.
If a font is missing the driver should continue processing
and deal with the missing font in one of three ways:
1. Insert appropriate white space where the font would
appear,
2. Insert black rectangles of the size of the font given in
the TFM file,
3. Print the characters from that font at a different size or
from another font at the same size.
If methods 1 or 2 are used and the driver is unable to locate
size information for the font in question, then the driver
may simply ignore any set_char or put_char commands that
occur while the current font is that font.
=========================================================================
Date: Thu, 10 May 90 19:49:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: Voting
I will be sending reminder notices to those people who are
expected to vote on the standard on a daily basis until all votes
are received. Feel free to take time to read it over and ask for
clarification on any issues (although not too much time--I'd like
all votes in by May 25 when I come back from watching Back to the
Future III). You may vote yes, no, or abstain on any portion of
the standard (thus, you can decide to reject the stuff on the
configuration file while keeping everything else, etc.). You may
change your votes at any time before May 25, so if you hear
something that convinces you were wrong, that's OK.
If there is anybody who thinks that they aren't on the list of
people who will vote who thinks they have a good reason to be on
the list, please send me a note and I'll get back to you.
And again, if there is anything in the draft that you feel could
use clarification, please send a note to the list and I'll
respond to it as quickly as possible.
-dh
=========================================================================
Date: Sun, 13 May 90 20:14:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: Graphics inclusion \special commands
Based on previous discussion on the topic of graphics inclusion
\special commands, it seems that we can assume that the two
parallel approaches to including a graphics file are necessary:
the first is the "simple" approach in which all the information
necessary for including the graphic is given in the \special
command but is specific to a single graphic format while the
second can cover a more general situation where the same graphic
might be stored in several formats and the driver would select
the best format for the output device from those available. For
now, we will concentrate on the former.
Now, the first thing to remember is that there are several
zillion people out there with PostScript printers who want to be
able to consistently include graphics in their output regardless
of whether they're working at home on their PC or at work on a
VAX, so we'll want to be able to handle all the capabilities that
they have available to them now.
The second thing to remember is that there are several zillion
_more_ people who _don't_ have access to PostScript printers and
have to deal with their less sophisticated printers which
frequently not only do not prohibit scaling, but also prevent
rotation of a graphic by even 90 degree increments.
And we want the \special for this to be more-or-less the same for
both situations.
Now, first of all, we need to determine exactly what information
the \special will need. The following seem obvious:
- filename of graphic
- format of graphic (e.g., Tek, PostScript, Xerox 9700 bitmap,
GIFF, etc.)
What about other information?
- size
- orientation
- scaling (would this necessarily be part of size?)
- ???
Not to mention syntax.
I'd like to get some comments back from the rest of the list on
this and see what all of you think.
I'm also going to ask some other groups for comments (e.g.,
comp.text.tex, texhax, uktex) and forward those on to driv-l.
-dh
=========================================================================
Date: Sun, 13 May 90 21:12:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Font naming
Gee, I just discovered that I'm not getting any of the driv-l mail (I've found a
workaround of sorts, so I'll be able to keep up to date, but this is still
inconvenient).
Anyway, first of all, let me say that the level 0 standard was written without
knowledge of Joachim's, Bart's, and Nelson's comments so I hope none of them
thought I was deliberately ignoring them (although I did manage to anticipate
some of their thoughts).
But down to business.
First of all, some thoughts on font naming:
(1) I prefer to have all sizes of any font in a single directory. It's easier to
determine what sizes are available (incidentally Joachim, not all systems will
have a mechanism for doing this; on my previewer for VM/CMS written in WEB, I
had to call an external REXX function to determine what font would be used (see
TeXMaG V2N3) and I think that under MVS such a task would be difficult if not
impossible) for any given font if that is the case.
(2) On systems with a limited name space, we will have problems. The two
nastiest are MS-DOS and System V Unix. On MS-DOS, the current practice is to
encode the size in the directory. Another option would be to name files
something like:
\fonts\canon\pk\XXXXX.NNN
where XXX is the name of the font and NNN is the scaling number. For four digit
scaling numbers, we replace 10YY with aYY, 11YY with bYY etc. (see MF: the
Program for details).
System V is the reason why I'll cling to VMS kicking and screaming until my
fingernails pop off. The fourteen character restriction is on the total size of
the name, so if you have a file called, say, cmssbxsc10.1548pk, system V will
truncate this to cmssbxsc10.154 (in my opinion, this is far worse than the 8/3
restriction of MS-DOS). I think that in order to have any degree of safety in
this environment, it would end up being _necessary_ to have the size of the
fonts encoded in the directory.
In any event, it would be nice if we published a set of preferred naming schemes
for each system. This can be an annex to the level 0 standard.
-dh
Don Hosek "When I was younger, I would throw
dhosek@ymir.claremont.edu spitballs at girls that I liked. Now,
dhosek@ymir.bitnet I beg and plead for dates. Frankly, the
uunet!jarthur!ymir old way was more satisfying."
=========================================================================
Date: Sun, 13 May 90 22:36:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: PXL files
Nelson Beebe at one point said
> I feel strongly that drivers should support at least PK, GF, and PXL formats
> precisely because there are sites that will ahve only the kind you don't
> support if you don't support all of them.
I know that there are a few people out there who are aware of my vehement
disapproval of PXL files. After all, the buggers _have_ been obsolete for a long
time and have many limitations.
The time required to complete even a large amount of PXL files into PK format
is fairly trivial and the space savings are tremendous (on the average 50% or
more, I believe). If a site has more than one device and one device's driver
requires PXL files, fine, they should have two sets of rasters anyway.
Incidentally, as I noted in my comments on Rick Caldwell's note, implicit in the
requirement that drivers handle 256-character fonts is non-support of PXL files.
I'm not sure whether this should be made explicit, but it isn't a coincidence
that I didn't mention PXLs at all.
I think that the obvious choice for a font format which all drivers must support
is clearly PK. (incidentally, Joachim's comment on GFs is a good one, although I
find that in my MF work, in the early stages I'm dealing primarily with GFtoDVI
proofs so using GFtoPK to handle actual tests isn't that big of a deal).
-dh
=========================================================================
Date: Mon, 14 May 90 11:48:00 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: jsg@ARBORTEXT.COM
Subject: Re: Font naming
The large majority of TeX installations on PCs I believe come from
ArborText or Personal TeX. Both of us use a font naming convention
that separates fonts by resolution (or magnification, which is the
same thing). DVILASER/PS, for example, will look for a file
"...\dpi360\cmr10.pk" if it is trying to typeset "cmr10 at 12pt" on a
300 dot per inch printer.
I think that on balance the arguments favor this approach. They have
already been made by other people and I won't try to restate them.
The main point I'd like to make is that a standard that mandates a
flat directory structure would demand an incompatible change on the
part of the majority of PC users of TeX.
John Gourlay
jsg@arbortext.com
=========================================================================
Date: Mon, 14 May 90 15:38:58 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Wayne Podaima <WJP@VM.NRC.CA>
Subject: Re: Graphics inclusion \special commands
In-Reply-To: Message of Sun, 13 May 90 20:14:00 PDT from <DHOSEK@HMCVAX>
On Sun, 13 May 90 20:14:00 PDT <DHOSEK@HMCVAX> said:
>
>Now, first of all, we need to determine exactly what information
>the \special will need. The following seem obvious:
>- filename of graphic
>- format of graphic (e.g., Tek, PostScript, Xerox 9700 bitmap,
> GIFF, etc.)
>
>What about other information?
One other item that should be considered as an optional param (defaulting
to 1) is the graphics/plot number within the file - to handle CGM, Tek, ???,
files that can contain multiple plots.
=========================================================================
Date: Mon, 14 May 90 20:21:47 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: XITIJSCH@DDATHD21.BITNET
Subject: Remarks on level 0 standard (lots and urgent)
INTRODUCTION
============
Below follow the remarks of two people, Joachim Schrod and Klaus
Guntermann from Darmstadt, on Don Hoseks proposal of a level 0 DVI
standard. (It is a long mail but is worth reading :-)
But before we plunge into details we want to point out a principal
problem of the proposal. It is not mentioned why a feature is
included in this level and why others are left out. This is because
it is not mentioned what *is* the level 0 standard, i.e., what kind
of driver features we have in mind when we talk about the level 0. We
will develop a scheme below.
To pinpoint the consequences of the preceding paragraph: there are
oddnesses which in our opinion will be points of discussion after
the presentation of the level 0 standard and will hinder the
forthcoming of the standardization effort. As an example: for a user
of a DVI driver it is certainly more important to alter the offsets
on the page or to specify page ranges he wants to output (if the
output device is a printer) than to alter at run time the way
directories or font files are named on his system! Usually he will
install his fonts the way the driver requires it and will live with
that. But more about this point below, this should only be a hint to
the problems with the topics mentioned in the level 0 standard.
PLEASE REMEMBER, we want to have a driver standard which
1. is oriented towards the NEEDS OF USERS -- we have to face their
needs and wishes first!
2. is implementable per se and gives explanations about the ``correct
way'' to do it if and only if this affects the output. All other
implementation specific informations are hints.
3. is implementable in an efficient manner -- users don't want to wait
minutes to get their first page on a screen or hours to get it on a
sheet of paper.
This enumeration is orderd by importance.
CLASSIFICATION OF THE DVI STANDARD
==================================
We propose a classification of the DVI standard: The standard is
described as basic output functionalities which result in a level 0.
Afterwards two traces are constructed: Trace U describes the features
which are important for the user interface and trace C describes the
features which are important for configuration and installation. Both
traces consist of sublevels.
To distinguish between these traces is important because a driver
may have a sophisticated user interface but does not provide any
control over the configuration. (Such drivers do exist!)
E.g. a driver may conform to the standard level U3/C1. Then this
driver will provide the features as defined in sublevel 3 of trace U
and in sublevel 1 of trace C. If a driver does not conform to any of
the sublevels of a trace it is said that the driver conforms to
sublevel 0 of this trace; i.e., a driver on level 0 will confom to
the standard level U0/C0.
This classification should be incorporated in a preface of the DVI
standard. It will provide a framework for questions and answers and
will explain ``the architecture of the whole building.'' It is needed
in order to enable the standard comittee to respond to an objection
with ``That is not the topic of the current level/discussion. We will
consider it when discussing level xxx (again).'' Without this we will
not be able to put together a complete standard in acceptable time.
The definitions of levels above 0 will address features. We want to
call your attention to our paper ``High Quality DVI Drivers'',
presented at TeX88 in Exeter, where we have named the corresponding
features and where we have classified them.
LEVEL 0
-------
The level 0 standard is THE DEFINITION OF BASIC OUTPUT
FUNCTIONALITIES all DVI drivers *MUST* share.
I.e., level 0 must define what is necessary to output a given DVI
document in a way so that two DVI drivers -- using the same fonts --
will produce the same output on a specific device. For a user, the
notion of ``a driver conforms to level 0'' will mean: this driver
outputs DVI correctly -- nothing more.
To assert this the level 0 standard must contain much technical
material. This includes definitions of file formats (DVI, TFM, PK,
GF, PXL, and VF), definitions of algorithms (rounding and maximal
drift handling), and minimal requirements both for the
`must-be-handled' complexities and for the driver environment (e.g.
to assure the ability to use more than one printer on a single
computer system, perhaps with drivers of different families).
These definitions must not be given as programs, i.e., a reference
to DVItype or a chapter of TeX is not appropriate. They must be given
as parts of the standards (e.g. as appendices, see below). At first
they will be rather informal (literate) specifications, we may
substitute them with formal specifications later. But if we
incorporate formal specifications we should pay attention to the fact
that we should not use WEB (Pascal) nor any other existing
programming language to express the semantics because this may lead
to implementations which are not appropriate.
TRACE U, SUBLEVEL 1
-------------------
The level U1 will be THE DEFINITION OF BASIC USER FUNCTIONALITIES all
DVI drivers should provide.
I.e., level U1 will define such features as offset settings, page
selection, etc. A proposal for a list of such features may be found
in our paper ``High Quality DVI Drivers'' which we presented at TeX88
in Exeter.
TRACE U, SUBLEVEL 2
-------------------
The level U2 will be THE DEFINITION OF ADDITIONAL USER FEATURES
medium quality DVI drivers should provide.
It will consist of three parts, (1) features for all drivers,
(2) features for previews, and (3) features for printer drivers.
I.e., level U2 will define such functionalities as multiple DVI files,
selection of output orientation, interactive reduction of text on a
screen, etc.
TRACE U, SUBLEVEL 3
-------------------
The level U3 will be THE DEFINITION OF ADDITIONAL USER FEATURES high
quality DVI drivers should provide.
It will also consist of three parts, (1) features for all drivers,
(2) features for previews, and (3) features for printer drivers.
I.e., level U3 will define such features as selection of paper format,
placement of multiple pages on one sheet, display of a ruler, etc.
TRACE C, SUBLEVEL 1
-------------------
The level C1 will be THE DEFINITION OF BASIC CONFIGURATION AND
INSTALLATION FEATURES all DVI drivers should provide.
I.e., level C1 will define such things as standard naming conventions,
configuration possibilites (parts of them have been included in the
current proposal of level 0), etc.
TRACE C, SUBLEVEL 2
-------------------
The level C2 will be THE DEFINITION OF ADDITIONAL CONFIGURATION AND
INSTALLATION FEATURES quality DVI drivers should provide.
I.e., level C2 will define such things as flexibility on naming
conventions, configuration possibilites at run time, search paths,
etc.
Other sublevels (and other traces? distribution?) may be added.
THE LEVEL 0 STANDARD
====================
In this section we will present comments and alterations to the text
Don Hosek has sent. The original proposal will always be cited and
often replacements will be proposed, original and replacement will be
indented to distinguish it from our comments. (Don, would you please
shorten your lines to 70 chars the next time? :-)
The appendices mentioned below must be added to allow the
concentration of all informations at one place.
-----
Proposal:
The following represents a minimal standard (level 0) for DVI drivers. The
complete standard will be presented as a series of "tiers" requiring
increasingly stringent control over the output of DVI drivers. A trip test
for DVI drivers will be created which will allow developers of DVI drivers
to insure that their drivers meet the standards developed here.
The above considerations should be incorporated in this paragraph.
This will be a repetition of the preface but we think it will clarify
this section.
It should be noted that a trip test for drivers will not be able
to test *all* things; i.e., it may not test the handling of max
drift, font replacement, etc., because they influence the output
which is on paper or on screen!
-----
Proposal:
A. DVI commands.
The driver should be able to interpret every DVI command listed
in section 15 of the DVItype program.
change it to:
A. DVI commands.
The driver should be able to interpret every DVI command listed
in appendix A.
Appendix A should be the appropriate section of DVItype or TeX. (Don,
if you need it as a LaTeX or Plain TeX text, contact Joachim :-)
-----
Proposal:
1. Changes in position due to characters.
The driver should accurately track movement using the pixel
width from the font file and the TFM width from either the
font file or TFM file.
change it to:
1. Changes in position due to characters.
The driver should accurately track movement using the pixel
width from the font file (see III) and the TFM width from
either the font file or TFM file as specified in appendix B.
The format of a TFM file is given in appendix C.
Add appendix B where both the formula for rounding (different between
characters and rules!) and the algorithm of max drift handling is
explained. (Has somebody already extracted it from the mailings?
Otherwise Joachim will do it -- please respond quickly.)
Add appendix C with the TFM definition (e.g. from TeX or TFtoPL).
-----
Proposal:
3. Font formats.
The driver should be able to read PK fonts with the location
and naming specified by an external file. GF support is
optional and PXL support is discouraged.
delete it and insert as new III.A:
A. Font formats.
The driver should be able to read PK fonts. The format of a
PK font is given in appendix D.
The font formats should not be covered in the section about the DVI
file.
Add appendix D with the PK format (e.g. of PKtype).
GF and PXL support is part of level U2 (additional functionality
for the user). The configuration of location and naming is part of
trace C. We want to stress the argument again: users need offset
changes and page selections, not name alterations at the basic
levels. (At least that is the feedback of the users of our driver
family which runs at several hundred sites. Besides, the original
would mean that the Beebe driver family in a version <3.0 does not
conform to level 0; that would be silly :-)
-----
Proposal:
II. Configuration file.
The driver must have a configuration file read at run-time which
contains in it a model for where the driver will look for any files
it uses. The driver should support reading fonts from both a tree
structure, where the magnification and resolution are incorporated
into the directory where the font resides, and a flat structure,
where the magnification and resolution are incorporated into the
font's extension.
delete it and insert it in trace C.
Only a high quality driver has to support both forms and only then
the configuration must be specifiable at run time. By the way, the
concentration on a configuration file would be nonsense anyway. This
is an implementation issue. The feature is configuration at run time,
not how it is done.
Remember: we are talking about *LEVEL 0*.
-----
Proposal:
III. Font files.
substitute by:
III. Font files.
The naming conventions and standard locations of font files
must assure that fonts for different output devices may be
distinguished. The name of the fonts location should contain
a reference to the mode_def name, if the fonts were created
by METAFONT.
This is the basic functionality that allows the usage of more than
one device with different drivers.
Please note that we do not specify the way the naming conventions
should be. Level 0 is responsible for the BASIC OUTPUT FUNCTIONALITY,
these problems will be addressed in trace C.
-----
Proposal:
1. Magnification number.
This number is given by 5*resolution*magnification where the
change to:
1. Magnification number.
This number is given by the scaling factor relative to 200dpi
in per mille, i.e., 5*resolution*magnification where the
This change explains the obscure factor five.
-----
Proposal:
B. Magnifications.
1. Minimum magnifications.
At the minimum, the driver should be able to load fonts at
the following magnifications of its target resolution:
1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44
(magstep2), 1.728 (magstep3), 2.074 (magstep4), 2.488
(magstep5), 2.986 (magstep6), 3.583 (magstep7), and
4.300 (magstep8).
2. Margin of error.
If a DVI file requests a magnification within 2% of an
existing magnification, the driver should use that font
without warning.
change to:
B. Magnifications.
A driver must be able to load fonts at every magnification.
1. Minimum repair of rounding errors:
If a font file in one of the following magnifications is
requested and exists, the font must be accessed even in
the presence of rounding errors:
0.5, 0.6, 0.7, 0.8, 0.9,
1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44
(magstep2), 1.728 (magstep3), 2.074 (magstep4), 2.488
(magstep5), 2.986 (magstep6), 3.583 (magstep7),
4.300 (magstep8), and 5.160 (magstep9).
The proposal is both too little and too much: Why should a driver
only work with those magsteps? (E.g., LaTeX uses other magnifications
as well and in Europe often magnification of 1.414 are used for
output on A formats which will be reduced later.) On the other hand
rounding errors at magnifications 0.5 ... 0.9 should be recognized,
too, because they are often used to substitute fonts which are not
available in small design sizes, e.g. cmcsc10 scaled 700 instead of
cmcsc7.
The ignorance of an 2% error for *all existing* magnifications
would require a directory or file search and that's too much for the
level 0. Let's include 2. into level C2.
-----
Insert in the proposal:
IV. The Output.
A. Alteration of output.
If the output differs from the DVI specification more than
caused by technical reasons (i.e. resolution) due to clipping
of characters or rules, ignorance of specials, or substitution
or neglection of fonts, a warning must be issued. This
warning should give the user enough information to locate
the problem in his output.
We think the reason for the insertion is clear.
-----
Topic I.E.1 should be moved to IV, perhaps as IV.B, because the
change of positions belongs more to the output than to the DVI file.
SUMMARY
=======
We have presented a classification of standard levels and revised the
proposal of Don Hosek according to this classification. We hope that
our arguments are taken into account and that the standard is changed
in the way we have proposed, we are sure that it will be worthwile.
Joachim is able to provide the appendices we have requested if they
are not available to the comittee in LaTeX or Plain TeX form.
Somebody whose native language is English should rework our
formulations, this person should especially pay attention to the
usage of should and must. This problem is also in the text of Don.
Joachim Schrod XITIJSCH@DDATHD21.Bitnet
Klaus Guntermann XITIKGUN@DDATHD21.Bitnet
TH Darmstadt
Institut f\"ur Theoretische Informatik
Alexanderstr. 10
D-6100 Darmstadt
FR Germany
=========================================================================
Date: Mon, 14 May 90 19:34:49 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: "Tomas G. Rokicki" <rokicki@NEON.STANFORD.EDU>
Subject: The Level 0 standard (draft 001)
In-Reply-To: DHOSEK@HMCVAX.BITNET's message of Thu,
10 May 90 19:36:00 PDT <9005110248.AA23152@Sunburn.Stanford.EDU>
My vote on the standard:
> The driver should be able to read PK fonts with the location
> and naming specified by an external file. GF support is
> optional and PXL support is discouraged.
Very good. PXL files should most assuredly be discouraged in no uncertain
terms; this standard must be forward-looking.
> 1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44
Add magstep9 (please; SliTeX uses it) and change 1.095 to sqrt(1.2) (which
is what MF uses when generating the resolution number and thus the name of
the font . . .)
I think we should explicitly and highly discourage drivers that go to extreme
lengths to find a font file that matches---often using a much too small font,
for instance, if the larger size isn't found. People accept the output as
`correct', besmirching the good name of TeX, and wonder why it prints
differently at other sites. Perhaps we could set a maximum error (5% would
be a good upper limit on such an error).
Everything else is fine . . .
-tom
=========================================================================
Date: Mon, 14 May 90 20:19:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: FWD: RE: Requesting recommendations on graphics inclusion
standardization
The first of the responses on the graphics inclusion standardization has floated
in...
Received: from newton.phys.washington.edu by HMCVAX.CLAREMONT.EDU; Mon, 14 May
90 20:13 PDT
Received: by newton.phys.washington.edu (5.61/UW-NDC Revision: 2.1 ) id
AA13097; Mon, 14 May 90 20:16:45 -0700
Date: Mon, 14 May 90 20:16:45 -0700
From: "Laurence G. Yaffe" <lgy@newton.phys.washington.edu>
Subject: RE: Requesting recommendations on graphics inclusion standardization
To: dhosek@HMCVAX.CLAREMONT.EDU
Message-id: <9005150316.AA13097@newton.phys.washington.edu>
X-Envelope-to: dhosek
One aspect of this graphics standards effort which I believe is
extremely important, but which I have not seen discussed, is the
desirability of allowing a single source file to describe both the
text and graphics of a document. This makes mailing a document,
or collaborating with others in its perparations vastly easier.
(In contrast, my last manuscript used over 100 separate source files
in order to handle a large number of figures!) Secondly, as you note,
I believe that it is important to allow the possibility of other
graphics languages besides Postscript. In my view, the following
1) Some way to instruct TeX to place the entire contents of a file
(possibly preceded by some text) into a single \special.
I know that DVI files may contain special commands specifying
large amounts of information (> 2^20 bytes) - however I am
unaware of any way to place the contents of a file into a special
which avoids the various internal TeX limits on macro argument
length (or box size, etc.). If this is currently possible, I would
dearly love to know how.
2) Some way to instruct TeX to place a block of text verbatim into
a special - without running into internal TeX limits. (Something
akin to the Unix sh/csh "here-is" document (i.e., "<<_SOME_TERMINATOR_").
3) DVI driver standards which permit run-time flexibility in the
processing of \specials. What I have in mind is the ability
to instruct the DVI driver "take this information and filter
it through the program 'foobar' which will produce Postscript
(or some other graphics langauge) which should then be included".
I realize that this introduces some operating system dependencies -
but that's unavoidable.
Given, for example, a DVI driver which does emit Postscript, these
ingredients would enable one place arbitrary Postscript, Fig code,
or any other form of information directly into a TeX file, without actually
requiring that the DVI driver understand any of these graphics languages
directly - merely that it be able to talk to an external conversion
program producing Postscript. I really wish this were possible today.
--------------------------------------------------------------------------
Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu
University of Washington Bitnet: yaffe@uwaphast.bitnet
=========================================================================
Date: Mon, 14 May 90 22:47:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: FWD: Details of \special{} and paper language
Date: Thu 10 May 90 10:53:01-MDT
From: "Nelson H. F. Beebe" <Beebe@science.utah.edu>
Subject: Details of \special{} and paper language
X-US-Mail:
"Center for Scientific Computing, South Physics, University of Utah, Salt Lake
City, UT 84112"
X-Telephone: (801) 581-5254
Here is what I've extracted from paper.c and specia.c; lines like
========================================================================
separate the inclusions.
========================================================================
From paper.c, which implements the parser used for both paper
specification and \special{}s:
Paper handling and specification is a complex issue, and may require
future extensions. Thus, it is desirable to have a flexible means of
specifying paper characteristics, and a reasonable scheme seems to be
to have the -paper switch take as an argument a small program in a
minilanguage that contains a compound statement with embedded simple
assignment statements.
The variables to which values are assigned are given in the
form_record structure, and the symbol_table[] array; those two
variables need to be modified to add support for new ones.
The -paper switch should be able to both select a pre-defined paper
type, and define a new paper type. Usually, the latter usage will
appear only in startup files.
An example of command-line selection of paper type might be
-paper:letter
A definition of paper characteristics might be compactly specified as
-paper:{paper="letter";width=8.5in;height=11in;dev_init="...";}
or more readably, as
-paper:
{
paper = "letter"; % standard US paper size
width = 8.5in;
height = 11in;
x_origin = 1.05in; % printer origin is off by 0.05in
y_origin = 1in;
x_clip = 1; % printer wraps coordinates, so
y_clip = 1; % we need clipping turned on
x_left = 0.3in; % not all of page is imageable
x_right = 0.3in;
y_top = 0.5in;
y_bottom = 0.5in;
output_order = -1; % print pages from last to first
dev_init = "...." % adjacent strings are concatenated
"...."
"....";
dev_term = "\f\033E"; % final formfeed and printer reset
page_init = "....";
page_term = "....";
}
Comments are from percent to end-of-line (like TeX), and letter case
is not significant in variable names. Whitespace is ignored, so the
specification can be formatted for readability, or for compactness.
Dimensions can be given in any unit known to TeX (bp cc cm dd in mm pc
pt sp).
The presence of a left brace following the paper switch signals that a
forms definition follows; otherwise, the following token is a paper
name. To facilitate collection of the complete specification at a
higher level without having to parse it in detail, braces must be
balanced; escape sequences and comments provide ways to ensure this.
UNIX supports multiline arguments, so the paper specification could
come on the command line; most other systems do not, but the startup
files provide the facility.
The variables that can be specified in the language are as follows:
------------------------------------------------------------------------
name type value
------------------------------------------------------------------------
paper string standard form name (e.g. "A4", "US-legal")
use string name of form to copy values from
dev_init string device initialization string
dev_term string device termination string
height dimension physical paper height
output_order number negative value means print in reverse order
page_init string page initialization string
page_term string page termination string
width dimension physical paper width
x_origin dimension offset of TeX (0,0) point from left edge
y_origin dimension offset of TeX (0,0) point from top edge
x_left dimension width of unprintable region on left edge
x_right dimension width of unprintable region on right edge
y_top dimension width of unprintable region on top edge
y_bottom dimension width of unprintable region on bottom edge
x_clip number non-zero means x clipping enabled
y_clip number non-zero means y clipping enabled
------------------------------------------------------------------------
The PAPER variable must always be given, since it is the key into the
paper_table[] array, and its values represent the legal set of
-paper:xxx switches. If it is omitted, then the accumulated variables
will silently be discarded, since no acceptable entry in paper_table[]
will have been found. The paper_table[] array is expanded dynamically
to handle any number of entries. Existing paper_table[] entries can
be modified by later programs, making it convenient to maintain a base
file containing standard paper definitions that are later modified to
specify additional peculiarities of particular printers.
The USE variable requests copying parameters from an already-existing
form. Such copying happens BEFORE any other parameters from the
current program are copied, and that is done AFTER the complete
program has been successfully parsed. Thus, only the last USE
parameter given in a program is effective. This makes it easy to
prepare modifications of base forms. For example, most laser printers
use the same size paper, but differ in the imageable area and output
stacking order. Programs like
{
paper = "ALW-note";
use = "letter";
x_left = 0.41in;
x_right = 0.41in;
y_top = 0.42in;
y_bottom = 0.42in;
}
{
paper = "ALW-letter";
use = "letter";
x_left = 0.25in;
x_right = 0.25in;
y_top = 0.04in;
y_bottom = 0.04in;
}
{
paper = "ALW-legal";
use = "US-legal";
x_left = 0.89in;
x_right = 0.89in;
y_top = 0.5in;
y_bottom = 0.5in;
}
would describe the three paper types note, letter, and legal known to
the Apple LaserWriter.
The DEV_INIT and DEV_TERM strings supply information that informs the
printer about the paper types; the strings will be sent at the
beginning and end of the output. In the case of PostScript devices,
which have macro definitions downloaded before the printing commands,
the device initialization string will come between the two.
Generally, only expensive high-performance printers offer facilities
these strings can take advantage of, so for most applications, they
need not be specified. The internal token buffer expands dynamically
to accommodate long strings, so there is no limit, other than total
available memory, on the size of these strings.
The PAGE_INIT and PAGE_TERM strings are similar in intent to DEV_INIT
and DEV_TERM; they are issued at the start and end of every output
page.
By decree of the Stanford TeX Project, (X_ORIGIN,Y_ORIGIN) = (1in,1in)
for a DVI driver, and all standard macro packages (LaTeX, SliTeX,
AMSTeX, Plain TeX) assume this. In rare circumstances, it may be
desirable to change it.
The HEIGHT and WIDTH values define the physical page dimensions. The
variables X_LEFT, X_RIGHT, Y_TOP, and Y_BOTTOM measure unprintable
regions in the margins; for example, many laser printers cannot print
closer than about 0.3in from the paper edges. These values are used
when X_CLIP or Y_CLIP is selected. For devices which must be sent a
page bitmap, the dimensions of the printable region define the size of
the page bitmap, which is allocated dynamically by the DVI drivers.
For high-resolution printers on machines with limited memory, the page
bitmap requirements can be large, and the availability of these
parameters in a configuration file, instead of as hardcoded values in
the compiled program, should facilitate tuning memory usage.
Although the page printing order is already a run-time selectable
option, there are now several models of Hewlett-Packard LaserJet
printers, and clones, with different paper stacking order, The
OUTPUT_ORDER option makes it convenient to choose the order as part of
the paper definition.
The clipping actions implemented when X_CLIP or Y_CLIP are non-zero
save unnecessary transmission of off-page characters to the output
device, and prevent unpleasant side effects, such as coordinate wrap
on some printers (e.g. Hewlett-Packard LaserJet Plus and Series II).
For most applications, clipping should be enabled.
The grammar for the minilanguage is based on the C language grammar
given in Appendix B of
@Book{Harbison:carm-2,
author = "Samuel P. Harbison and Guy L. {Steele Jr.}",
title = "C---A Reference Manual",
publisher = "Prentice-Hall",
year = 1987,
edition = "Second",
}
with changes affecting hexadecimal escape sequences in strings, and
concatenation of adjacent strings, as specified in the January 1988
draft ANSI C standard. Adjacent string concatenation is a convenient
way of working around limitations on line length when long strings are
needed, and adding support for it took only 4 lines of code.
Hexadecimal escape sequences of arbitrary length permit transparent
support for character sizes larger than 8 bits. Octal escape
sequences remain limited to 3 digits (for backward compatibility;
hexadecimal escape sequences are new with the draft ANSI C standard).
In the following grammar, the suffix -opt means that the item is
optional. Numeric constants are not specified in grammatical form.
They are parsed by the ANSI standard library routine, strtod(), which
expects numbers in the form ([] marks optional fields, {|} marks
alternatives):
[whitespace][sign][digits][. digits][{e|E}[sign]digits]
Except in quoted strings, tokens may not contain embedded blanks.
Thus, 210mm is legal input, but 210 mm is not.
Here finally is the grammar parsed by paper(), which expects a program
as its argument:
program:
statement
statement:
assignment-statement
compound-statement
null-statement
assignment-statement:
name = constant
name : constant
name constant
compound-statement:
{ statement-list-opt }
null-statement:
,
;
statement-list:
statement
statement ; statement-list
statement , statement-list
constant:
dimension-constant
float-constant
string-constant
name
dimension-constant:
float-constant dimension-unit
dimension-unit: one of
bp cc cm dd in mm pc pt sp
string-constant:
simple-string-constant
string-constant simple-string-constant
simple-string-constant:
" character-sequence-opt "
' raw-character-sequence-opt '
character-sequence:
character
character-sequence character
raw-character-sequence:
raw-character
raw-character-sequence character
character:
printing-character
escape-character
raw-character:
printing-character
\'
printing-character: one of (note that " and \ are omitted, and ' may
be specified by \' as well)
<space> ! # $ % & ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ ] ^ _
` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~
escape-character:
\ escape-code
escape-code:
character-escape-code
octal-escape-code
hexadecimal-escape-code
character-escape-code:
a b f n r t v \ ' "
octal-escape-code:
octal-digit
octal-digit octal-digit
octal-digit octal-digit octal-digit
hexadecimal-escape-code:
x hexadecimal-digit
hexadecimal-escape-code hexadecimal-digit
octal-digit: one of
0 1 2 3 4 5 6 7
hexadecimal-digit: one of
0 1 2 3 4 5 6 7 8 9 A B C D E F a b c d e f
name:
letter
letter extended-letter-sequence
extended-letter-sequence:
extended-letter
extended-letter-sequence extended-letter
letter: one of alphabetic or underscore characters
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
_
extended-letter:
0 1 2 3 4 5 6 7 8 9
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
- . _
The characters permitted in extended-letter are chosen (a) not to
conflict with characters otherwise significant in the grammar, and (b)
to cover the most common filename syntax so as to allow unquoted
simple filenames to be collected as single constant name tokens for
assignments.
This grammar supports two kinds of quoted strings. The normal kind is
delimited by double quotes, and inside it are recognized all the
escape sequences supported by the C language. The raw kind is
delimited by single quotes; only escape-single-quote pairs are
recognized inside it. This is more convenient when it is necessary to
have strings with several backslashes, since it then avoids having to
double all of them. Once they are parsed, they are both labelled
T_STRING.
The grammar supports statement separators (rather than terminators),
and they may be either commas or semicolons. In a simple language, it
is convenient to allow both separators, and since there is a null
statement, the final separator before a right brace may optionally be
omitted.
Finally, note that the assignment statement may use either the equals
or colon operator, or the operator may be omitted. This supports
the common syntaxes
keyword = value
keyword : value
keyword value
Because the values have very limited syntactical possibilities, there
is no ambiguity created by this.
The code below uses private objects yylex(), yypeek(), yyerrors, yyleng,
yypending, yytoken, and yytype, by analogy with the UNIX lexical
analyzer generator, lex. However, in the interests of wide
portability, lex and yacc (the UNIX parser generator) are rejected in
favor of a hand-coded recursive descent parser, with lexical analysis
implemented in next_token(), and accessed by calls to yylex() and
yypeek().
Most of the functions defined here are declared static, so that they
are known only within this file. The only public one available outside
is
paper(const char *pgm)
Parse a paper specification program.
After the code was written for the support of paper programs, code was
added for \special{} string keywords, and for key binding keywords for
interactive device drivers.
The \special{} keywords are:
------------------------------------------------------------------------
name type value
------------------------------------------------------------------------
boundingbox string bounding box extents
graphics string low-level graphics commands
include string plot file at current point
language string device language
literal string device-dependent literal text
message string text to be typed to terminal
options string miscellaneous options
overlay string plot file overlayed on page
position string bounding box position
------------------------------------------------------------------------
The key bindings keywords are:
------------------------------------------------------------------------
name type value
------------------------------------------------------------------------
exit_level string return from current display level
first_page string goto first document page
goto_page string goto n-th document page
help string ask for help
home_window string set window to original position
horizontal_move_fraction number fractional overlap for move
horizontal_scroll_fraction number fractional overlap for scroll
last_page string goto last document page
move_down string move text down
move_left string move text left
move_right string move text right
move_up string move text up
next_page string goto next page
noop string do nothing
previous_page string goto previous page
quit string quit program execution
redisplay string redisplay current page
scroll_down string scroll window down
scroll_left string scroll window left
scroll_right string scroll window right
scroll_up string scroll window up
search_backward string search DVI file backward
search_forward string search DVI file forward
universal_argument string argument multiplier prefix
vertical_move_fraction number fractional overlap for move
vertical_scroll_fraction number fractional overlap for scroll
zoom_down string redisplay at lower magnification
zoom_up string redisplay at higher magnification
------------------------------------------------------------------------
[27-Jun-89] -- add key binding names to structures
[21-Jun-89] -- add early return on error (no useful error recovery
seems possible, and quick returns avoid error message
cascades of earlier versions), increase expect()
message detail, extend grammar to support names as
constants for convenience in \special{} grammar (to
allow `include foo.ps' as well as `include "foo.ps"'),
and extend character set permitted in names.
[16-Jun-89] -- add page_initialization and page_termination keywords
[12-Jun-89] -- add boundingbox, message, and position keywords
[26-Apr-89] -- add missing initform(&pt,(const char*)NULL) in paper(),
and support for output_order, and \special{} keywords.
[22-Nov-88] -- original version
========================================================================
From specia.c:
This symbol table defines the keywords, their variables, and their types;
static symbol_entry spec_st[] =
{
{{"dummy",5}, (symbol_value*)&dummy, T_STRING},
{{"boundingbox",11},
(symbol_value*)&spec.boundingbox, T_STRING},
{{"graphics",8},(symbol_value*)&spec.graphics, T_STRING},
{{"include",7}, (symbol_value*)&spec.include, T_STRING},
{{"language",8},(symbol_value*)&spec.language, T_STRING},
{{"literal",7}, (symbol_value*)&spec.literal, T_STRING},
{{"message",7}, (symbol_value*)&spec.message, T_STRING},
{{"options",7}, (symbol_value*)&spec.options, T_STRING},
{{"overlay",7}, (symbol_value*)&spec.overlay, T_STRING},
{{"position",8},(symbol_value*)&spec.position, T_STRING},
};
Here is how it is used:
initstab(spec_st,MAXSPECFIELDS); /* clear all fields */
if (paper(spec_st,MAXSPECFIELDS,program) != 0) /* parse failed; error */
return; /* message has already been written */
On a successful return from paper(), all input variables found in the
paper or special program have been set.
The contents of the TeX \special{} command is expected to conform to a
minilanguage in the same grammar as for paper specifications. The
argument string should contain a series of assignment statements for one
or more of the following keywords:
======= ===== ===================
keyword value action
======= ===== ===================
graphics string execute the generic graphics
primitives in string
(not yet defined)
include filename insert file contents with
relative page positioning
literal string insert literal PostScript
options string not yet defined
overlay filename insert file contents with
absolute page positioning
======= ===== ===================
The order of these is not significant, except that if duplicate keywords
are specified, the value of the last one is used. It is not necessary
to supply a final newline in the strings or files; one will be provided
automatically to ensure correct output.
Literal PostScript code from a file or a literal string is expected to
be well-behaved, and preferably, should conform to Adobe's Encapsulated
PostScript File format version 1.2 or later, and to Adobe's PostScript
Document Structuring Conventions, version 2.0 or later. It may contain
a showpage (which is disabled temporarily here), but it should not
contain any of these:
banddevice grestoreall nulldevice setpageparams
copypage initclip quit setsccbatch
erasepage initgraphics renderbands setscreen
exitserver initmatrix setdevice settransfer
framedevice note setmatrix
If it does, erroneous output is virtually certain. While these commands
could be disabled like showpage is, Adobe's Encapsulated PostScript
guidelines do not recommend doing so.
The imported PostScript should write into its own dictionary if it needs
to define objects. Because dictionary sizes must be specified when they
are created, it is not possible to define a standard one in advance in
the SB and SE macros to protect from corruption of the dictionary used
by dvialw.
The language keyword should specify "PS" or "PostScript" (letter case
does not matter). If any other non-empty value is found, the \special{}
command is ignored, since it presumably applies to some other output
device, and control returns immediately. However, if no language
keyword is given, we assume PostScript, and continue.
Files specified by include/overlay keywords are searched for in the
DVIINPUTS path.
In the "include filename" (the usual) case, the upper-left corner of the
bounding box will be placed at the current point. The PostScript file
must then contain (usually near the start) a comment of the form
%%BoundingBox: llx lly urx ury
specifying the bounding box lower-left and upper-right coordinates in
standard PostScript units (1/72 inch). Alternatively, if the comment
%%BoundingBox: (atend)
is found in the file, the last 4096 characters of the file will be
searched to find a comment of the form:
%%BoundingBox: llx lly urx ury
In the "overlay filename" case, the PostScript file to be included will
be mapped onto the page at precisely the coordinates it specifies, where
the page origin is in the lower-left corner, y increasing upward, x
increasing to the right. Any %%BoundingBox specification is ignored,
since it is not required for positioning. This option might be used to
print an overlay page. For actions that are to be done on every page,
such as printing a logo, or a string like "draft" or "company
confidential", it is more efficient to redefine showpage instead.
If the PostScript file cannot be opened, or the \special{} command
string cannot be recognized, or for relative positioning, the bounding
box cannot be determined, a warning message is issued and the \special
command is ignored.
Any literal string, and the section of the PostScript file between the
comment lines
%begin(plot)
%end(plot)
or the entire file if the %begin(plot) comment cannot be found, is
copied to the output file as
SB % filename
(xcp-llx) (ycp-ury) translate % if relative positioning
...literal string...
...PostScript file contents...
SE % filename
The SB and SE macros revert to standard PostScript units of big points
(1/72 in), and bracket the inserted PostScript text with save/restore
commands. The translate command positions the (0,0) origin of the
inserted PostScript such that the UPPER-LEFT corner of the bounding box
is at TeX's current point.
For literal inserted PostScript without an include/overlay file, the
origin is moved to TeX's current point.
The save/restore in SB and SE ensure that the inserted PostScript
cannot change the environment existing before the \special{}. Should it
be necessary to do so (e.g. to remember things from one special to the
next, or to redefine an operator, like showpage), you should just output
SE followed by your PostScript, followed by another SB. The intervening
PostScript will then apply to TeXdict.
In order to support things like landscape mode, change bars, and grey
shading, it is necessary to have paper dimensions, the bounding box
size, and the current point available to inserted PostScript code.
These are stored in the PostScript macros PaperHeight, PaperWidth,
BoxHeight, BoxWidth, CurrentX, and CurrentY in the outer level TeXdict.
PaperHeight and PaperWidth are set only once, at the beginning of the
job. The other four are redefined before each SB is output. Their
values are all in standard PostScript units of big points (1/72in), NOT
pixels. For an overlay command, the size of the bounding box will be
the page size.
The origin can be moved to the lower-left page corner by the PostScript
sequence
CurrentX neg CurrentY neg translate
This is useful in order to obtain absolute page positioning, such as for
a page logo overlay.
The size of the bounding box (which will be the page size in the event
of "overlay filename") in big points is saved in PostScript macros
BoxWidth and BoxHeight. They can be used to perform geometric
transformations on the included PostScript.
Here are some examples:
% Display a picture with the upper-left corner at the current point
\special{language "PostScript", include "pict.eps"}
% Display a picture at its original absolute page position
\special{language "PostScript", overlay "pict.eps"}
% Use literal PostScript to draw a 1in box with lower-left corner at
% TeX's current point
\special{language "PostScript",
literal "
newpath
0 -72 translate % move origin from upper-left to lower-left
0 0 moveto
0 72 rlineto
72 0 rlineto
0 -72 rlineto
-72 0 rlineto
closepath
4 setlinewidth
stroke
showpage"}
% Display a figure at half size
\special{language "PostScript",
literal "0.5 0.5 scale",
include "pict.eps"}
% Display the figure in landscape mode by rotating the coordinates
% about the center of the bounding box
\special{language "PostScript",
literal "BoxWidth 2 div BoxHeight 2 div translate
90 rotate
BoxWidth -2 div BoxHeight -2 div translate",
include "pict.eps"}
========================================================================
-------
=========================================================================
Date: Tue, 15 May 90 01:12:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: FWD: Requesting recommendations on graphics inclusion
standardization
From: IN%"jwright@cfht.cfht.hawaii.edu" 15-MAY-1990 01:09:38.36
To: dhosek@YMIR.CLAREMONT.EDU
CC:
Subj: Requesting recommendations on graphics inclusion standardization
Return-path: jwright@cfht.cfht.hawaii.edu
Received: from uwila.cfht.hawaii.edu by YMIR.CLAREMONT.EDU; Mon, 14 May 90
21:53 PDT
Received: from quonset.cfht.hawaii.edu by uwila.cfht.hawaii.edu (4.1/CFHT-1.46)
id AA11556; Mon, 14 May 90 18:55:45 HST
Received: by quonset.cfht.hawaii.edu (15.11/15.6) id AA03998; Mon, 14 May 90
18:55:42 hst
Date: Mon, 14 May 90 18:55:40 HST
From: jwright@cfht.cfht.hawaii.edu
Subject: Requesting recommendations on graphics inclusion standardization
To: dhosek@YMIR.CLAREMONT.EDU
Message-id: <9005150455.AA11556@uwila.cfht.hawaii.edu>
X-Envelope-to: dhosek
X-Mailer: Mail User's Shell (6.5 4/17/89)
> Now, first of all, we need to determine exactly what information
> the \special will need. The following seem obvious:
> - filename of graphic
> - format of graphic (e.g., Tek, PostScript, Xerox 9700 bitmap,
> GIFF, etc.)
But aren't file naming conventions quite specific to each different OS?
A least common denominator approach is likely to please no one (except
perhaps those with TOPS-10 machines? :-) I certainly don't have any
great wisdom to share, other than "consider it carefully"...
Jim Wright
jwright@quonset.cfht.hawaii.edu
Canada-France-Hawaii Telescope Corp.
=========================================================================
Date: Tue, 15 May 90 15:33:00 EST
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Ted Werntz <WERNTZ@FORDMURH.BITNET>
Subject: GIF and TIFF files
Since there are GIF and TIFF files (but not GIFF) this might be of interest:
CompuServe's GIF spec is in Simtel20 at PD:<MSDOS.GIF>GIF.ARC
Aldus/Microsoft's TIFF spec ver 5.0 is at PD:<MSDOS2.TIFF>TIFF-50.ARC
Note that the above TIFF spec has provisions for defining special classes,
and that the initial classes were B for bi-level or one bit black and white,
G for Grey Scale, P for Palette and R for RGB full color. An additional
Class F (FAX) seems to now exist. Could there be a benefit to defining a
T for TEX class?
In addition to the 4 (or 5) TIFF classes that are now defined, there is
the additional question of whether the TIFF files are compressed, and if
so, by what compression technique. This information is in the TIFF header
for each TIFF file.
For instance, if you use your PC to emulate a TEK4010 using Joe Doupnik's
new MS-KERMIT ver 3.0, you can produce TIFF class B files if you are using
a monochrome system, and TIFF class P if you are using a VGA. In neither
case are Kermit's TIFF files compressed at present, but Joe is giving
thought to adding compression in the future.
Ted Werntz Werntz@Fordmurh
=========================================================================
Date: Tue, 15 May 90 18:29:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: FWD: \specials
Date: Tue, 15 May 90 08:48:16 CDT
From: cargo@tardis.cray.com
Subject: \specials
To: dhosek@YMIR.CLAREMONT.EDU
Message-id: <9005151348.AA11476@zk.cray.com>
X-Envelope-to: dhosek
Thinking about the inclusion of graphics, some of the things I can think
of might be: Is the graphic defined by absolute position or relative
position? With some bitmap files and printers, a graphic might need to
be absolute and text has to be moved out of the way. Can the graphic be
clipped, and what is the clipping region? This might be possible in many
applications. Resolution? Might be usable for informational purposes.
When including PostScript into TeX on VAX/VMS, I did keep size and scaling
separate (since scaling could be done independently in the x and y directions,
there were two scale factors).
dsc
=========================================================================
Date: Tue, 15 May 90 18:36:11 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Pierre MacKay <mackay@CS.WASHINGTON.EDU>
Subject: delayed answers to mail
I am temporarily unable to answer your messages in a timely manner.
If you are interested in getting TeX 3.0 in a normal distribution,
please send your request to
elisabet@max.acs.washington.edu
If you have technical questions about the distribution, or about
compilation etc., forward your message to the same address, and
Elisabeth will relay them to me.
I must ask you please not to overwhelm Elisabeth with messages.
My mail has been averaging 150 messages a week, which is one of the
reasons I must take this slightly drastic step.
Email: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computer Support Center TUG Site Coordinator for
Lewis Hall 35F, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
=========================================================================
Date: Tue, 15 May 90 19:07:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: FWD: RE: Requesting recommendations on graphics inclusion
standardization
Date: Tue, 15 May 90 16:07:46 CDT
From: ekberg@ti-csl.csc.ti.com
Subject: RE: Requesting recommendations on graphics inclusion standardization
Sender: ekberg@osage.csc.ti.com
To: dhosek@YMIR.CLAREMONT.EDU
Message-id: <9005152107.AA05367@osage.csc.ti.com>
X-Envelope-to: dhosek
> Based on previous discussion on the topic of graphics inclusion
> \special commands, it seems that we can assume that the two
> parallel approaches to including a graphics file are necessary:
> the first is the "simple" approach in which all the information
> necessary for including the graphic is given in the \special
> command but is specific to a single graphic format while the
> second can cover a more general situation where the same graphic
> might be stored in several formats and the driver would select
> the best format for the output device from those available. For
> now, we will concentrate on the former.
I and others in my work group have been using another approach which I find to
be quite acceptable. The previous approaches involved using either psfig or a
locally-written program to allow printing images to an Imagen printer. A
problem with either of these approaches was that you had to remember what
printer to print the document on. This seems to go against the grain of the
DVI philosophy.
The basic idea of our current approach is to capture the graphic as a bitmap
and translate it to LaTeX commands. The translation involves using
special-purpose bitmap fonts to display the bit patterns of the image at the
proper locations. Each character displays 6 bits of the image. The translated
image is placed into the document by just \inputting it. This approach has the
distinct advantage of being DEVICE-INDEPENDENT. I can print the .dvi file on a
PostScript or an Imagen printer without change. I can also display it via a
DVIViewer without change. I have grown to dislike the .dvi files that can only
be printed on one class of printer.
> What about other information?
> - size
> - orientation
> - scaling (would this necessarily be part of size?)
> - ???
The only thing that must be given to TeX is the size. I prefer to delegate the
other tasks to more sophisticated programs, like those in the publicly
available P*M (* is one of B, G, N, or P) collection written by Jef Poskanzer
(pokey@well.sf.ca.us) and the Fuzzy Bitmap collection mostly written by Michael
L. Mauldin (Michael.Mauldin@NL.CS.CMU.EDU). These programs handle many image
formats and many kinds of transformations.
-- tom (aisle C-4Q), ekberg@csc.ti.com
=========================================================================
Date: Wed, 16 May 90 15:21:46 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: jsg@ARBORTEXT.COM
Subject: My vote
I oppose most of the sections of draft 1 of the level 0 proposal. My
comments follow listed by section, and at the end I mention some
topics that I think have been overlooked. I also heartily approve of
the reorganization by Schrod and Guntermann.
I.B.1. How the character set is handled in the printer is irrelevant.
I.B.2. This is not a ``minimal'' requirement.
I.B.3. The driver should not be expected to exceed the limits of the
output device.
I.C.1. The driver should not be expected to exceed the limits of the
output device.
I.C.2. The driver should not be expected to exceed the limits of the
output device.
I.E.1. ``Accurately track'' is ambiguous. Also, pixel widths are
neither available nor relevant when dealing with PostScript or other
scalable kinds of fonts. The standard must accept drivers that handle
such fonts.
I.F.2. The driver should not be expected to exceed the limits of the
output device.
I.F.3. VF support should also be required. I don't know what ``GF
support is optional and PXL support is discouraged'' means in the
context of a standard.
I.G. Up until now the standard as I understood it has been for a
driver to silently ignore specials targeted at a different driver so
that several consecutive specials that do the same thing on different
devices can be processed without spurious warning messages.
II. This is not a ``minimal'' requirement.
III.A. This is an implementation detail that is relevant only as part
of a variable font search feature under section II.
III.B.1. Is this implicitly a requirement on font distribution? If
so it is excessive. If not it should be made clearer.
III.B.2. This is ambiguous. If a driver has a threshold of 1% does
it conform to the standard or not? What about a threshold of 5%?
What about a driver with a variable threshold?
III.C. A driver that scales fonts would appear to violate this section.
III.C.3. This seems to contradict III.B.2.
Here are some topics most of which should be addressed in the level 0
standard:
- positioning of the DVI page on the paper
- the minimal set of fonts that must be included with a driver
- the production of checksum warnings
- the selection of pages from a DVI file
- font substitution
=========================================================================
Date: Wed, 16 May 90 13:09:35 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: "Tomas G. Rokicki" <rokicki@NEON.STANFORD.EDU>
Subject: My vote
In-Reply-To: jsg@ARBORTEXT.COM's message of Wed,
16 May 90 15:21:46 EDT <9005161945.AA18517@Sunburn.Stanford.EDU>
Some comments on some comments:
> I.C.2. The driver should not be expected to exceed the limits of the
> output device.
This is rather loose; one of the limits of the LaserJet, for instance, is
that you can only have 228 chars in a font (or some such); alternative
approaches may overcome various natural limits of devices.
> I.E.1. ``Accurately track'' is ambiguous. Also, pixel widths are
> neither available nor relevant when dealing with PostScript or other
> scalable kinds of fonts. The standard must accept drivers that handle
> such fonts.
I claim that pixel widths should be used when dealing with PostScript fonts;
just because PostScript doesn't set its fonts consistently on a page doesn't
mean that when the fonts are used with TeX they shouldn't be. It's easy to
define pixel widths for PostScript fonts . . . remember that PostScript and
its font cache does do pixel positioning and no subpixel positioning . . .
> I.F.3. VF support should also be required.
Not in level 0; dvidvi or some such can provide such a facility.
Finally, I believe that some mention should be made at least for a landscape
special, as this is perhaps the most often desired special in a driver.
Let's at the very least get this one standardized and in use.
-tom
=========================================================================
Date: Thu, 17 May 90 05:04:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: A landscape special.
>Finally, I believe that some mention should be made at least for a landscape
>special, as this is perhaps the most often desired special in a driver.
>Let's at the very least get this one standardized and in use.
I think that for landscape printing, the X_rotate \special discussed back in May
or whenever that was will work quite well. Some of the advantages of it include
that it's generalized enough that one can also do things like instruct the
printer (assuming it's able to handle it) to rotate text by some arbitrary
angle.
Here are excerpted pieces from the last report we had in TUGboat:
\subsubsection*{Box specials}
A box \Special\ command, since it will always be entirely
typeset on a single page, will be enclosed in a \TeX\ box (\verb+\hbox+
or \verb+\vbox+). In the \DVI\ output, box structure is reflected by
surrounding {\it push\/} and {\it pop\/} commands. For example,
the \TeX\ commands:
\begin{verbatim}
normal
\hbox{\special{abc} special}
text
\end{verbatim}
generate the following \DVI\ code:
\begin{verse}
{\tt "normal"}\\
{\it push}\\
{\it right}\\
{\it xxx} {\tt "abc"}\\
{\tt "special"}\\
{\it pop}\\
{\it right}\\
{\tt "text"}
\end{verse}
A \DVI\ driver can exploit this for a command such as \verb+X_rotate+
by maintaining on the \DVI\ stack, values for items such as
{\it rotation\_angle}.
The X_rotate special would have a syntax of
X_rotate <angle>
where <angle> is the angle to rotate (in a counterclockwise direction) in
\frac{1}{65536} degree units.
An environment for printing in landscape or inverse landscape would be fairly
trivial to implement. The standard way to rotate something would be to do
something along the lines of
\dimen0=90pt
\setbox0=\hbox{\special{X_rotate \the\dimen0} Some text}
\dimen0=\wd0 \dimen1=\ht0 \wd0=\dp0 \ht0=\dimen0 \dp0=0pt
\kern\dimen1 \setbox0
(the last two lines make sure that appropriate spacing is done for the rotated
text--all this would be handled by a macro).
The driver will set the text as best it can and expect TeX to automatically fix
things when it is done working at some odd angle.
-dh
=========================================================================
Date: Thu, 17 May 90 06:23:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DHOSEK@HMCVAX.BITNET
Subject: Re: My vote
>Date: Wed, 16 May 90 15:21:46 EDT
>From: jsg@ARBORTEXT.COM
>I oppose most of the sections of draft 1 of the level 0 proposal. My
>comments follow listed by section, and at the end I mention some
>topics that I think have been overlooked. I also heartily approve of
>the reorganization by Schrod and Guntermann.
>I.B.1. How the character set is handled in the printer is irrelevant.
Yes, but mentioning the fact that that there need not be a 1-1 mapping between
DVI fonts and device fonts, while it may seem obvious, has led to some decrepit
drivers. One of the reasons that 256 character support isn't more widespread is
because some driver authors take the fact that device X can only handle 128
characters in a font to mean that they can only support fonts with <= 128
characters. The standard has to be something more than just a list of
specifications, we should point out implementation details whenever possible.
>I.B.2. This is not a ``minimal'' requirement.
Umm, I'm not sure what you mean by this; point I.B.2 is saying that a driver
should be able to handle characters up to the size mentioned without complaint.
A driver can handle larger characters if it likes. There are many printer
drivers out there that won't print CMINCH!
>I.B.3. The driver should not be expected to exceed the limits of the
>output device.
[plus a few others]
I'm not wedded to the numbers given; I suggested all of these points back in
Jan/Feb when I first brought up the topic. It's entirely possible that there are
printers that don't meet these requirements (can somebody check the stats on the
Xerox 2700 series printers?). I think that at some point, we'll have to accept
the fact that certain output devices are not adequate for TeX use. Obviously, an
IBM line printer would be one of them. Other printers, (e.g., the 2700) ride the
borderline.
>I.E.1. ``Accurately track'' is ambiguous. Also, pixel widths are
>neither available nor relevant when dealing with PostScript or other
>scalable kinds of fonts. The standard must accept drivers that handle
>such fonts.
(1) level 0 doesn't cover internal fonts; (2) as Tom Rokicki pointed out, pixel
widths are relevant for PostScript; (3) the ambiguity was intentional. For the
final draft, we will have to more thoroughly define this, but as we learned last
summer, this is a rather complicated issue.
>I.F.3. VF support should also be required. I don't know what ``GF
>support is optional and PXL support is discouraged'' means in the
>context of a standard.
VF: This is level 0. VF can be handled by a pre-processor.
``..optional..discouraged'': Drivers _must_ read PK files. They can read GF
files if they want. PXL file reading is discouraged since PXL files cannot
contain more than 128 characters, even if the driver deals with this properly, I
would not be surprised to see a system manager typing GFtoPXL on grreg10 (a
256-character font). As I've said before, there's very little reason to continue
using PXL files.
>I.G. Up until now the standard as I understood it has been for a
>driver to silently ignore specials targeted at a different driver so
>that several consecutive specials that do the same thing on different
>devices can be processed without spurious warning messages.
Why should the special to rotate a block of text be different between dvi2hplj
and dvi2postscript? The idea of the standard is to have ONE set of special
commands for all drivers. And if my dvi file has a \special in it that isn't
recognized by the driver, I'd sure like to know about it.
>II. This is not a ``minimal'' requirement.
Sure it is. As an example, a few years ago, I installed TeX on a PC using
Arbortext Preview and PTI's DVICOR. Both drivers had hardcoded into them the
locations of the font files making it necessary to have two copies of the fonts
on the hard disk. The system administrator should be able to specify where fonts
are and how they are organized without recompiling the driver.
>III.A. This is an implementation detail that is relevant only as part
>of a variable font search feature under section II.
>III.B.1. Is this implicitly a requirement on font distribution? If
>so it is excessive. If not it should be made clearer.
No, it's simply stating that if a driver MUST work with a fixed set of
magnifications, it should support these AS A MINIMUM.
>III.B.2. This is ambiguous. If a driver has a threshold of 1% does
>it conform to the standard or not? What about a threshold of 5%?
>What about a driver with a variable threshold?
I'd say that it's 2%, end of story. Let's take a hypothetical situation where a
DVI file requests cmr10 at 10.475pt (TeX wouldn't do this, except under some
really WEIRD circumstances). A 5% threshhold gives 0.52375pts difference or
a range from 9.951pt to 10.999pt. How do you decide between cmr10 and cmr10 at
10,95 pt? 1/2 a point or more is two big of a variance to allow. The purpose is
to allow the driver to deal with a situation where a global magnification in
consort with a magnified font ends up with a size that's just a little off (due
to rounding--see Robert McGaffey's article in TUGboat 8#2). 2% is just enough to
cover the worst cases. More than that can lead to some really ugly results.
>III.C. A driver that scales fonts would appear to violate this section.
Huh?
>III.C.3. This seems to contradict III.B.2.
Oops, I should have said that if the font is missing, a warning message should
be issued. That makes a difference.
>Here are some topics most of which should be addressed in the level 0
>standard:
>- positioning of the DVI page on the paper
The _de facto_ standard is (1in,1in). I see no need to change it, but it should
be mentioned.
>- the minimal set of fonts that must be included with a driver
Fonts should not be inextricably tied to the driver. If you're shipping floppy
disks or tapes, it might not be too big a deal to toss in some fonts, but if
you're distributing the driver via e-mail or FTP, people usually don't want to
have to get several meg of fonts. I think that the minimal font set is something
for the distribution standards people rather than for us.
>- the production of checksum warnings
Yes, this should have been in there as well.
>- the selection of pages from a DVI file
Page selection (and ordering) is a complicated business. There exist
preprocessors which handle this in varying ways. We'll be covering this in a
higher level of the standard (see the old logs for details on this).
>- font substitution
Again, this is not something for level 0.
One thing that would be worthwhile, however, would be to include a note in the
introductory paragraph indicating that a level n driver, if it attempts any of
the tasks discussed in higher levels, should conform to the specifications of
those standard levels.
-dh
=========================================================================
Date: Thu, 17 May 90 07:57:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: FWD: Requesting recommendations on graphics inclusion
standardization
From: IN%"spqr%ecs.southampton.ac.uk@NSFNET-RELAY.AC.UK" "Sebastian Rahtz"
17-MAY-1990 07:56:56.43
To: dhosek%ymir.claremont.edu@NSFNET-RELAY.AC.UK
CC:
Subj: Requesting recommendations on graphics inclusion standardization
Received: from relay.cs.net by YMIR.CLAREMONT.EDU; Thu, 17 May 90 07:55 PDT
Received: from nsfnet-relay.ac.uk by RELAY.CS.NET id aa24331; 17 May 90 10:55
EDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with
NIFTP id aa22462; 17 May 90 14:27 BST
Received: from escher.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Thu, 17 May
90 13:45:17 BST
Date: Thu, 17 May 90 13:43:53 bst
From: Sebastian Rahtz <spqr%ecs.southampton.ac.uk@NSFNET-RELAY.AC.UK>
Subject: Requesting recommendations on graphics inclusion standardization
In-reply-to: <73.9005161036@cameron.ecs.soton.ac.uk>
To: dhosek%ymir.claremont.edu@NSFNET-RELAY.AC.UK
Message-id: <3074.9005171243@escher.ecs.soton.ac.uk>
X-Envelope-to: dhosek
> Now, first of all, we need to determine exactly what information
> the \special will need. The following seem obvious:
> - filename of graphic
> - format of graphic (e.g., Tek, PostScript, Xerox 9700 bitmap,
> GIFF, etc.)
>
> What about other information?
> - size
yes, and I'd link this with scaling. I want the piccy to come out 10in
by 4in.
> - orientation
i'd say this was a separate \special:
\begin{rotate}{-45}
\special{file=fred.ps,type=ps,width=4in,height=2in}
\end{rotate}
dont forget the PS people would appreciate the possibility of putting
in the bounding box info.
> Not to mention syntax.
key=value pairs separated by commas seems so universal you might as
well stick with it.
Beebe's scheme seems to comprehensive, i'd stick with that!
=========================================================================
Date: Thu, 17 May 90 11:05:39 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: jsg@ARBORTEXT.COM
Subject: Re: My vote
> I.C.2. The driver should not be expected to exceed the limits of the
> output device.
This is rather loose; one of the limits of the LaserJet, for instance, is
that you can only have 228 chars in a font (or some such); alternative
approaches may overcome various natural limits of devices.
We certainly should try to exceed the limits of printers when we write
drivers, but I'm saying that for ``minimal'' drivers we shouldn't
expect too much work in this direction.
> I.E.1. ``Accurately track'' is ambiguous. Also, pixel widths are
> neither available nor relevant when dealing with PostScript or other
> scalable kinds of fonts. The standard must accept drivers that handle
> such fonts.
I claim that pixel widths should be used when dealing with PostScript fonts;
just because PostScript doesn't set its fonts consistently on a page doesn't
mean that when the fonts are used with TeX they shouldn't be. It's easy to
define pixel widths for PostScript fonts . . . remember that PostScript and
its font cache does do pixel positioning and no subpixel positioning . . .
If I try to print the word ``Tom'' using an Adobe font on a PostScript
printer with the command ``(Tom) show'' the position of the ``m'' will
be (metaphorically) its rounded DVI position. The PostScript
interpreter will not take into account the rounded widths of the
preceding characters. In addition, different PostScript interpreters
will round differently and the position of the ``m'' will vary by a
pixel from one printer to another. Under these conditions it's
meaningless for a driver to try to keep track of pixel positions.
It's a different story with bitmapped fonts like Computer Modern,
which carefully translated can benefit from pixel positioning.
=========================================================================
Date: Thu, 17 May 90 11:51:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Global landscape \special ing
One other thing that I should point out about the "box delimited" specials: one
can apply them to an entire page with little difficulty. The following would do
landscape printing:
\voffset=\paperheight \advance\voffset-2in % Origin is now 1inx1in from LLcorner
\dimen0=90pt
And then before any output on each page, pop in
\special{X_rotate \the\dimen0}
-dh
=========================================================================
Date: Fri, 18 May 90 21:17:28 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA10846@ARTHUR.CS.PURDUE.EDU>; FRI,
18 MAY 90 21:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
I remember a message from someone of ArborTeX stating
that it would be NOT possible to know anything precise
about the positioning of a PostScript printer.
This is INCORRECT. You can trick the printer to follow
the positioning computations of the driver precisely,
IF
you know the resolution of the device
send integer positions only
round all font widths to the nearest integer pixel value.
THEN you are only dealing with integer positions and so is the printer.
StvB
=========================================================================
Date: Sat, 19 May 90 00:04:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: FWD: \special in DVI files
Below is a note sent to the TeX implementors list which raises an issue worth
noting. I'll be sending a copy of my response to the list shortly.
Date: 18 May 1990, 15:55:23 GMT
From: Peter Breitenlohner (089) 32308-412 PEB at DM0MPI11
To: Barbara Beeton BNB at MATH.AMS
Barbara,
During my work on DVIcopy (which is nearly finished) I came across a
question concerning the DVI format. Maybe you know who can answer this:
The definition of the DVI format (in TeX, in DVItype, and in GFtoDVI)
specifies that a special (|xxx|) command can appear not only inside a
page, but also before the first |bop|, or between an |eop| and the next
|bop|. The definition does not specify whether an |xxx| can appear
between the last |eop| and the |post|, maybe yes, maybe no???
All this makes sense for specials which might, e.g., specify that all
following pages should be printed in portrait or landscape format, or
should be printed on a special paper, etc.
TeX certainly writes specials only inside a page, but what about other
programs. And what about DVIcopy when copying only selected pages:
should specials from pages which are skipped be written to the output
DVI file or not???
To make things more confusing, DVItype specifies that specials may occur
outside a page, but given such a DVI file DVItype will complain that
the DVI command is not a bop????
I doubt that many existing DVI drivers (if any) can handle specials
occuring outside a page.
I would appreciate any clarification on this subject
With best regards Peter Breitenlohner.
-------
=========================================================================
Date: Sat, 19 May 90 00:14:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Re: \special after EOP
>The definition of the DVI format (in TeX, in DVItype, and in GFtoDVI)
>specifies that a special (|xxx|) command can appear not only inside a
>page, but also before the first |bop|, or between an |eop| and the next
>|bop|. The definition does not specify whether an |xxx| can appear
>between the last |eop| and the |post|, maybe yes, maybe no???
>To make things more confusing, DVItype specifies that specials may occur
>outside a page, but given such a DVI file DVItype will complain that
>the DVI command is not a bop????
I would say that there is a bug in DVItype since we have the fabled conflict
between documentation and code. The only real solution is to have DEK decide
which he wants to change (my recommendation is on the documentation). Barbara,
could you forward this information to him.
The current status on the situation of these \special commands is (1) no
DVI-writing program generates them (the only ones that I know of are GFtoDVI and
TeX (and variants)) and (2) no DVI-reading program accepts them (since all are,
in theory, DVItype derivatives).
-dh
=========================================================================
Date: Sat, 19 May 90 00:39:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Global special syntax and placement
We need to resolve the global \special syntax issue. There are several
alternatives that have been posed:
(1) On the first page, preceded by the tag global: e.g.,
\special{global: rotate 5898240} %5898240=90*65536
PROS: Easy to implement from a TeX point of view.
CONS: Requires scanning the whole first page for specials. However, this code
is not too difficult to write and will be necessary if we allow a
special affecting a page to appear anywhere on that page.
(2) On the first page, delimited by some pair of specials:
\special{beginglobals}
\special{rotate 5898240}
\special{endglobals}
PROS: easy for driver to know when to stop looking for globals
CONS: harder to implement than above syntax from TeX side plus the bulk of
cons for (1)
(3) On a page containing no other material
a. With the first special marking that page as a global specials page.
b. With that page marked by having a special page number.
COMMENTS: easy to parse from a DVI standpoint, however, one must know when
the last global has occurred or the document has begun which can be
difficult to implement under LaTeX. Also, the extra page can look ugly.
Discussion on this?
-dh
=========================================================================
Date: Sat, 19 May 90 03:11:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: TUG meeting attendence
Well, time for my annual "who's going to the meeting?" message.
Incidentally, we have a half hour block reserved for us this year
in a panel discussion type situation; I and a few of the voting
members (any volunteers?) will be up in front of the committee
presenting everything that we've officially voted on and
addressing any issues that come up.
-dh
=========================================================================
Date: Sat, 19 May 90 15:19:28 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Bart Childs <BART@CS.BITNET>
Subject: Re: TUG meeting attendence
Bart Childs will be there and volunteers if needed.
=========================================================================
Date: Sat, 19 May 90 16:16:58 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA21054@ARTHUR.CS.PURDUE.EDU>; SAT,
19 MAY 90 07:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
Even though I decided to not participate any further
in these discussions, I would like to see the result
of this published somewhere. I would like to check
my driver and dvi2dvi program whether it does the
correct thing or not.
Thanks.
StvB
=========================================================================
Date: Sat, 19 May 90 16:17:10 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA21070@ARTHUR.CS.PURDUE.EDU>; SAT,
19 MAY 90 07:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
I will be at the meeting.
StvB
=========================================================================
Date: Sat, 19 May 90 14:53:03 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: "Tomas G. Rokicki" <rokicki@NEON.STANFORD.EDU>
Subject: TUG meeting attendence
In-Reply-To: Don Hosek's message of Sat,
19 May 90 03:11:00 PDT <9005191103.AA05356@Sunburn.Stanford.EDU>
I'll be there . . .
=========================================================================
Date: Mon, 21 May 90 00:45:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Re: Publication of standards
Here's my plan of attack:
We will have something at Texas A&M outlining the standard. This will be a
DRAFT. Even if every single subscriber to this list thinks that it's perfect (an
unlikely occurrence in itself), the main point of presenting the draft at Texas
will be to get wider input and find out if we've missed anything or done
something really stupid, etc.
After the meeting we will continue to hammer away at the standard so that when
the deadline for TUGboat 11#3 rolls around, we'll be able to grab a big chunk of
it for ourselves (I'll warn Barbara at the meeting--we should have some idea of
how much space we'll want then). I'll also make arrangements for the standards
documents to be made available from TUG, the Aston archive, the
ymir.claremont.edu archive (mine), and Jon Radel.
-dh
=========================================================================
Date: Mon, 21 May 90 09:51:09 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: DAVID@PENNDRLS.BITNET
Subject: graphics inclusion specials.
Don Hosek suggested that a graphics inclusion special required a
filename and a graphics format as minimum information. Since not all
devices can support all formats, this makes a DVI file that does
graphics inclusion device specific. Someone reported a method for doing
device independent graphics file inclusion by converting the graphics
file to a set of character bitmaps. I would like to suggest another
approach. The essence of the approach is to make 'graphics format' an
optional piece of information.
All of our drivers recognize the special command "ips filename" ('ips'
stands for 'imbed page segment' and is borrowed from our first driver
that could do file inclusions: the IBM 4250 driver). When a driver
encounters this special, it looks for a file whose identifier is derived
from the specified file name and a token derived from the target device
type. Our major graphics packages can generate graphics files in a
format suitable for each supported device. If a user generates a
graphics file with the appropriate name and format for each device, then
he can output the same DVI file on any of the supported devices.
This scheme is directly analogous to the existence of device-specific
versions of each font used in a document. I would like to see this
scheme included in the specials standard. I suggest treating it as a
default: if no format is specified in a file inclusion special,
the driver should assume a default based on the target device.
And like font file identifiers, the derivation of the graphics file
identifier from the specified (one to eight character?) name should
be configurable.
-- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)
=========================================================================
Date: Mon, 21 May 90 11:32:45 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: UCIR001%FRORS31.BITNET@CUNYVM.CUNY.EDU
Subject: my vote
I agree with Don's proposal. I don't think that it's perfect BUT i
prefer to accept this minimum of requirements today rather than wait
one more year (reading lot of esoteric, indigestible, sometimes
unuseful messages) and obtain a new text with few words changed!
This proposed standard is ACCEPTABLE by everybody and you probably
better accept this ``level 0'' and try (after the TeXas Meeting) to
propose a level 1 than more and more increase the discussions.
(it would be better useful to meet during few days...)
Please be concrete, positive and efficient.
Don, I consider your DRAFT proposal as FINAL for this level 0 and i hope
that many people will agree.
Bernard GAULLE
=========================================================================
Date: Mon, 21 May 90 13:31:49 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: jsg@ARBORTEXT.COM
Subject: Pixel positioning in PostScript
As I pointed out to Tom Rokicki you can do this with bitmapped fonts
(and ArborText does in its drivers), but it doesn't make sense to do
it with true PostScript fonts.
Incidently, even if you use integral coordinates at the device
resolution, different printers still produce different results. It's
dismaying and Adobe has been informed, but they decline to do anything
about it.
From DRIV-L@tamvm1.tamu.edu Fri May 18 22:25:28 1990
Received: by blue.arbortext.com (5.54/ati-3.1)
id AA02771; Fri, 18 May 90 22:15:12 EDT
Message-Id: <9005190215.AA02771@blue.arbortext.com>
Received: from TAMVM1.TAMU.EDU by tamvm1.tamu.edu (IBM VM SMTP R1.2) with BSMTP
id 9164; Fri, 18 May 90 21:17:36 CDT
Received: by TAMVM1 (Mailer R2.03B) id 0627; Fri, 18 May 90 21:17:34 CDT
Date: Fri, 18 May 90 21:17:28 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@tamvm1.tamu.edu>
Sender: The TUG DVI driver standards discussion list <DRIV-L@tamvm1.tamu.edu>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA10846@ARTHUR.CS.PURDUE.EDU>; FRI,
18 MAY 90 21:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@tamvm1.tamu.edu>
To: David Rodgers <dlr@ARBORTEXT.COM>, John Gourlay <jsg@ARBORTEXT.COM>
Status: RO
I remember a message from someone of ArborTeX stating
that it would be NOT possible to know anything precise
about the positioning of a PostScript printer.
This is INCORRECT. You can trick the printer to follow
the positioning computations of the driver precisely,
IF
you know the resolution of the device
send integer positions only
round all font widths to the nearest integer pixel value.
THEN you are only dealing with integer positions and so is the printer.
StvB
=========================================================================
Date: Mon, 21 May 90 17:59:33 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA28183@ARTHUR.CS.PURDUE.EDU>; MON,
21 MAY 90 17:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
Why doens't it make sense with the PostScript fonts?!
Same deal, you download a width vector with integral
widths and you use the same widths in the printer.
StvB
=========================================================================
Date: Tue, 22 May 90 09:42:50 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: jsg@ARBORTEXT.COM
Subject: Pixel widths and PostScript fonts
I guess it boils down to a question of philosophy. Do you use the
fonts as they were designed by Adobe or do you change them to suit
your own design criteria? There's room for both approaches in the
world.
=========================================================================
Date: Tue, 22 May 90 09:01:12 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA11281@ARTHUR.CS.PURDUE.EDU>; TUE,
22 MAY 90 08:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
I disagree because making the witdhs fit, you follow the rules
of dvitype precisely and that's the drum all other drivers
march to. And PostScript will not round that much different.
And by forcing the widths to be integers, you finally know
what's going to happen in your printer precisely.
I also claim that ArborText simply used the first solution
to the problem for simplicity and historical reasons. Not forcing
integer widths makes for an easier driver, less code to write.
In other words: did you guys ever consider and experiment with the
other approach?!
StvB
=========================================================================
Date: Tue, 22 May 90 09:45:32 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: XITIJSCH@DDATHD21.BITNET
Subject: Re: Pixel widths and PostScript
I fully agree with Stephans approach of using pixel widths in PS fonts,
too. As he wrote, that's the way it's done in the TeX/DVI world and
there are enough good reasons for it. Please remember that in very
well designed fonts pixel and TFM widths may even not be the same!
(which is, of course, impossible for our usage of PS fonts).
Joachim
=========================================================================
Date: Tue, 22 May 90 10:03:29 LCL
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Comments: <Parser> W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID
<AA13239@ARTHUR.CS.PURDUE.EDU>; TUE,
22 MAY 90 09:". Rest of header flushed.
Comments: <Parser> E: "From:"/"Sender:" field is missing.
From: Undetermined origin c/o Postmaster <POSTMASTER@TAMVM1.BITNET>
There are disadvantages with my approach of rounding
also PostScript fonts which are:
1. Increased complexity of the code (well, I would
not call it a disadvantage: it's laziness)
2. Increased length of PostScript code (again: you
want to do it right, then you need to do it
that way; it's not that much after all, one
width vector per PostScript font).
3. Resolution independence is lost (again, there is
nothing like a free lunch: you need to
generate a new PostScript file when you
go from a PostScript laser printer to a
PostScript typesetter). So that's ONCE
in every document's like time (if at all).
Stephan v. Bechtolsheim
Computer Sciences Department svb@cs.purdue.edu
Computer Science Building (317) 494 7802
Purdue University FAX: (317) 494 0739
West Lafayette, IN 47907
=========================================================================
Date: Thu, 24 May 90 21:12:00 PDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Don Hosek <DHOSEK@HMCVAX.BITNET>
Subject: Re: Old drivers
[In a note to me, Joachim listed as one of the reasons for his reorganization]
> (2) it deletes stuff which should not belong to ``real basics''
> because it would have the consequence that 90% of the existing
> drivers -- which have proven to work saticfactory -- do not
> correspond to the standard!
This was intentional. Let's take for example the case of Nelson Beebe's drivers,
which you cited in your long message to driv-l; you pointed out that the old
version of his drivers, since it didn't allow reconfiguring where its files
would be without recompilation, would not conform. Actually it wouldn't conform
on several other points as well.
Level 0 should _not_ be defined as interpretting the DVI file correctly and
nothing more. A level 0 driver should be able to take any DVI file I create with
32-bit standard TeX, and, aside from the specials, print it without difficulty.
This means that a document which uses, for example, ancient Greek (and I, for
one, _do_ use Sylvio Levy's Greek font fairly regularly), should be printable. A
document which contains cminch at magstep5 should be printable. A catalog of
typefaces available on the system should be printable. Documents containing
PicTeX or LaTeX picture mode grahpics should be printable.
Incidentally, I think that a perusal through logs of any TeX discussion group
will show that most people do _not_ find 90% of the drivers satisfactory.
"Functional", perhaps, but rarely satisfactory.
-dh
=========================================================================
Date: Thu, 24 May 90 21:30:12 -0700
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Pierre MacKay <mackay@CS.WASHINGTON.EDU>
Subject: delayed answers to mail
I am temporarily unable to answer your messages in a timely manner.
If you are interested in getting TeX 3.0 in a normal distribution,
please send your request to
elisabet@max.acs.washington.edu
If you have technical questions about the distribution, or about
compilation etc., forward your message to the same address, and
Elisabeth will relay them to me.
I must ask you please not to overwhelm Elisabeth with messages.
My mail has been averaging 150 messages a week, which is one of the
reasons I must take this slightly drastic step.
Email: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computer Support Center TUG Site Coordinator for
Lewis Hall 35F, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
=========================================================================
Date: Mon, 28 May 90 23:24:06 CDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: Bart Childs <BART@CS.BITNET>
Subject: My Vote and some comments.
I vote yes! Bart Childs
You may cut off the rest but I have the following comments.
There has been a high level of professional response to the
proposal and comments made so far. I was particularly pleased
with the comments of our moderator, Joachim, John Gourlay, Nelson,
Tom Rokicki, and Stephan. I admit to not being sure on the
last few things between Stephan and John on PostScript, but
I feel I will in time.
I will comment on the draft numbers item by item when I feel
there is some change needed. I generally agree with the details
stated by Tom and John and so some of this is repitious and some
is slightly changed from theirs. I agree with the generality
of several things of interpretation should be in a separate document
rather than the bare bones statement of the standard. My comments
suffer in the same manner.
I.A. Why not tie this to the current TeX? Level 1 may go further
into the land of possible DVI files.
B.1. Simply: Drivers must handle fonts with 256 characters.
2. Require cminch at magnification 1200. Many of the most
popular printers can't handle this as fonts!
3. OK but some printers can't handle this even if the driver can.
See my comment at the end ###1.
E.1. I recall Pierre saying that DEK said that the driver should
use the font file over the TFM file. If a driver/printer has
preloaded fonts, it should use the TFM.
2. The wording is wrong. The driver must carry TeX's resolution
and range in dimensions.
3. If the out of range happens, then the driver must emit a loud
warning! All other possible actions should be optional.
F.1. (merged with F.2) Level 0 should require 64 fonts or less!
That number greatly exceeds any quality document's requirements.
``Quality documents seldom have more than 5 or 6 (textual) fonts''
I will furnish the exact quote and source upon request.
G. Level 0 should have landscape as a minimum. All specials not
supported should be logged to the file with the loud warnings
(see I.E.3) and (say up to) 80 characters of the contents of the
special (hex if binary).
II. Make it functional. Allow searchlist, preloading, and interactive
use. Some drivers ``preload'' the big 16 (or other sets) like TeX
can. Shouldn't most or all PostScript drivers do the same if we
can resolve the placement problems?
III. A directory of font files should contain (directories of) font
files for a given device or resolution+marking technology.
PK_B300 could contain PK files for Canon engines and PK_W300
could be for Xerox ... Further identification (whether directory
or extension) should be logical like:
a. magnification (hopefully without 5*) like 100, 1095 ... and
825 would allow shrinkage.
b. magstep 0, h, 1, ... with overflow to the above?
This helps systems with restricted name lengths.
III.B.1 Magstep 9 is needed for slides.
III.C Add output a loud warning!!!
###1. When the implementation cannot handle a part of the standard,
the shortcomings should be documented with some statement of
the cause (this might help us in getting better printers).
Level 0 needs some more things. John suggested some. I find the
most pressing to be 1) positioning on the page, subsetting the
file (like printing one page or a sequence of them), duplex offsets,
and printing in DVI order or logical page number order.
John Gourlay's comment about I.G may be due to the way Arbortext
puts device dependent graphic inclusions in. I will lobby long and
hard for device INdependent graphics inclusion.
Don Hosek suggested X_rotate for landscape. That complicated mess
should never be confused with that. Many clerks and secretaries
have to do landscape and they understand it. If a local implementation
wants to do it by using the more general form, then fine but hide
it from the user.
%%%%%%%%%%%%% about my earlier comments
I read my submission again after reading Joachim's reply.
I apologize for my incompleteness and sarcastic nature.
I have now read notes from Don Hosek and John Gourlay
and Nelson Beebe's again.
We need the standard to make things better for the
long run with reasonable limitations based upon the
reality of existing installations and characteristics
of compilers, operating systems, and other real-world
considerations. Thus, most of our ``elements of the
standards'' should be functional.
One of our elements we have been discussing is the accessing
of font files (files containing pixels in some format).
How about something like:
Requirement: Users must be able to access nnn files
containing pixels. Documentation or a utility shall
be furnished that will explain how to determine the
various magnifications of each font that is available.
There should be a superior directory (or library element)
that identifies the collection to follow: PK_W300 could
contain fonts suitable for the write white 300 dpi
engines by Xerox and Ricoh. Installations may wish
to tune their local MF parameters and indicate directories
like X4050 and X9700 for different sets for Xerox 4050
and 9700 printers, respectively. Files could have an
extension of 0pk, 300gf, or ... to indicate no magnification.
If a compact notation like `0pk' is used, allowances must
(should) be made to enable non-standard magnifications
(at least at the next level?)
Implementation considerations: The vagaries of operating
systems cause the implementations to vary. Some examples
of differing implememtations include:
1. All font files (not tfms) are in a given directory for a
particular printer. VMS and AOS systems can use a searchlist
to ease the finding of the proper file efficiently.
2. Font files can be in different directories based upon
magnification. (This may aid performance in small systems
but it is more difficult to determine the available sizes).
A utility, script, or ... should be furnished to determine
the available sizes of fonts with the use of wildcards.
3. A flat short-named file structure may require names that
don't look like others. (On CTSS the total file name is
eight characters, including the period and extension.
Oh yeah, it is case sensitive and it is not really an extension.
Joachim, that is what I call a flat file system. I really
don't prefer one either.)
Here, cmssbx10.tfm becomes CSSBXA.T in the implementation I did.
On leaving directory organization to the locals. I guess that is OK.
However, we find that 30 or 40 font files will satisfy the needs of
nearly 99% of the users. Some people have had some beautiful schemes
of a preprocessor that sees which fonts are needed and then copying
them to the fonts directory if they aren't there. Thus, they free
many megabytes of disk on their personal computers.
The thing that is important is for the casual or lesser user of TeX
to be able to be functional and find their limits, easily.
On valid_mags. My scheme has problems with ``nonstandard'' sizes.
However, there are few ``quality'' arguments that can justify them.
The biggest problem is probably with magnifications less than 1000.
When I said ``output the position'' ... When a font is substituted
for another of nearly the same size, before each character is output,
the printer should be ``positioned'' where the correct character
should have been. The width of the previous (possible substituted)
character should not be assumed to have put us in the right position.
This is similar to the checking for accumulated roundoff between
DVI positions and pixel positions. Joachim, I apologize for these
not being clear.
I hope to see you here next month.
Bart Childs
=========================================================================
Date: Wed, 30 May 90 14:37:27 EDT
Reply-To: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
Sender: The TUG DVI driver standards discussion list <DRIV-L@TAMVM1>
From: yale!LRW.COM!leichter%harvard@HARVUNXW.BITNET
Subject: Device-independent graphics \special's
There's been a lot of discussion on this list of how graphics inclusion
specials should be defined. The real problem here is that most of the discus-
sion centers on how particular page description languages view the problem
(particularly, how Postcript does things), rather than on the actual primi-
tives that people need. It's important to support the special features of
various printers, but it would also be nice to support things portably across
a variety of printer platforms.
Notice, for example, that TeX already defines a simple graphics interface,
namely, the rule. A rule is not a character, and there's a whole special
mechanism for setting rules - though they could easily have been handled by
using a font of small rectangles, as LaTeX picture mode builds diagonal lines
out of small diagonal segments. It wasn't, because rules are important, are a
common typographical device, and won't come out right unless handled with
care.
There's a simple extension to the TeX notion of a rule that most modern
printers could handle with no trouble: The gray rule. A gray rule is simply
a rule printed at some density other than 100% black. Postscript printers can
certainly produce gray rules, and every HP LaserJet since the LaserJet + -
that is, every LaserJet that supports rules as a primitive at all - also
supports gray rules.
As an illustration of what can be done, I've added the following \special's to
Nelson Beebe's DVIJEP (the following is extracted from a comment in the code):
HPLJ rule_pattern <n>
HPLJ rule_type <n>
The HPLJ rule_pattern command selects the rule pattern id. This id is
retained by the printer until changed reset at the end of the job.
The HPLJ rule_type sets the type of rule the next rule command will draw.
This is a one-shot setting; the value will be reset to 0 (solid black
rule) after the next rule is drawn.
For gray rules, the rule_pattern value is the integer percentage of black in
the pattern to be printed. The printer cannot, of course, not really image
any possible gray level - it chooses the closest of (on a LaserJet+) 9
possible levels, including white and black.
The rule_type value is either 0 (normal black rule, rule_pattern is ignored)
or 2 (gray rule). It happens that the printer retains the rule_pattern value
you send it, but a printer driver could easily re-send it if necessary.
I defined rule_type to apply only to the next following rule. I'll probably
add a "rule_type_lock" command that will remain in effect until reset.
When I defined this stuff, I made it "HPLJ specific". But there's really no
reason for that - the interface makes sense on any printer. Even printers
that can't print gray rules can just "round to black", or fake it with a bit-
map if they wish.
The LaserJet actually includes another alternative: The rule_type can be 3,
in which case the rule_pattern chooses one of (in the LaserJet+) 6 built-in
patterns, such as horizontal lines, vertical lines, and so on. This partic-
ular interface isn't suitable for portable use, though one could choose names
for a set of common patterns and specify those. As in the case of gray scale,
the driver printer would only guarantee some reasonable approximation.
Note that I did NOT add a special to DRAW a gray rule: TeX's \hrule and
\vrule already provide a good interface, and in fact it would be a royal
pain to calculate sizes and such and insert them into the specials. I think
this is important: Retain as much of the interface as you can.
Postscript provides many examples of transformations that could be applied to
stuff produced by TeX. Some - like rotations - are useful but can get tricky
since then TeX no longer really knows where the characters it is writing will
be positioned. Others - shadowing of characters, for example - are quite
tame.
There are not all THAT many different things one does with type in the vast
majority of cases. I suggest that it would be very worthwhile to come up
with "standard specials" to cover as many of those as possible.
-- Jerry