From <@VM.ITS.RPI.EDU:LISTSERV@IRLEARN.UCD.IE> Thu May 11 12:24:29 1995 Received: from VM.ITS.RPI.EDU (vm.its.rpi.edu [128.113.26.10]) by mail1.its.rpi.edu (8.6.9/8.6.4) with SMTP id MAA27141 for ; Thu, 11 May 1995 12:24:22 -0400 Message-Id: <199505111624.MAA27141@mail1.its.rpi.edu> Received: from VM.ITS.RPI.EDU by VM.ITS.RPI.EDU (IBM VM SMTP V2R2) with BSMTP id 2383; Thu, 11 May 95 12:25:15 EDT Received: from IRLEARN.UCD.IE by VM.ITS.RPI.EDU (Mailer R2.10 ptf000) with BSMTP id 0381; Thu, 11 May 95 12:25:14 EDT Received: from IRLEARN.UCD.IE (NJE origin LISTSERV@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 4220; Thu, 11 May 1995 17:21:58 +0100 Date: Thu, 11 May 1995 17:21:57 +0100 From: BITNET list server at IRLEARN (1.8a) Subject: File: "TWGDVI-L LOG9409" To: Michael D Sofka ========================================================================= Date: Thu, 1 Sep 1994 09:14:35 -0400 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: "Michael D. Sofka" Subject: Test message. This is a test message to see if TWGDVI-L is working (from my end). Please let me know if you receive anything. Mike ========================================================================= Date: Thu, 1 Sep 1994 15:29:35 +0100 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Sebastian Rahtz Subject: Re: Test message. In-Reply-To: Your message of "Thu, 01 Sep 1994 09:14:35 EDT." <"swan.cl.cam.:068940:940901141527"@cl.cam.ac.uk> i shall shortly try and pass on to this list some meterial about snardardized \specials for www addresses embedded in dvi files. it might be relevant. that was my test sebastian ========================================================================= Date: Thu, 1 Sep 1994 16:28:05 SST Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Friedhelm Sowa Subject: Re: Test message. On Thu, 1 Sep 1994 09:14:35 -0400, Michael D. Sofka wrote: >This is a test message to see if TWGDVI-L is working (from my end). >Please let me know if you receive anything. Now you know :-) Friedhelm ========================================================================= Date: Thu, 1 Sep 1994 08:42:55 -0700 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: "Tomas G. Rokicki" Subject: Re: Test message. I got something; thanks! -tom ========================================================================= Date: Fri, 2 Sep 1994 11:10:46 -0400 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Michael Sofka Subject: Introduction and Charter. Hello, I assume from the responses that the TWGDVI-l is working, and I'm the only person who did not receive the introductory notice.... As some of you may already know I was asked to chair the Technical Working Group for DVI issues. The following is the charter as given to me by Michael Ferguson. As you can see there is considerable flexibility, and even with this flexibility the mandate was given as "Tentative". ---------------------------------------------------------------------- WG-94-08: (SC-TWG) --- Standards and Coordination TWG Title: DVI Driver Implementation and Standardization Issues Mandate: (Tentative) The major objective shall be to study the issues in the requirements of DVI Drivers imposed by changing needs and technologies, and to make recommendations for implementation and standardization of such drivers to enhance the uniformity of their use. Work will include, but not be limited to, the examination of the use, syntax, and semantics of \special{..} commands. Technical Working Group Chair: Michael Sofka (mike@psarc.com) Technical Council Liason: Sebastian Rahtz (spqr@ftp.tex.ac.uk) ---------------------------------------------------------------------- Actually, this sounds like a fair and reasonable mandate and I would like to propose as our first order of buisness that the tentative be removed. Are there other issues that should be added for consideration in the future? As a second order of buisness I propose that we adapt the use, syntax and semantics of \special{..} comands as our first implementation and standardization issue. As can be seen by almost any of the talks presented at TUG'94, and by reading the very common questions regarding figure inclusion in comp.text.tex, there are a lot of specials out there, and they are not always compatable. It is also clear that making them compatable will not be an easy task. Some of the difficulties with standarization are: 1. Invested work in the form of driver code and macros for particular sets of specials. 2. Conflicting priorities for specials. For example: a. Page independence---should specials be allowed to affect later or earlier pages in a file. b. Macro writer interface---should the burden for maintaining consistency be on the special writer, or the macro writer. c. Platform [in]dependence---Mac, PC, UNIX. (e.g, Mac's are used in pre-press, and specials could be tailored for interfacing with other Mac based programs.) d. Clean and uniform special interfaces. The syntax and semantics of most of my specials "just growed" that way. This does not seem to be good way to develope a standard. e. Others I missed. 3. Who are the customers. That is, are the specials being designed for portablitiy, or for particular purposes. Are screen previews, and printer independence important for these customers? (I'm using the word "customers" in the modern Demming sense of "who is going to make use of your work," or "who are you doing the work for, and what do they want". Of course, Demming also said that it is your job to find what the customer wants, even if they do not yet know it.) There are already a lot of specials out there, and they are being used. It would be desirable for a standard to be able to (at the least) not exclude previous work. One plan of attack is to first put together a taxonomy of existing specials. Their syntax and semantics, examples of use, and drivers/platforms that support them. We could publish this in an upcomming issue of TTN, or TUGBoat. I personally feel that a taxonomy is a necessary precurser to a serious standarization process because we need to know what is out there to form the base of a standard. I am sure that there are many present and future uses of specials that we collectively have not thought of. To this end we should also post notices in comp.text.tex, info-TeX, and TTN asking for manual pages on specials. Some of you represent vendors, or may know of vendors whose specials should be considered. (Are there any volunteers to contact them?) Nelson Beebe has given me an article on how specials will be handled in the next release of his driver suite, and Tom Rokicki has mentioned a similar article for dvips. Would the two of you be willing to make the articles available to members of this list? Finally, some of you expressed a great deal of interest in contributing to the TWG, and others would prefer observer status. Could each of you introduce yourselves to the members, express your particular interest in specials and other DVI Driver issues, and establish your "official" status. The only difference I can see between members and observers is the members should be willing to aid in collecting the taxonomies, putting together summaries for publication, writing progress reports, and so on. Comments will be asked of, and considered by all. Lastly, who else should be included in this list? The current members are: Nelson Beebe beebe@math.utah.edu David Carlisle carlisle@cs.man.ac.uk Angus Duggan angus@harlequin.co.uk Yannis Haralambous Yannis.Haralambous@univ-lille1.fr Berthold Horn bkph@ai.mit.edu Eberhard Mattes mattes@azu.informatik.uni-stuttgart.de John Plaice plaice@ift.ulaval.ca Sebastian Rahtz spqr@ftp.tex.ac.uk Tom Rokicki rokicki@cs.stanford.edu Joachim Schrod schrod@iti.informatik.th-darmstadt.de Michael Sofka mike@psarc.com Friedhelm Sowa tex@mail.rz.uni-duesseldorf.de Barry Smith barry@bluesky.com -- Michael D. Sofka mike@psarc.com Directory of Software Development, Publication Services, Inc. ========================================================================= Date: Mon, 5 Sep 1994 12:42:40 +0100 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Sebastian Rahtz Subject: Re: Introduction and Charter. In-Reply-To: Your message of "Fri, 02 Sep 1994 11:10:46 EDT." <"swan.cl.cam.:142000:940905104312"@cl.cam.ac.uk> > > Technical Council Liason: Sebastian Rahtz (spqr@ftp.tex.ac.uk) could you change that to sebastian.rahtz@tex.ac.uk, please? the other form will stop working soon. it also serves to explain my presence here :-} Though i also admit to a very considerable interest in the \special question with reference to the LaTex2e graphics and colour packages which i assist David C with. LaTex2e would naturally love to have a default graphics driver package with `standard' syntax :-} if anyone wnats to know what i really am, i recently started work as TeX Analyst for Elsevier Science Ltd in the UK. > 1. Invested work in the form of driver code and macros > for particular sets of specials. i suspect a lot of this is hidden, such as the specials Mike himself uses at PS. my experience of the `public' stuff is that it can be sorted out, and the investment is not *too* great. > b. Macro writer interface---should the burden for > maintaining consistency be on the special writer, > or the macro writer. speaking for LaTeX2e, standardization of abilities and agreement on what they do is more importantthan absolute syntax. for instance, PS figure inclusion - some peopel support clipping to teh bounding box, others not. its very irritating allowing for this discrepancy in function > least) not exclude previous work. One plan of attack is to first put > together a taxonomy of existing specials. Their syntax and semantics, > examples of use, and drivers/platforms that support them. We could > publish this in an upcomming issue of TTN, or TUGBoat. I personally > feel that a taxonomy is a necessary precurser to a serious > standarization process because we need to know what is out there to > form the base of a standard. agreed, yes, but lets not go overboard about this. get a catalogue going quickly, but not waste *huge* effort or time in getting it perfect. speaking selfishly, i'd like to use the chance of this catalogue to update the LaTex2e graphics drivers; that collection contains what I could glean late last year from various sources; i think took in the work that Laurent Siebenmann did in boxedeps in collecting specials > > Lastly, who else should be included in this list? The current members Karl Berry might like to contribute. and Art Ogawa has strong views. Andrew Trevorrow might like to represent his OzTeX view. i'd also like the AMS represented for their hypertext project sebastian ========================================================================= Date: Mon, 5 Sep 1994 15:14:17 BST Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: David Carlisle Subject: Re: Introduction and Charter. In-Reply-To: <9409050949.AA10833@m1.cs.man.ac.uk> (message from Michael Sofka on Fri, 2 Sep 1994 11:10:46 -0400) > Could each of you introduce yourselves to the members, express your > particular interest in specials and other DVI Driver issues, OK I'm David Carlisle and I got roped into this because, together with Sebastian Rahtz, I am responsible for the support for colour/graphics inclusion and other `driver related' features in the LaTeX2e distribution. > and establish your "official" status. Put me down as a ``member''. David ========================================================================= Date: Tue, 6 Sep 1994 12:00:27 EDT Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: "Berthold K.P. Horn" Subject: Test message. In-Reply-To: Sebastian Rahtz's message of Thu, 1 Sep 1994 15:29:35 +0100 <9409011536.AA29523@life.ai.mit.edu> Hi: could you list my email address as 71172.524@compuserve.com please. I don't use the bkph@ai.mit.edu InterNet address much. Thanks, Berthold. ========================================================================= Date: Mon, 12 Sep 1994 02:00:12 +0200 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Yannis Haralambous Subject: Re: Introduction and Charter. Sorry it took me so long to answer. I only would like to share a few thoughts on that idea of taxonomy, and its publication in TUGboat or TTN: -- let's do it, -- but let's not impose TUGboat/TTN readers the sight of it. \specials tend to become mythical objects, and a standad syntax for them is the equivalent of the Graal for the common TeX user. Giving a list of all \special syntaxes from past and present would be very fair for all those people who have worked on it, but extremely painful to read. It surely would be nice to have such a document, but it should be published apart. Peter Flynn will never accept it for TTN (too technical!) and if we put it into TUGboat there will be even more people shouting that TUGboat is for gurus only. Why do we need to have it printed in the first place? aren't we living in the age of WWW? Acrobat? Instead of spending time and effort in establishing YASS (Yet Another Special Syntax), I would propose we find and write down tools to switch between syntaxes. Let's fond out what the minimal requirements for a syntax are, so that we can tell which ones can unambiguously be converted into each other. A tool that detects which syntax is being read would be the ideal thing (but then perhaps I'm asking too much). Don't forget that we want backwards compatibility: all those DVI files lying around, have \specials inside them (think of the heroin of Alien 3). In the Omega project we are defining fltering processes for the \special stream. What interests us the most right now, is a clean way to convert all possible \special syntaxes into each other (OK, let's stop being impartial, we want to convert everything into dvips syntax, as long as PostScript is the goal; after all it's author has promissed us to upgrade it for XVF and XFM 16-bit fonts ;-) Finally a last thought: I think that name (and mandate?) of this working group should be slightly changed, to cover also Metafont specials. Don't forget that there is a similar notion for information imbedded in GF files. I'm using those specials to get information out of Metafont: in this way I can produce virtual fonts *with* Metafont (and a small tool which reads the data in the GF file and writes it in a text file). besides this way of using them, these specials could also contain PostScript commands: then we could have colored letters (in much the same way as virtual fonts do it). Unfortunately, in the PK format MF specials can only be placed between characters and that limits their scope severely (otherwise we could have Metapost-like features using Metafont specials). As the author of the PK format is on this list, maybe it is time to enhance that format a bit, concerning those specials? that is, if we can keep backwards compatibility. Enough for now, Cheers Yannis ========================================================================= Date: Mon, 12 Sep 1994 09:40:53 +0100 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Sebastian Rahtz Subject: Re: Introduction and Charter. In-Reply-To: Your message of "Mon, 12 Sep 1994 02:00:12 +0200." <"swan.cl.cam.:002870:940912000059"@cl.cam.ac.uk> in reply to Yannis: no amount of conversion will put in information that wasnt supplied. see my example of included PS figures - are they to be clipped to the BB or not? write the tools, yes, but dont let that stand in the way of defining the needs, if not the precise specification. well, who could deny the MF \specials are not interesting too? and the ones in VFs. the taxonomy thing should include those too. sebastian ========================================================================= Date: Tue, 20 Sep 1994 17:03:47 +0200 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: Joachim Schrod Subject: Re: Introduction and Charter. In-Reply-To: <199409050948.LAA08623@hp5.iti.informatik.th-darmstadt.de> from "Michael Sofka" at Sep 2, 94 11:10:46 am Michael Sofka wrote, long ago: > I assume from the responses that the TWGDVI-l is working, and I'm the > only person who did not receive the introductory notice.... If you want to receive a mail you sent yourself, you have to turn this feature on at the Bitnet listserver. (I can look up the details if necessary.) > Nelson Beebe has given me an article on how specials will be > handled in the next release of his driver suite [...] > Would you be > willing to make the articles available to members of this list? Nelson's article has been made available (years ago ;-) at the archive of the defunct DVI Driver Standards Committee. That archive is at ftp.th-darmstadt.de:/pub/tex/dvi-standard/. Nelson's paper is in a subdirectory named papers/. There is also a (very early) proposal by Don Hosek. > Could each of you introduce yourselves to the members, express your > particular interest in specials and other DVI Driver issues, Well, we know all of us personally, don't we? I'll concentrate on the driver side of the introduction... I did DVI driver development for about ten years, from 1982 to 1992. First, I wrote about four stand-alone drivers in different languages (the very first in IBM 370 assembler controlling a 120dpi matrix printer connected to a terminal line...); then a driver family that runs on 7 different operating systems (all Unix variants count as one) and supports 16 output devices (dot matrix printers counting as one device). The latter project was actually about methods to produce portable compiler backends, that these backends are DVI drivers was only of remote interest. (That's my master thesis. ;-) Later, I made a presentation (together with my supervisor, Klaus Guntermann) at the Exeter TeX conference about classification of driver features. It was also a proposal how standardization could proceed. This got me involved in the TUG DVI Driver Standards Committee. After having lots of discussion, I opened my mouth too wide and got secretary of this committee. In the next year I consolidated the text for the level 0 standard and triggered its publication in TUGboat. To make one thing clear: this text has still lots be desired. With all the inconsistencies and problems it has (that nobody wanted to discuss further...), it's far from being really finished. At Portland (1992) Don Hosek stepped back as chair of the committee and I was asked if I could transform the committee into a TWG, as its chair. (The whole framework of TWGs was just founded at this time.) Due to some problems with the TUG board this was not possible. One year later, at Aston, the problems were cleared out, but then it was too late for me, my main interests had moved to other problem domains already (formal specification of TeX and integration of TeX into an author's workbench). I told Michael Ferguson that it would be better if he would found another person that could make this job, I'll participate in the discussion. My particular interests in special? I don't have any particular interests there. My interest in DVI driver standardization was and is that the standard does not single-handedly focuse on one specific class of output devices or even on one specific output device. IMO one of the most important points in the whole DVI issue is the portability we have with it. If we abandon this portability we should think about abandoning DVI at all, it does not serve its role any more. Then there are other (better?) page description languages one can or should use. (You know what I've got in mind here. ;-) > and > establish your "official" status. The only difference I can see > between members and observers is the members should be willing to aid > in collecting the taxonomies, putting together summaries for > publication, writing progress reports, and so on. Comments will be > asked of, and considered by all. Then I think I'm an observer. I want to be engaged in discussion, but my time does not allow to really participate in writing papers. (To be blunt: I think I've done my share.) Perhaps you could see my role as someone who has participated in the `old' discussions and don't want to see the knowledge and experience of these discussions being discarded. I hope that I'm not the only person doing this, there are many others on this mailing list who did participate then already. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ========================================================================= Date: Tue, 20 Sep 1994 11:24:38 -0400 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: "Michael D. Sofka" Subject: Administrivia and appolgies. Hello fellow TWG members, First, my appologies for being negligent in my duties to get this discussion going. My paying job has been keeping me busy, and as a result some mail has been sitting in my box for some time without being addressed. I ask you to bear with me for the next couple of weeks. I'm soon going to be changing jobs (from Publication Services to Rensselaer Polytechnic Institute), and after seven years with the same employer there are a lot loose ends to clean up. (Not to mention new loose ends to learn.) > Sebastian Rahtz asks: >could you change that to sebastian.rahtz@tex.ac.uk, please? I've sent this request and other email change requests to Peter Flynn. >> 1. Invested work in the form of driver code and macros >> for particular sets of specials. >i suspect a lot of this is hidden, such as the specials Mike himself >uses at PS. my experience of the `public' stuff is that it can be >sorted out, and the investment is not *too* great. Yes, there is a lot of work invested in the drivers used by Publication Services. But, we are also to some extent less concerned about loosing that work then we are about being sure that standards adopted will do the job required. Maybe the public stuff can be sorted out and standarized (that is the optimistic view), but I suspect that some of the goals of different driver writers may be in conflict with each other. This is why I suggest a taxonomy as a first step. >> b. Macro writer interface---should the burden for >> maintaining consistency be on the special writer, >> or the macro writer. >speaking for LaTeX2e, standardization of abilities and agreement on >what they do is more importantthan absolute syntax. for instance, PS >figure inclusion - some peopel support clipping to teh bounding box, >others not. its very irritating allowing for this discrepancy in >function This is a case in point. To me it seems obvious that you want to clip the figure. This view comes from the way we use figure integration, and the way we develope our figures. All of our artwork includes accounting information. That is, a little label giving the book name, the art number, the date, etc. We, of course, do not want this information printing in the final book. We also do not want to delete it from hundreds of pieces of art before figure integration. So, we clip the figures. It is equally obvious (from my view) that you cannot depend on the figure BoundingBox to provide accurate figure dimensions. Some figures do not have BoundingBoxes, some have incorrect BoundingBoxes, and very often the BoundingBox reflects sections of the file that are not a part of the figure (such as accounting information). In addition, the PostScript BoundingBox is only accurate to 1 point. There are many cases where design elements are done as art work, and require greater then 1 point accuracy. > > least) not exclude previous work. One plan of attack is to first put >> together a taxonomy of existing specials. Their syntax and semantics, >> examples of use, and drivers/platforms that support them. We could >> publish this in an upcomming issue of TTN, or TUGBoat. I personally >> feel that a taxonomy is a necessary precurser to a serious >> standarization process because we need to know what is out there to >> form the base of a standard. >agreed, yes, but lets not go overboard about this. get a catalogue going >quickly, but not waste *huge* effort or time in getting it perfect. Agreed, if by perfect you mean getting all the messy details correct. The purpose is not a users guide to all specials, just a guide to how people are using specials. > speaking selfishly, i'd like to use the chance of this catalogue to >update the LaTex2e graphics drivers; that collection contains what I >could glean late last year from various sources; i think took in the >work that Laurent Siebenmann did in boxedeps in collecting specials A good use, but one that might require getting some of the messy details correct. >> Lastly, who else should be included in this list? The current members >Karl Berry might like to contribute. and Art Ogawa has strong views. >Andrew Trevorrow might like to represent his OzTeX view. I've written Art and Karl, but do not have an email address for Andrew Trevorrow. Could you (Sebastian) send him an invite, or send me his email address. Thank You. >i'd also like the AMS represented for their hypertext project Capital suggestion. I'll write Mike Downs. >sebastian >From: Yannis Haralambous >Sorry it took me so long to answer. I only would like to share a few thoughts >on that idea of taxonomy, and its publication in TUGboat or TTN: > -- let's do it, > -- but let's not impose TUGboat/TTN readers the sight of it. >\specials tend to become mythical objects, and a standad syntax for them is >the equivalent of the Graal for the common TeX user. Giving a list of all >\special syntaxes from past and present would be very fair for all those >people who have worked on it, but extremely painful to read. It surely >would be nice to have such a document, but it should be published apart. >Peter Flynn will never accept it for TTN (too technical!) and if we put it >into TUGboat there will be even more people shouting that TUGboat is for >gurus only. Why do we need to have it printed in the first place? aren't we >living in the age of WWW? Acrobat? An interesting view. Yes, a large linean taxonomy would be booring, and inappropriate for TTN. A summary of the findings, however, that are appropriate to driver writers would be an appropriate TUGboat article. >Instead of spending time and effort in establishing YASS (Yet Another Special >Syntax), I would propose we find and write down tools to switch between >syntaxes. Let's fond out what the minimal requirements for a syntax are, so >that we can tell which ones can unambiguously be converted into each other. >A tool that detects which syntax is being read would be the ideal thing >(but then perhaps I'm asking too much). Don't forget that we want backwards >compatibility: all those DVI files lying around, have \specials inside them >(think of the heroin of Alien 3). I like this idea, but in addition to converting between some standard special types (assuming they are convertable) does not meet to goals of all current and future writers. I'm thinking particularly of drivers for hypertext and interactive TeXs. Running a filter will slowdown these applications somewhat. In addition some consideration should be given to a uniform syntax that future drivers can use. >In the Omega project we are defining fltering processes for the \special >stream. What interests us the most right now, is a clean way to convert >all possible \special syntaxes into each other (OK, let's stop being >impartial, we want to convert everything into dvips syntax, as long as >PostScript is the goal; after all it's author has promissed us to upgrade >it for XVF and XFM 16-bit fonts ;-) Besides PostScript, there are display systems such as on Macintoshes, Windows and X. Requiring all documents be converted to PostScript for portability seems a bit much given that TeX is supposed to provide that portability in the first place. >Finally a last thought: I think that name (and mandate?) of this working >group should be slightly changed, to cover also Metafont specials. Don't >forget that there is a similar notion for information imbedded in GF files. >I'm using those specials to get information out of Metafont: in this way >I can produce virtual fonts *with* Metafont (and a small tool which reads >the data in the GF file and writes it in a text file). Very interesting. You, I suspect, are the expert on that field. How would you re-word the mandate, and what do you propose regarding Metafont specials. Are they widely used by font developers, and are there competing versions (as with drivers). But, we should concentrate our efforts on the first goal. >besides this way of using them, these specials could also contain PostScript >commands: then we could have colored letters (in much the same way as >virtual fonts do it). Unfortunately, in the PK format MF specials can only >be placed between characters and that limits their scope severely (otherwise >we could have Metapost-like features using Metafont specials). >As the author of the PK format is on this list, maybe it is time to enhance >that format a bit, concerning those specials? that is, if we can keep >backwards compatibility. Tom? >Yannis Mike -- Michael D. Sofka mike@psarc.com Directory of Software Development, Publication Services, Inc. Fifty percent of all software projects cost more then estimated. [And, fifty percent of all people are taller then average.] ========================================================================= Date: Wed, 21 Sep 1994 09:18:04 -0700 Reply-To: TeX Users Group TWG on DVI Driver Issues Sender: TeX Users Group TWG on DVI Driver Issues From: "Tomas G. Rokicki" Subject: Specials, bounding boxes, and PostScript Howdy, folks; time for me to check in, I guess. > >what they do is more importantthan absolute syntax. for instance, PS > >figure inclusion - some peopel support clipping to teh bounding box, > >others not. its very irritating allowing for this discrepancy in > >function > > This is a case in point. To me it seems obvious that you want to > clip the figure. This view comes from the way we use figure integration, > and the way we develope our figures. All of our artwork includes > accounting information. That is, a little label giving the book > name, the art number, the date, etc. We, of course, do not want > this information printing in the final book. We also do not want > to delete it from hundreds of pieces of art before figure integration. > So, we clip the figures. > It is equally obvious (from my view) that you cannot depend on the > figure BoundingBox to provide accurate figure dimensions. Some > figures do not have BoundingBoxes, some have incorrect BoundingBoxes, > and very often the BoundingBox reflects sections of the file that > are not a part of the figure (such as accounting information). > In addition, the PostScript BoundingBox is only accurate to 1 point. > There are many cases where design elements are done as art work, > and require greater then 1 point accuracy. For most people, though, using EPSF clip art and art generated by consumer applications, the bounding box is all they have to provide figure sizes. Ignoring the bounding box and requiring them to respecify the size somehow would be a bad choice for most of these users. And, as you say, since the bounding box is often subtly incorrect , clipping off descenders of the bottom text line or half the thickness of a rule on the edge of the figure, strictly clipping would severely impair the quality of the results. Thus, for most of my users, clipping off is the desired mode. For those like in you in a professional environment, where you both want and need clipping, it is easily accessible. Dvips has had optional clipping, with clipping by default turned off, for years, with no complaints; on the other hand, compare the many papers in conference proceedings and the like that have their figures subtly mangled because they used drivers with clipping and graphics with slightly-off bounding boxes. The one-point accuracy is indeed a problem. Some programs work around this by using floating point bounding boxes (even though the Red book says the numbers should be integers.) Most bounding-box parsing programs do the right thing with this form of bounding box; this might be an upwardly-compatible extension to promote. What is not acceptable, and what happens if the bounding box is missing or ignored, is to have the user guesstimate the dimensions, or eyeball it through the previewer a few dozen times. > Besides PostScript, there are display systems such as on Macintoshes, > Windows and X. Requiring all documents be converted to PostScript > for portability seems a bit much given that TeX is supposed to > provide that portability in the first place. Well, everyone knows how I feel about this---PostScript provides a cheap and uniform graphics rendering environment available on every platform (including Macintoshes, Windows, and X). I certainly don't want to reinvent, code, promote, fix, extend, and maintain yet another graphics standard, just so us TeX users can have our own version of `portability'! Perhaps endorsing a particular portable PostScript implementation (such as GhostScript) and integrating it into the TeX system (as has been done on numerous platforms) would be a reasonable alternative. > >besides this way of using them, these specials could also contain PostScript > >commands: then we could have colored letters (in much the same way as > >virtual fonts do it). Unfortunately, in the PK format MF specials can only > >be placed between characters and that limits their scope severely (otherwise > >we could have Metapost-like features using Metafont specials). > >As the author of the PK format is on this list, maybe it is time to enhance > >that format a bit, concerning those specials? that is, if we can keep > >backwards compatibility. For both GF and PK formats, the bits are sent in a specific, top-to-bottom, left-to-right order that severely restricts the way in which the raster might be colorized. I neither see any application for specials inside a PK character, nor do I even want to *think* about changing the PK format. So sell me on it. -tom