--On Sunday, 08 January, 2006 14:42 +0200 Yaakov Stein <yaakov_s@xxxxxxx> wrote: >> While I personally like PDF for many things, I find PDF to be >> a poor > choice for IETF works-in-progress, >> or even for RFCs because they lack many of the >> characteristics that > ASCII files offer. > > Don't you mean that ASCII lacks many of the features PDF offers > (font faces, font styles, diagrams, etc. etc. etc.) ? > > The characteristic you apparently want, i.e. being easy to > plug into SW that accepts only ASCII characters, is recovered > by "text selection" in the PDF viewer. Yaakov, while I think most of this thread has continued past usefulness without a new, and narrower, proposal, because I remain interested in the potential of PDF for some purposes... I think this helps make it clear that any "use PDF" proposal, especially for I-Ds, needs to be very specific about a PDF profile and required feature set. It is possible to create perfectly good PDF files from which "text selection" won't work at all. It is possible to create PDF files that imbed font faces and styles from which text copying and pasting won't work in many operating systems even if "text selection" is available. Extracting a diagram from a PDF file so that _it_ can be edited is rarely an obvious operation. And so on. Unless those things are available, PDF may be fine for representing a finished document where the only requirement is accurate rendering, but it is fairly terrible for working documents, which I think is what David was trying to suggest. Even with them, it may be worse than importing ASCII into the editor of your choice, even if that editor is MS Word. One way to look at this is that one of the advantages of ASCII is that it is sufficiently feature-poor as to not require any (or much -- we still have the line-end problem) versioning or profiling. From that point of view, part of the problem with either PDF or Word is that they are feature-rich and growing (new versions are being produced with additional capabilities). So, to use them effectively in a contract in which material must be selected and worked on, one has to get into the business of specifying particular versions, features and must or must not be used, and so on. While XML formats can get quite complex, one of the advantages of that particular model is that it is extremely easy to test for whether any prohibited features have been used. My guess it that, for these complex and feature-rich systems, we will find it even harder to reach agreement on those profiling issues than on whether to permit these formats. As an example, assuming you would still like to see MS Word accepted as a submission and display format, suppose we agreed on Word 95's features and file formats. There might actually be some reasons for doing so, starting from the observation that Word<-> RTF conversions were much less likely to lose information than might be the case for Word 2003. But I can't go to the store and buy a copy of Word 95, no one is supporting it, and so on. Conversely, while I think Word 2003 claims to be able to write out Word 95-compatible files, we have no guarantees that capability will exist in Word 2006 or Word 2008 (?): your own observation about Microsoft's incentives about new versions would suggest that the backward support will be dropped at some stage. Worse, it is not easy to tell a Word 2003 file from a Word 97 one, at least without some serious reverse-engineering, so it is fair to predict that we would see leakage and other side effects, some with significant ill effects. So, while applauding your current I-D as a useful first step (I _really_ dislike having these discussions in the absence of a draft), if you want to propose PDF, I think it is time that you (or others) produce a starting-point draft that specifies or discusses at least: * What the PDF is to be used for (several people, not just myself, have pointed out that the rules might plausibly be different for I-Ds and RFCs) * What version of the file format is to be used. * Consistent with that version, what features are required to be supported in the PDF file * Consistent with that version, what features are prohibited in the PDF file. * What is to be required about font-embedding and whether any restrictions on fonts and styles or the size and definition of image are needed. * Probably answers to some other questions I don't know enough to ask * How, or if, it is possible to design and build good, multiplatform, tools to test for whether or not those requirements have been met. I think it would also be helpful if the draft would identify a selection of tools, for a variety of platforms, that could be used to create the relevant documents and, ideally, enforce whatever requirements are specified. If that list implies a requirement for any tools that require high-powered machines, large amounts of disk space or memory, particular versions of particular operating systems, and/or expensive per-machine licenses, then we need to know, and consider, that as well. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf