🚀 go-pugleaf

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