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