=========================================================================
Date: Fri, 3 Jan 1992 15:51:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Area on font names in DVI files
What is current practice regarding explicitly given areas on font
names in DVI files? I have some vague memories of this being
discussed, but am certain that it never made it into the level 0
standard.
-dh
=========================================================================
Date: Fri, 3 Jan 1992 16:01:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Level 0 standard
It's been sitting around for over a year now... Here's what I'd
like to decree:
- The standard as it stands as of January 31, 1992 at 12:00
noon Pacific standard time will be submitted for publication
in TUGboat as official. In February I will submit copies to
all driver suppliers listed in the TUG tables so that they
may, if they choose, inform me of their compliance (or
non-compliance) to the standard for future publications of
the driver list.
Any pending amendments at that time which have over fifty
percent of votes received will be applied to the standard
before distribution.
- I will reconsider this if I receive notice from greater than
33% of the voting members of the committee that they would
prefer more time.
- Further changes to the standard will be considered, BUT,
cannot be made official until the January of the following
year (i.e., a change approved in July 1992 will not become
an official part of the standard until January 1993).
If you lack a current copy of the standard, contact Joachim Scrod
<schrod@iti.informatik.th-darmstadt.de> for a current copy.
-dh
=========================================================================
Date: Fri, 3 Jan 1992 16:10:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Immediate goals
These are the things that I would like to see us put our
attention to in 1992:
- Establishment of a standard syntax for \special commands. Note
that this has nothing to do with what commands should be
supported, merely their syntax. I believe Nelson has written
up something on these lines, but I've never seen it. Could
we have it posted or at least find out where to get it?
- Once the syntax is established, I'd like to see us provide a
standard for graphics inclusion. This should be a multi-tiered
standard building from simple inclusions of printer-readable
material to sophisticated abilities like GIF inclusion, PS
interpretation etc. (Yes, there actually are drivers that
provide these facilities). Tom Rokicki will doubtless be
willing to offer some expertise here.
- Perhaps we should officially adopt Karl Berry's naming scheme
for external fonts? A few other font use points, perhaps in
separate standards also need standards.
- Color printers are becoming cheaper, better and more common.
Color will have to be addressed somewhere along the line.
In a separate message, I'll outline what I'd like to see as the
structure of the standards as a whole.
-dh
=========================================================================
Date: Fri, 3 Jan 1992 16:36:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Standards structure
Here's how I envision the DVI driver standards being structured:
The Level 0 standard will be guidelines for basic functionality
as well as containing the specifications for the basic file
formats.
Other areas of standardization will be handled on a
topic-by-topic basis. Standards may be tiered. For example, there
will be a standard on \special syntax which will likely be an
untiered standard (we aren't going to make the syntax
complicated, I hope). On the other hand, a syntax for graphics
inclusion is likely to be tiered according to the requirements
given. To illustrate, driver A might, like Rokicki's dvips handle
simple PS inclusions and so be able to claim Graphics Inclusion
Level 2 for PostScript. Another driver which can do more
sophisticated transformations and other file formats could claim
Graphics Inclusion Level 5 for HPGL and PCX. The DVI driver
listings in TUGboat will include summaries of the features at
each level allowing someone to compare the abilities of the
drivers at a glance. There may need to be parallel tiering for
some aspects of the standards, e.g., vector graphics inclusion
and bitmap graphics inclusion represent two different problems: a
driver could be identified as Level 1/0 if it only handled simple
vector inclusions while another driver which could do
sophisticated vector inclusions as well as simple bitmap
inclusions could be Level 6/1. PLEASE NOTE that this is just a
general impression of the structure and does not necessarily
indicate specific plans for graphics inclusions specials.
What I would like to see is initial drafts of standards developed
by individuals or small groups and submitted almost-complete to
the group at large for review. Initial discussions could possibly
be conducted in subgroups either via listserv (Tom, might it be
possible to get us driv-l-a through driv-l-d for these
discussions?) or via private mailing lists. NOTE that these
subgroups are for discussions to take place before the initial
draft is released. After that point the issues will be taken up
on DRIV-L.
One last discombobulated note on internal structure: I would like
us to follow a modifed version of the ISO outline:
- Informative introduction
- Statement of standard contents
- Expected uses of standard
- Summary of changes to standard since last official release
- References to related standards
- Definitions
- The actual requirements. Note that each point may be followed
by explanatory commentary which must be typographically
distinct.
- Annexes
=========================================================================
Date: Sat, 4 Jan 1992 14:42:35 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Level 0 standard
In-Reply-To: <9201040008.AA08662@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"DonHosek" at Jan 3, 92 4:01 pm
Don Hosek wrote:
>
> It's been sitting around for over a year now... Here's what I'd
> like to decree:
No, for heavens sake!!!
> - The standard as it stands as of January 31, 1992 at 12:00
> noon Pacific standard time will be submitted for publication
> in TUGboat as official.
The standard draft 0.05a as of 02 October 1991 is already submitted
for publication in TUGboat. It's a call for comments of the
membership-at-large. My editorial remarks say that comments may be
sent for only 2 months after TUGboat publication (I want to get rid of
level 0.)
We cannot decide on a standard which was not presented to the
membership-at-large.
> - I will reconsider this if I receive notice from greater than
> 33% of the voting members of the committee that they would
> prefer more time.
I, as the Secretary, would prefer to have more time. [This is my
notice ;-) ]
To tell the background: The draft is in the moment in a form which is
not appropriate for a standard publication. barbara has said she will
send me the ISO guidelines for writing a standard. (well, that's two
months ago, perhaps I should ask her what's happened). The standard
has to be reformulated according to such guidelines.
There will be no changes of contents, but of presentation. My time
schedule does not allow to start with such things immediately. First I
must get out the new MakeIndex which I have already announced in Paris.
Talking about work to do: Anybody likes to write up a rationale for
draft 0? Volunteers are welcome.
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Sat, 4 Jan 1992 14:33:13 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Area on font names in DVI files
In-Reply-To: <9201032358.AA08653@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"DonHosek" at Jan 3, 92 3:51 pm
Don Hosed wrote:
>
> What is current practice regarding explicitly given areas on font
> names in DVI files? I have some vague memories of this being
> discussed, but am certain that it never made it into the level 0
> standard.
I do not remember that it was discussed. It is certainly not in the
standard draft. I would name it implementation-dependant ;-)
--
Joachim
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
=========================================================================
Date: Sat, 4 Jan 1992 14:45:01 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Immediate goals
In-Reply-To: <9201040018.AA08672@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"DonHosek" at Jan 3, 92 4:10 pm
You wrote:
>
> These are the things that I would like to see us put our
> attention to in 1992:
>
> - Establishment of a standard syntax for \special commands. Note
> that this has nothing to do with what commands should be
> supported, merely their syntax. I believe Nelson has written
> up something on these lines, but I've never seen it. Could
> we have it posted or at least find out where to get it?
Of course, it's in the official archive :-)
ftp.th-darmstadt.de:pub/tex/dvi-standard/papers/special-beebe-1.02.tar.Z
Btw, I'm looking for the official documentation of tpic specials for
inclusion in the archive. Anybody has them for me?
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Sat, 4 Jan 1992 10:16:10 MST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: "Nelson H. F. Beebe" <beebe@MATH.UTAH.EDU>
Subject: Documentation and source code on \special support et al
On math.utah.edu in ~ftp/pub/tex/pub/paper, I have the following files:
-rw-r--r-- 1 beebe 12179 Dec 4 19:35 epsf.tex
-rw-r--r-- 1 beebe 714 Jan 4 10:10 index
-rw-r--r-- 1 beebe 1225 Jan 4 10:03 paper.tar-lst
-rw-r--r-- 1 beebe 79061 Aug 5 14:08 paper.tar.z
-rw-r--r-- 1 beebe 66536 Oct 24 18:21 special.dvi
-rw-r--r-- 1 beebe 882 Jan 4 10:04 special.tar-lst
-rw-r--r-- 1 beebe 107155 Aug 5 14:11 special.tar.z
-rw-r--r-- 1 beebe 729237 Dec 13 10:51 tex-epsf.dvi-alw-pp1-25
-rw-r--r-- 1 beebe 526786 Dec 13 10:52 tex-epsf.dvi-alw-pp26-50
Here is what the index file says:
>> ...
>> epsf.tex Extended macros for PostScript file inclusion
>> in dvips; minor redefinitions make
>> this usable with dvialw 3.0.
>>
>> paper.tar.z Source code, Makefile, and test data for
>> DVI 3.0 \special, paper, and command-line
>> parsing support as described in TUGboat
>> article draft.
>>
>> paper.tar-lst Contents listing of paper.tar.z
>>
>> special.tar.z Draft of TUGboat article on \special
>> support and paper specification.
>>
>> special.tar-lst Contents listing of special.tar.z
>>
>> tex-epsf.dvi-alw-pp1-25 PostScript file for ``TeX and
>> Encapsulated PostScript'' article
>> (pages 1--25)
>>
>> tex-epsf.dvi-alw-pp26-50 PostScript file for ``TeX and
>> Encapsulated PostScript'' article
>> (pages 26--50)
>> ...
The ``TeX and Encapsulated PostScript'' paper is an early DRAFT that I
prepared just before Christmas for a talk on the subject that I'll be
giving locally. I think you may find it interesting. It is included
only in PostScript form, because the many figures presented there
require features of dvialw 3.0, which is not yet released in source
form. It is split into two parts because our Apple LaserWriter II
cannot print it in one pass.
========================================================================
Nelson H.F. Beebe
Center for Scientific Computing
Department of Mathematics
220 South Physics Building
University of Utah
Salt Lake City, UT 84112
USA
Tel: (801) 581-5254
FAX: (801) 581-4148
Internet: beebe@math.utah.edu
========================================================================
=========================================================================
Date: Sat, 4 Jan 1992 12:14:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Re: Level 0 standard
Joachim Wrote
-Don Hosek wrote:
->
-> It's been sitting around for over a year now... Here's what I'd
-> like to decree:
-No, for heavens sake!!!
-> - The standard as it stands as of January 31, 1992 at 12:00
-> noon Pacific standard time will be submitted for publication
-> in TUGboat as official.
-The standard draft 0.05a as of 02 October 1991 is already submitted
-for publication in TUGboat. It's a call for comments of the
-membership-at-large. My editorial remarks say that comments may be
-sent for only 2 months after TUGboat publication (I want to get rid of
-level 0.)
I assume you mean version 0.
-We cannot decide on a standard which was not presented to the
-membership-at-large.
-> - I will reconsider this if I receive notice from greater than
-> 33% of the voting members of the committee that they would
-> prefer more time.
-I, as the Secretary, would prefer to have more time. [This is my
-notice ;-) ]
Actually, your justification is more than reasonable. I withdraw
the January 31 deadline and replace it with a June 31 deadline.
This will give ample time to provide copies at the TUG meeting in
Portland (among other things). One important note: I feel that it
is very important that the standard be "officially" published for
the TUG meeting in Portland so I'll let the deadline slide
possibly as late as July 15 because of publication delays, but no
later. If publication delays cause TUGboat 12#1 to come out after
May 1st, we'll possibly release a second version (as necessary)
on January 31, 1993.
-To tell the background: The draft is in the moment in a form which is
-not appropriate for a standard publication. barbara has said she will
-send me the ISO guidelines for writing a standard. (well, that's two
-months ago, perhaps I should ask her what's happened). The standard
-has to be reformulated according to such guidelines.
-There will be no changes of contents, but of presentation. My time
-schedule does not allow to start with such things immediately. First I
-must get out the new MakeIndex which I have already announced in Paris.
As I indicated in one of the previous batch of notes, this
revision of the presentation is desirable, but I am not
particularly willing to unduly hold up publication to accomplish
it. I have the outline of the standards from Goldfarb's SGML
Handbook and will check the local university library for more
info and if I can find it, I'll take on the task maybe. Please
note that unless we intend to submit our standards to the ISO, I
do not think that it's necessary to take the ISO guidelines as
gospel truth.
-Talking about work to do: Anybody likes to write up a rationale for
-draft 0? Volunteers are welcome.
-dh
=========================================================================
Date: Mon, 6 Jan 1992 09:13:54 EDT
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Gaulle Bernard <UCIR001@FRORS12.BITNET>
Subject: Re: Immediate goals
In-Reply-To: Message of Fri,
3 Jan 1992 16:10:00 PST from <DHOSEK@HMCVAX.CLAREMONT.EDU>
Very pleased to read that "our goals" are becoming "immediate goals".
I applaud to these goals (though they were expressed likely in the same
words during the past and that nothing really happened...) and strongly
agree they require "immediate boarding".
I think i read Nelson's proposal for \special, hum| let's say one year ago.
I say again (look in the logs) his proposal is EXCELLENT. As far as i
remember, some code is available too. I dispaired that no discussion
take place on his proposal. Starting a new year with very good intents
it's the time for this; please let's go.
Thanks for people discussing efficiently on this list. Best wishes.
--bg
=========================================================================
Date: Mon, 6 Jan 1992 13:14:13 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Level 0 standard
In-Reply-To: Don Hosek's message of Sat,
4 Jan 1992 12:14:00 PST <9201042016.AA11997@cs.umb.edu>
Don: Please note that unless we intend to submit our standards to the
ISO, I do not think that it's necessary to take the ISO guidelines
as gospel truth.
I agree absolutely. (I don't see any point in making this an ISO
standard, either.) I don't understand why the form of the presentation
is important. I can understand that the current output as a TUGboat may
not be the best, but it's a big leap from there to fulfilling ISO's or
anyone else's requirements.
Still, I suppose this is essentially the secretary's decision to make --
it's your time, Joachim :-)
Talking about work to do: Anybody likes to write up a rationale for
draft 0? Volunteers are welcome.
The current output has some rationale stuff in it. Is there any big
reason to have the rationale as a separate document?
More messages follow on other topics. (Is it the consensus that
separate topics in separate messages is easier to deal with?)
=========================================================================
Date: Mon, 6 Jan 1992 13:25:53 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Immediate goals
In-Reply-To: Don Hosek's message of Fri,
3 Jan 1992 16:10:00 PST <9201040014.AA00798@cs.umb.edu>
(Don) Perhaps we should officially adopt Karl Berry's naming scheme
for external fonts? A few other font use points, perhaps in
separate standards also need standards.
I don't think my naming scheme is suitable for standardization. Two
reasons:
First, it is updated periodically for new typefaces etc.; of
course, the underlying scheme could be a standard, but I'm not sure this
is of much benefit.
And also, second, that naming scheme is a real mess, because of the
8-character length limitation. (Specifically, ``variant'' includes
scripts like `Greek' and encoding schemes like `expert' as well real
typeface variation, like italic.) I think it's too kludgy to
standardize.
What other font-related things did you have in mind?
karl@cs.umb.edu
=========================================================================
Date: Mon, 6 Jan 1992 13:43:03 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: proposed amendment to level 0 std
(The latest output I have is draft 0.05.)
(Forgive me if there is some procedure to be followed for proposing
amendments; I'm just blundering ahead.)
In section 2.6.2, the standard says:
For a vertical movement of y DVI units, vv is set similarly except
that vv is set to vv + pixel_round (y) if -0.8quad < y < 0.8quad ...
I think using quad for vertical dimensions is conceptually wrong, and
therefore propose that `quad' be changed to `ex'. Since the draft I
have doesn't explain that quad and space_shrink are fontdimens (I
consider that editorial, and sent it to jsch separately), there is no
other change to explain what ex is.
Also, for my own information I'd like to know the relationship between
DEK, us, and the font-format appendices. I sent some editorial changes
to jsch in them a while back, and his reply -- correct me if I'm wrong
here, Joachim -- was that DEK controlled the content of those.
I certainly have no desire to substantively change what, say, DVI files
are. But I think there is much language that is, well, inappropriate
for a standard. (I appreciate DEK's humor as much as anyone, but a
standards document isn't a personal book...) For example, the
description of set4 reads:
Same as set1, except that c is four bytes long, possibly even
negative. Imagine that.
I would change this to something dishwater-dull like:
Same as set1, except that c is four bytes long, and signed.
Opinions?
=========================================================================
Date: Mon, 6 Jan 1992 19:51:42 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Level 0 standard
In-Reply-To: <9201061821.AA11155@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"KarlBerry" at Jan 6, 92 1:14 pm
You wrote:
>
> Don: Please note that unless we intend to submit our standards to the
> ISO, I do not think that it's necessary to take the ISO guidelines
> as gospel truth.
> I agree absolutely. (I don't see any point in making this an ISO
> standard, either.) I don't understand why the form of the presentation
> is important. I can understand that the current output as a TUGboat may
> not be the best, but it's a big leap from there to fulfilling ISO's or
> anyone else's requirements.
The output is not my problem. The wording is my problem. The draft is
still very unprecise. And the ISO guidelines should have guidelines in
making this better. (I don't care for their typography, I meant
structure!)
> Talking about work to do: Anybody likes to write up a rationale for
> draft 0? Volunteers are welcome.
> The current output has some rationale stuff in it. Is there any big
> reason to have the rationale as a separate document?
What's a separate document? I want to have it in one file. I will
be able to produce three documents from this file: (1) the `core'
standard, (2) the rationale, (3) the standard together with the
rationale. The first document is the definitive one. It's the one we
vote on.
Remember: A rationale explains many of the decisions and discusses a
number of subtle points. (To cite an example: ``[The Rationale] is not
part of ANSI Standard X3.159-1989, but is included for information
only.'')
But this is not the work a volunteer is searched for. I'm happy to
receive a rational which I will incorporate myself...
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Mon, 6 Jan 1992 14:01:39 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Level 0 standard
In-Reply-To: Joachim Schrod's message of Mon,
6 Jan 1992 19:51:42 MEZ <9201061854.AA10917@cs.umb.edu>
Sorry, I misunderstood; I thought the ISO standards were about
formatting, not content.
I agree, the current draft is imprecise in many places. Shall we just
attack them one by one?
I meant a separate document in the sense of someone printing would end
up with two different documents. What you suggest is fine (I
don't see any need for anything except (3), the std together with the
rationale, but whatever).
I don't mean to argue the need for a rationale. I think the rationale
is just as important as the standard. I'm not sure any volunteer can
reconstruct this, except by reading through the archives.
karl@cs.umb.edu
=========================================================================
Date: Mon, 6 Jan 1992 20:43:52 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Level 0 standard
In-Reply-To: <9201061938.AA11437@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"KarlBerry" at Jan 6, 92 2:01 pm
You wrote:
>
> I don't mean to argue the need for a rationale. I think the rationale
> is just as important as the standard. I'm not sure any volunteer can
> reconstruct this, except by reading through the archives.
That's it precisely. (I've done this for one year to produce the
report for the TUG Board, so it's not impossible. Just a few MB ;-)
--
Joachim
=========================================================================
Date: Mon, 6 Jan 1992 11:29:31 -0800
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Pierre MacKay <mackay@CS.WASHINGTON.EDU>
Subject: Level 0 standard
In-Reply-To: Karl Berry's message of Mon,
6 Jan 1992 13:14:13 EST
<9201061820.AA07134@june.cs.washington.edu>
It would do no harm to have TeX in some way represented within
the ISO system, but remember that *we* cannot submit anything to
ISO. We will have to find a sponsor through ANSI or some other
national standards organization. Unless ISO has changed a lot
lately, they simply will not listen to any suggestions that come
from outside the national standards organization.
Email concerned with UnixTeX distribution software should be sent primarily
to: elisabet@max.u.washington.edu Elizabeth Tachikawa
otherwise to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computing Support Center TUG Site Coordinator for
Thomson Hall, Mail Stop DR-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
=========================================================================
Date: Mon, 6 Jan 1992 14:54:49 -0800
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
Subject: Area on font names in DVI files
In-Reply-To: Don Hosek's message of Fri,
3 Jan 1992 15:51:00 PST <9201032354.AA17899@orion.arc.nasa.gov>
You write:
> What is current practice regarding explicitly given areas on font
^^^^^^^^^^^^^^^^^^^^^^
> names in DVI files?
What does this mean, exactly? Sorry, but I can't be sure what you mean.
-art
=========================================================================
Date: Mon, 6 Jan 1992 15:04:10 -0800
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
Subject: Level 0 standard
In-Reply-To: Don Hosek's message of Fri,
3 Jan 1992 16:01:00 PST <9201040003.AA17984@orion.arc.nasa.gov>
You write:
> - The standard as it stands as of January 31, 1992 at 12:00
By this do you mean the Level-0 standard?
-art
=========================================================================
Date: Mon, 6 Jan 1992 20:58:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Separate messages for separate topics?
Karl asked if we should use separate messages for separate topics.
Yes.
-dh
=========================================================================
Date: Mon, 6 Jan 1992 21:10:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: ISO and the language/structure of the DVI standards
Given Joachim's explanation of his desire for the ISO guidelines,
I think that it's possible to deal with linguistic imprecisions
on a point by point basis. A formal amendment procedure in most
cases shouldn't be necessary, but identifying places where the
language needs to be changed is. As regards outline, I did give
in an earlier posting a slightly modified version of the ISO
outline (the main change I inserted was a section indicating
changes to the standard).
On a related note as regards Karl's qualms about the use of quad,
it is a unit usually identical to the em (as in em-quad)
(although in some CM fonts as well as expanded fonts, an em is
different from a quad as so defined) and is defined to be an
amount of space equal to the design size of the font. Using exes
would require TFM-reading which is not necessary with quads (in
fact, the size of a quad for a given font can be determined
without reading anything more than the DVI file). This
information should appear in the definitions section and in the
rationale.
-dh
=========================================================================
Date: Mon, 6 Jan 1992 21:27:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Re: Area on font names in DVI files
-You write:
-> What is current practice regarding explicitly given areas on font
- ^^^^^^^^^^^^^^^^^^^^^^
-> names in DVI files?
-What does this mean, exactly? Sorry, but I can't be sure what you mean.
'salright.
In TeX, if one specifies a font as, e.g.,
\font\foo=myfonts:bar
the "myfonts:" is stored in the DVI file and an indication is
given which part of the name in the DVI file is area (in this
case "myfonts:" and which is font name ("bar").
-dh
=========================================================================
Date: Mon, 6 Jan 1992 21:31:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Font Issues
-(Don) Perhaps we should officially adopt Karl Berry's naming scheme
- for external fonts? A few other font use points, perhaps in
- separate standards also need standards.
-I don't think my naming scheme is suitable for standardization. Two
-reasons:
-First, it is updated periodically for new typefaces etc.; of
-course, the underlying scheme could be a standard, but I'm not sure this
-is of much benefit.
-And also, second, that naming scheme is a real mess, because of the
-8-character length limitation. (Specifically, ``variant'' includes
-scripts like `Greek' and encoding schemes like `expert' as well real
-typeface variation, like italic.) I think it's too kludgy to
-standardize.
I don't know... even just an official canon of font names would
be useful. There exists a genuine need to have consistent naming
of non-CM fonts, particularly PostScript fonts.
-What other font-related things did you have in mind?
Issues like a font should be accessed in its default encoding
scheme and if remapping is desired, it should be handled through
VF files, perhaps an "official" VFtoTFM (actually, VFtoPL would
be more portable being text-in, text-out), etc.
-dh
=========================================================================
Date: Tue, 7 Jan 1992 15:32:00 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Area on font names in DVI files
In-Reply-To: <9201071425.AA12575@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"Arthur Ogawa" at Jan 6, 92 2:54 pm
You wrote:
>
> You write:
>
> > What is current practice regarding explicitly given areas on font
> ^^^^^^^^^^^^^^^^^^^^^^
> > names in DVI files?
>
> What does this mean, exactly? Sorry, but I can't be sure what you mean.
From the DVI definition:
FONT DEFINITIONS
Font definitions for a given font number k contain further
parameters
c[4] s[4] d[4] a[1] l[1] n[a+l].
[...]
The remaining part of a font definition gives the external name of
the font, which is an ASCII string of length a+l. The number a is
the length of the ``area'' or directory, and l is the length of the
font name itself; the standard local system font area is supposed to
be used when a=0. The n field contains the area in its first a
bytes.
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Tue, 7 Jan 1992 15:54:28 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: ISO and the language/structure of the DVI standards
In-Reply-To: <9201071433.AA12664@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"DonHosek" at Jan 6, 92 9:10 pm
You wrote:
>
> Given Joachim's explanation of his desire for the ISO guidelines,
> I think that it's possible to deal with linguistic imprecisions
> on a point by point basis.
It's also a problem of the structure. Or as barbara wrote it (cited
with permission):
| the organization of iso standards [is] a reasonable model to follow
| in certain respects, most importantly in that the definition of a
| concept occurs in an iso standard exactly once, and any discussion is
| either clearly marked as a note, or is relegated to an "informative"
| annex. this leads to more precision, or at least (if the standard is
| well written) to fewer possibilities for "interpretation" and
| incompatibility. it also helps to make the statement of the rules
| more concise, thus easier to wade through when trying to decide, does
| this product conform or not? this is the real reason to have the
| rationale as a separate document, or at least a separate section, and
| i stand by it.
And I plan to follow this advice. After all, barbara has the most
experience with standard committees of us all. (``Lesser artists
steal, greater artists borrow.'')
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Tue, 7 Jan 1992 09:28:43 -0800
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
Subject: Area on font names in DVI files
In-Reply-To: Don Hosek's message of Mon,
6 Jan 1992 21:27:00 PST <9201070529.AA15227@orion.arc.nasa.gov>
Thanks for the clarification of ``area''. I now remember Knuth's
usage of this term. I have used some TeX implementations where
the area portion of the font name is ignored, which I found
strange.
No telling what a DVI translator should do with this. I too will
be interested to see what current practice is.
-art
=========================================================================
Date: Tue, 7 Jan 1992 12:40:34 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Re: Area on font names in DVI files
I'm afraid that quote from the standard doesn't resolve
Don's question. At least, I can imagine ambiguity:
suppose (in Unix syntax) that someone says
\font\foo = bar/baz
The question is, does one search for `bar/baz' in all directories
of the font search path, or just in the current directory?
=========================================================================
Date: Tue, 7 Jan 1992 18:41:45 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Area on font names in DVI files
In-Reply-To: <9201071733.AA13014@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"Arthur Ogawa" at Jan 7, 92 9:28 am
You wrote:
>
> Thanks for the clarification of ``area''. I now remember Knuth's
> usage of this term. I have used some TeX implementations where
> the area portion of the font name is ignored, which I found
> strange.
>
> No telling what a DVI translator should do with this. I too will
> be interested to see what current practice is.
My driver family uses the area information in the following way:
If the area is given no search is done but it is assumed that the
font must be there. (Usually, fonts are searched in several
directories and along a search path.) This is some kind of ``full
path'' notion like in UNIX file names. Please note that it is *not* a
file name, the type name may (must?!) be annotated with resolution
information to yield the font filename.
But as I mentioned already in a former mail: This is implementation
dependent. And be it only because it's not defined what TeX will put
into the font area. (Of course, I've nothing against adapting the
above scheme as part of the standard -- I would not have to change
our drivers ;-)
--
Joachim
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
=========================================================================
Date: Tue, 7 Jan 1992 12:45:01 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Re: Font Issues
There are always more font names. So an ``offical canon''
of font names will never be complete.
Also, the font name in the sense of my naming scheme is not complete.
The most important problem, I think, is that the encoding scheme
is not (and cannot, as far as I can see) be specified independently
of everything else.
Some people, for example, use the PostScript fonts in their
native encodings. Some use them in the DVIPS encoding.
Some in something else, for all I know.
I don't think we can possibly standardize encoding schemes.
I and my partner are working on fonts for GNU. We want our
fonts to be usable with Ghostscript, but also with TeX.
The Cork encoding scheme does not include all the standard
PostScript characters. So we had to come up with yet another
encoding scheme.
I do not think problems like this will go away. I think any
``official'' VFtoTFM or whatever is hopeless. The worst
problem is not getting the fonts right, it's getting the
macros to access the fonts right.
=========================================================================
Date: Tue, 7 Jan 1992 12:48:48 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Re: ISO and the language/structure of the DVI standards
I would never have guessed that that was what quad meant.
The text I have definitely implies that quad is what
comes from the TFM file.
=========================================================================
Date: Tue, 7 Jan 1992 10:04:31 -0800
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
Subject: Font Issues
In-Reply-To: Don Hosek's message of Mon,
6 Jan 1992 21:31:00 PST <9201070533.AA15252@orion.arc.nasa.gov>
I agree that Karl Berry's naming scheme should not be promulgated
as a standard, for his second reason in particular. My opinion
is that the font vendor supplies the official name of the font,
and that the name known to the TeX programmer may differ.
The chief reasons for the aforementioned differences will be
limitations in the underlying filesystem (8-character name space)
and the limitation in TeX that the font name correspond to
a kind-of file name, combined with TeX's insistence that
the filename have no embedded space.
Because of these limitations, a font name in TeX will inevitably
differ from the vendor's name of the font, so sorry.
I wonder why a font naming scheme should somehow be a concern of
the DVI driver standard. After all, what a DVI driver must do is
really simple: translate the font name in the DVI file into something
that designates a unique font to either itself or to a print server.
This is necessarily a system-dependent activity.
I also don't believe that the vf scheme, however desirable, should
be designated as a standard exclusive of other remapping schemes.
There are a number of existing methods of dealing with fonts
whose mapping is not the same as CM. They may not be as flexible as
vf, but they should not be excluded.
-art
=========================================================================
Date: Tue, 7 Jan 1992 19:06:03 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: Re: Font Issues
In-Reply-To: <9201071803.AA13206@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from
"KarlBerry" at Jan 7, 92 12:45 pm
Karl Berry wrote:
>
> I and my partner are working on fonts for GNU. We want our
> fonts to be usable with Ghostscript, but also with TeX.
> The Cork encoding scheme does not include all the standard
> PostScript characters.
What characters were missing?
--
Joachim
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
=========================================================================
Date: Tue, 7 Jan 1992 13:14:58 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Re: Font Issues
My naming scheme could (and, in fact, does) suggest
names to ``vendors'' who are not companies, and merely
wish to make sure their name does not conflict with others.
Saying that ``vendor'' supplies the name is no reason not
to have a standard naming scheme. But there are other reasons,
as I said.
I agree with Art that a font naming scheme is not the business
of the DVI standard. But I think Don was proposing that
as a separate-but-related standard.
I certainly agree with Art that VF files should not
be designated the ``standard'' way to do remappings.
One naming scheme that I think could usefully be standardized
is one which has no limitations on length. Then the various
aspects could be separated cleanly. (Like the X11 font names.)
I propose such a thing in my revision of the TUGboat article.
(ftp from ftp.cs.umb.edu:pub/tex/fontname/fontname.texi, if you're
interested).
=========================================================================
Date: Tue, 7 Jan 1992 15:59:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Re: ISO and the language/structure of the DVI standards
Joachim said:
-[I] wrote:
->
-> Given Joachim's explanation of his desire for the ISO guidelines,
-> I think that it's possible to deal with linguistic imprecisions
-> on a point by point basis.
-It's also a problem of the structure.
I know it's a pain to check referenced notes, but I did give in
the quoted note a reference to another note in which I give the
modified ISO outline that I'd like to see us use. It covers most
of the stated objections.
-Or as barbara wrote it (cited
-with permission):
-| the organization of iso standards [is] a reasonable model to follow
-| in certain respects, most importantly in that the definition of a
-| concept occurs in an iso standard exactly once, and any discussion is
-| either clearly marked as a note, or is relegated to an "informative"
-| annex.
Cf. the outline which has a definitions section which is
currently lacking in the standard as it stands. The typographic
distinction currently in use, I would think counts as "clearly
marked as a note."
-|this leads to more precision, or at least (if the standard is
-| well written) to fewer possibilities for "interpretation" and
-| incompatibility. it also helps to make the statement of the rules
-| more concise, thus easier to wade through when trying to decide, does
-| this product conform or not? this is the real reason to have the
-| rationale as a separate document, or at least a separate section, and
-| i stand by it.
-And I plan to follow this advice. After all, barbara has the most
-experience with standard committees of us all. (``Lesser artists
-steal, greater artists borrow.'')
Funny but the intermingled-but-typographically-distinct approach
was usedf by Charles Goldfarb in his presentation of the SGML
standard and it's far easier to use than the corresponding ISO
document. But whether or not the rationale should be printed as a
single document, I know that Joachim does (or should on the basis
of posts on only tangentially related topics in other forums)
believe that the two texts should be in a single source file (and
if he doesn't I'll fight him tooth and nail since that was a
conscious decision from the first day that I began to type the
rationales into the standard). If he wants to take the trouble to
write code to print standard-without-rationale and
rationale-without-standard (actually about five minutes work with
Rainer Schopf's verbatim.sty) he can but I doubt that in practice
anything but the combined version will get used.
-dh
=========================================================================
Date: Tue, 7 Jan 1992 16:31:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Re: Font Issues
-I agree that Karl Berry's naming scheme should not be promulgated
-as a standard, for his second reason in particular. My opinion
-is that the font vendor supplies the official name of the font,
-and that the name known to the TeX programmer may differ.
But font vendors are inconsistent across platforms how they name
fonts! There is a definite need to have consistency in what Adobe
Times Roman is called across platforms.
As for fluidity in the canon/rules, so be it. I would anticipate
a 6month to 12month cycle in the publication of the standards so
their can be a periodic updating of the canon/rules easily
enough. In practical terms, as I've found through my experience
with printer-resident fonts and others have found as well, even
just a list of "call this font that" is awfully useful.
-The chief reasons for the aforementioned differences will be
-limitations in the underlying filesystem (8-character name space)
-and the limitation in TeX that the font name correspond to
-a kind-of file name, combined with TeX's insistence that
-the filename have no embedded space.
-Because of these limitations, a font name in TeX will inevitably
-differ from the vendor's name of the font, so sorry.
Yes, exactly. So if it has to differ, than let's try to be
consistent about this. There's no reason that there should be a
different version of times.sty for every DVI-to-PS translator.
-I wonder why a font naming scheme should somehow be a concern of
-the DVI driver standard. After all, what a DVI driver must do is
-really simple: translate the font name in the DVI file into something
-that designates a unique font to either itself or to a print server.
-This is necessarily a system-dependent activity.
I brought it up because (1) it's been brought up to this
committee in the past and (2) part of the goal of the standard is
to have the same DVI file translated as identically as possible
regardless of what driver/system/printer is used. Your reasoning
could be taken (without too much stretching) to imply that we
have no business mucking about with how graphics inclusion is to
be handled.
-I also don't believe that the vf scheme, however desirable, should
-be designated as a standard exclusive of other remapping schemes.
-There are a number of existing methods of dealing with fonts
-whose mapping is not the same as CM. They may not be as flexible as
-vf, but they should not be excluded.
Let's suppose that Tom Reid decides never to support VF in his
TeXrox drivers but does continue to support use of Xerox fonts
through Xetrix and its data files. If we endorse the use of VF
remapping as the official remapping scheme that doesn't mean that
Tom can't be compliant to any part of the standard, simply that
he can't claim "TUG standard external font" handling. On the
other hand, if he does use VF and standard external font naming
then his DVI files will be "more interchangable" with other
drivers.
-dh
=========================================================================
Date: Thu, 9 Jan 1992 17:52:32 MEZ
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Subject: reports and standard via mail-server
Don Hosek pointed out correctly, that not all members of this list
have ftp access. And since batch-ftp systems like bitftp@pucc.bitnet
are tedious I've put the standard document and the reports also on
rusinfo.rus.uni-stuttgart.de. There you can access it via mail. Send a
mail to
mail-server@rusinfo.rus.uni-stuttgart.de
with the body
help
. The files are beneath the directory soft/tex/drivers/driv-standard,
in subdirectories papers and level-0. Please note that this is not a
full duplicate of ftp.th-darmstadt.de -- only the current versions are
there, no back versions or backlogs or such.
--
Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Secretary of TUG DVI Driver Standards Committee
=========================================================================
Date: Fri, 10 Jan 1992 18:17:07 +0100
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: "Eberhard Mattes" <mattes@AZU.INFORMATIK.UNI-STUTTGART.DE>
Subject: Re: Area on font names in DVI files
In-Reply-To: Arthur Ogawa's message of Tue,
7 Jan 1992 09:28:43 -0800
<9201071735.AA07143@azu.informatik.uni-stuttgart.de>
> I too will be interested to see what current practice is.
The emTeX drivers ignore the area. It was of no use with the old release
because TFM files weren't read. It might become more useful with the
next release which will be able to read TFM files.
Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
=========================================================================
Date: Sat, 11 Jan 1992 07:48:44 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Re: Area on font names in DVI files
I think the area in font names should be used to look up
bitmap files, not just TFM files. That is, if the person
says
\font\foo = ./myfont13
then if the current directory does not have myfont13.tfm, TeX
should complain, and if the current directory
doesn't have some GF or PK or whatever that the driver can use,
the driver should complain.
Put another way, when the user has said what path to use, use it,
and don't use the default paths.
=========================================================================
Date: Mon, 13 Jan 1992 10:51:53 CST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Bart Childs <bart@CS.TAMU.EDU>
Subject: Area on font names in DVI files
DVI came from device independent. We all know that.
Including an area in a font name in a DVI file should
always be discouraged because it is a means of making
DVI file non-portable.
The directory separator is different on different
systems and we should not be wasting our time to try
to accomodate such bad practices. I know of systems
with the separator being `/', `\', `:', and `>'.
I'll bet there are more. Let's get onto productive
things. I agree with Karl, that the handling should
apply to both bitmaps and tfm files, but it should
also apply to graphics inclusions ...
Most of the TeX's and drivers have an easy way to
handle it by the use of searchlists (if you are lucky)
or environment variables that list directories in order.
Bart Childs
=========================================================================
Date: Mon, 13 Jan 1992 12:13:25 EST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Karl Berry <karl@CS.UMB.EDU>
Subject: Area on font names in DVI files
In-Reply-To: Bart Childs's message of Mon,
13 Jan 1992 10:51:53 CST <199201131658.AA15178@cs.umb.edu>
I certainly agree with Bart, including an area in font names or whatever
filenames makes the document unportable and is thus to be discouraged.
It's also true that given search paths, there may no real reason to ever
need this.
But I still think that DVI processors should use the area if it's
present, and not use search paths. If the document is using `\' for
directory separators when it's `/' on the current system, well, the file
won't be found. Not the DVI processors' problem.
But it would be extremely counterintuitive if the user asks for a font,
say, `./myfont', and myfont gets found somewhere in the system
directory.
=========================================================================
Date: Mon, 13 Jan 1992 14:04:00 PST
Reply-To: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
Sender: The TUG DVI driver standards discussion list
<DRIV-L@TAMVM1.BITNET>
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Areas on font names
That TeX will use the area on a \font specification is not a
question under debate. One case where I can see this useful dates
back to the TeX 2.0 days when I'd make a new TFM for a font which
had spaces which could stretch more than the normal defaults).
Now as for whether the area should be used by the DVI driver, the
obvious argument for it comes in looking in private directories
for bitmaps.
Arguments against this include
- What about multiple devices including some with identical
resolutions? The same font cannot under any circumstances be
used for an HP LaserJet and for a Xerox 4050. Anyone who has
used the latter can verify this one. This means that a
moderately complicated template must be used.
- MakeTeXPK-type support (a la dvips and the new emTeX drivers)
is really rather complicated by this sort of thing since
unknown PKs have to be put in unusual locations.
My judgment would be that while dealing with the area would be a
nice feature, it complicates implementation enough that it
shouldn't be required by the level 0 standard.
-dh