========================================================================= Date: Fri, 3 Jan 1992 15:51:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 for a current copy. -dh ========================================================================= Date: Fri, 3 Jan 1992 16:10:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Gaulle Bernard Subject: Re: Immediate goals In-Reply-To: Message of Fri, 3 Jan 1992 16:10:00 PST from 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Pierre MacKay 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 Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa 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 Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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 Sender: The TUG DVI driver standards discussion list From: Joachim Schrod 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 Sender: The TUG DVI driver standards discussion list From: "Eberhard Mattes" 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Bart Childs 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 Sender: The TUG DVI driver standards discussion list From: Karl Berry 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 Sender: The TUG DVI driver standards discussion list From: Don Hosek 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