ted@imsvax.UUCP (Ted Holden) (01/04/86)
In a reply to my article concerning WordPerfect and the Navy DIF standard, H. Silbiger of Bell Labs gives a (reasonably) accurate account of the circumstances involved in the development of the DIF, but also provides several pieces of mis-information which I would like to clear up. >The first thing they agreed on that only functions everyone >used would be supported. This should read "would be supported IN FILE STRUCTURE". This doesn't mean that you LOSE things such as right-flush tabs, footnotes, or the WordPerfect paragraph numbers which fall outside of the 45 functions retained by DIF; it simply means that a reasonable WordPerfect to DIF conversion routine would transmit these things on a PAGE-IMAGE basis only, e.g. translate a right-flush tab into the appropriate number of blank spaces etc. Conversely, it makes no sense for other standards, such as the ISO,to include paragraph numbers as a file structure item, when most word processors or even a reasonable number of word processors don't have them. >Next they looked at those functions >for which evryone used the same control code. Those were accepted. >Next they all agreed on a code for all other functions for which >there was no common code. This is simply wrong. No two vendors used the same code for ANYTHING, there being as many file structures for word processors as there are people WRITING word processors. DIF codes, other then the 13 older VT100 type codes for things such as bolding and justifying which the standards committees forced on us, consist of an escape followed by a left bracket, then a numeric parameter of some sort, then a dollar sign indicating the end of the parameter, and lastly a character indicating the nature of the code. A left Margin setting of 11 would be Escape[11$@ the "@" symbol being the code for left margins. Of the 128 Ascii codes available, we have used 33; so much for the notion that the DIF is not extensible for future needs. >The DIF work should thus be seen as a stop-gap measure to >achieve some limited degree of interchange. It is not >easily extensible, and cannot support compound documents. The DIF is here and available NOW; the standards Mr. Silberman speaks of exist on paper and are likely to remain so, and there are several good reasons for believing that the Navy DIF standard will be the best system of document conversion available in the real world for some time to come. Actually writing DIF conversion routines which performed acceptably turned out to be FAR more difficult than anticipated, taking six months to a year in most cases. There have been several outright failures by major corporations attempting to write acceptable DIF routines, and the ones which do work and which the Navy has validated are typically on revision 150 or 200 at the time of acceptance. People who have actually been through this process are not likely to want to hear about any standard much more complicated than DIF. All attempts to write DIF conversion routines as if they were simply one-to-one table look-up type programs failed miserably and were unacceptable to the Navy, as I will shortly document and explain in one or two future articles. As I have stated previously, SSI's attempt at including Navy DIF in their little Convert routine falls into this category and basically doesn't work at all. I.M.S. has a set of real DIF filters for WordPerfect which we wrote as a means of bidding federal contracts with PCs. Anyone wanting a copy of these should send a purchase order and a check for $100 to: Integrated MicroComputer Systems DIF Development Group 6110 Executive Blvd., Rockville, Md. 20852 Suite 750
desj@brahms.BERKELEY.EDU (David desJardins) (01/05/86)
In article <491@imsvax.UUCP> ted@imsvax.UUCP (Ted Holden) writes: > > In a reply to my article concerning WordPerfect and the Navy DIF standard, >H. Silbiger of Bell Labs gives a (reasonably) accurate account of the >circumstances involved in the development of the DIF, but also provides >several pieces of mis-information which I would like to clear up. > They seem to have been omitted from the following, in that you basically support everything that he said... >>The first thing they agreed on that only functions everyone >>used would be supported. > > This should read "would be supported IN FILE STRUCTURE". This >doesn't mean that you LOSE things such as right-flush tabs, footnotes, >or the WordPerfect paragraph numbers which fall outside of the 45 >functions retained by DIF; it simply means that a reasonable >WordPerfect to DIF conversion routine would transmit these things on a >PAGE-IMAGE basis only, e.g. translate a right-flush tab into the >appropriate number of blank spaces etc. Conversely, it makes no sense >for other standards, such as the ISO,to include paragraph numbers as a >file structure item, when most word processors or even a reasonable >number of word processors don't have them. > Well obviously a tab can be turned into a bunch of spaces if your document standard doesn't include tabs! Are you claiming that by allowing spaces to be included in documents DIF _supports_ right-flush tabs!? >>Next they looked at those functions >>for which evryone used the same control code. Those were accepted. >>Next they all agreed on a code for all other functions for which >>there was no common code. > > This is simply wrong. No two vendors used the same code for >ANYTHING, there being as many file structures for word processors as >there are people WRITING word processors. DIF codes, other then the 13 >older VT100 type codes for things such as bolding and justifying which >the standards committees forced on us, consist of an escape followed by >a left bracket, then a numeric parameter of some sort, then a dollar >sign indicating the end of the parameter, and lastly a character >indicating the nature of the code. A left Margin setting of 11 would be > > Escape[11$@ > >the "@" symbol being the code for left margins. Of the 128 Ascii codes >available, we have used 33; so much for the notion that the DIF is not >extensible for future needs. > I don't suppose there was too much disagreement on things like ^I for tabs and ^J or ^M for end of line; these presumably were retained and the codes you describe were devised for the other functions. You say, "This is simply wrong," then offer no conflicting statement... On a separate point, aren't these control codes awfully redundant? Presumably a major goal of a document standard is compactness; do you really need six characters for the above?? >>The DIF work should thus be seen as a stop-gap measure to >>achieve some limited degree of interchange. It is not >>easily extensible, and cannot support compound documents. > > The DIF is here and available NOW; the standards Mr. Silberman >speaks of exist on paper and are likely to remain so, and there are >several good reasons for believing that the Navy DIF standard will be >the best system of document conversion available in the real world for >some time to come. > I look forward to seeing them... > Actually writing DIF conversion routines which performed acceptably >turned out to be FAR more difficult than anticipated, taking six months >to a year in most cases. There have been several outright failures by >major corporations attempting to write acceptable DIF routines, and the >ones which do work and which the Navy has validated are typically on >revision 150 or 200 at the time of acceptance. People who have actually >been through this process are not likely to want to hear about any >standard much more complicated than DIF. > The whole point of a standard is to make it versatile enough to handle everything; otherwise people who need to do things outside the standard make up their own extensions (or abandon the standard altogether) and pretty soon you have fifty different systems again. I don't see how anyone can consider a document standard which doesn't understand proportional spacing acceptable... I have to confess I don't see why it would be so hard to write a conversion routine; please do let us know why this is so difficult. It seems like a fairly straightforward task to me (which, I suppose, probably just demonstrates my ignorance...). The idea that major corporations could fail completely in writing a DIF conversion routine seems inconceivable... > All attempts to write DIF conversion routines as if they were >simply one-to-one table look-up type programs failed miserably and were >unacceptable to the Navy, as I will shortly document and explain in one >or two future articles. As I have stated previously, SSI's attempt at >including Navy DIF in their little Convert routine falls into this >category and basically doesn't work at all. I.M.S. has a set of real >DIF filters for WordPerfect which we wrote as a means of bidding federal >contracts with PCs. Anyone wanting a copy of these should send a >purchase order and a check for $100 to: > > Integrated MicroComputer Systems > DIF Development Group > 6110 Executive Blvd., > Rockville, Md. 20852 > Suite 750 Well obviously there's more to it that a 1-1 lookup, but that's not saying much... Also, I didn't think the net was for advertising commercial products (but please don't let this stop you from continuing this discussion). -- David desJardins