ISO/IEC JTC 1 Information Technology ISO/IEC JTC 1 N ???? DATE: 1999-01-04 REPLACES: N 4795, N 4763 DOC TYPE: Other document (Open) TITLE: Tips & Techniques for JTC 1 web-based distribution SOURCE: Editor, Keld Simonsen PROJECT: STATUS: Per San Diego Recommendation 7, this document is provided by the editor of the Tips & Techniques for JTC 1 Webpages. ACTION ID: FYI DUE DATE: DISTRIBUTION: P and L Members MEDIUM: NO. OF PAGES: ? Secretariat, ISO/IEC JTC 1, American National Standards Institute, 11 West 42nd Street, New York, NY 10036, USA; Telephone: +1 212 642 4932; Facsimile: +1 212 398 0023; E-mail: email@example.com
JTC 1 N ????
TITLE: Tips and techniques for JTC1 web-based distribution
SOURCE: JTC1 AD-HOC GROUP ON STRATEGY FOR IMPLEMENTING IT
This paper is provided in two sections:
Web Pages Tips and techniques
This section provides guidance on how to create and maintain web pages for ISO/IEC JTC 1 standardization committees. It also contains a proposal for a stucture of the pages and prototype pages. The scope only applies to ISO/IEC JTC 1 and its subcommittees, in the following named "committees", but WGs within the JTC 1 and other ISO or IEC committees may also benefit from the tips in the paper. This section is an implementation guide for JTC 1 N 5348 "ISO/IEC JTC 1 policy on electronic document distribution using the world wide web".
The pages should be made so it is straightforward to generate it out of existing TC or SC material, combined with the produced prototype web pages. The prototype pages have been made in a HTML-utilitities independent, portable and strictly conforming (to HTML 2.0) way, so they should be easy to use for integration. Basically what is needed is the scope of the committee in question, the chairman's or secretariat report to the parent body, or the business plan, the membership and liaisons lists, and then possibly descriptions of standards for example as text from the originating NP. Keld Simonsen, firstname.lastname@example.org has offered to help in merging the committee materials with the HTML sources, as well as offered hosting of the pages.
The committee web pages should be structured so that they are readable, also as a freestanding paper submission, of which these pages here are also an example. Normal style guidelines for good web documents, many available on the net, should be adhered to.
The structure of the prototype pages are:
The "internals" section is for confidential information, such as standards and other copyrighted work, ballot information, committee documents and email, and other documents that the committee wants to restrict access to. The information then needs to be accessible only via appropriate password protection.
The rest of the information scheduled as per this proposed web structure has been checked with the current ISO guidelines for document distribution, with special permissions for JTC 1, and should be OK for general distribution, as the following document types are classified for "open" distribution: Document register, secretariat report, programme of work, meeting notice, meeting agenda, meeting report, meeting resolutions, together with procedural information. As NPs are project related, these are also permitted for open distribution, under the one year trial period granted by the ISO TMB. Committees may chose to make another division of the distinction between public and restricted pages.
For restricted access, the password protection of most web servers can be used. For FTP protection, one can use a non-anonymous ftp account, or a hidden directory.
For mirroring web pages, it is advisable to only use ftp mirroring, as there are a number of problems with web mirroring using the HTTP protocol.
A number of resources are drawn upon, including the ISO and IEC web servers.
A number of guidelines for each of the documents is given below.
The structure of the web pages most likely will differ somewhat from committee to committee and will also necessarily develop over time, but some structure should be kept common, also for use in general ISO-wide text retrieval and web systems.
A specification in a web page indicating which documents are available and the naming conventions and reference conventions should be explained for people wanting to create links to the documents, and should not be changed lightly.
The complete web pages should be registered so they can be used, amongst other places at the ISO web pages.
The standardization committee should appoint maintainers for each of the documents, in many cases the pages will be maintained by the same person.
It is important that the web pages are well maintained. A way to do this is to have a direct relation to information already being generated by the committee, such as chairman's, or secretariat reports, project status, membership lists, ftp archives etc. As the web pages are advised to be readable clear text, the web document could be the same as the normal official document (or said in another way: the official document could be the web page).
Some of the information needed may be automatically updated, like ftp archive contents and e-mail subject list, and some may be done already by other sources, such as updated standards lists from ISO.
You should check your document for correct HTML before releasing it. A syntax checking service is available at http://www.webtechs.com/html-val-svc/mirror_sites.html
You should also check the set of pages for links that are erroneous.
Tools and template web pages will be produced or collected, and made available for JTC 1 use. Please contact the author, Keld Simonsen for suggestions.
A number of template web pages have been produced, to ease the production of ISO and IEC web pages, and to get a consistent feel across these web pages
In the following the contents of each of the pages will be described, along with some guidance on the contents. Not all pages have been described in this document, but information will be furnished in a later version.
The "index" page has general information for a casual interested person, while still being adequate also for work within the committee.
A user can find:
For further reference there is references to:
The HTML formatting requirements are very straightforward HTML. No complex capabilities are required for creating or viewing such pages. Also it is advised that a minimum of graphics be employed, as these may take a long time to download and thus may irritate the user, possibly to the extent of not getting the information.
There should be backpointers in the beginning of the text to the parent bodies on the homepage. On pages other than the home page, the committee name points back to the committee home page.
For the ISO and IEC bodies their logos are used, as also done on published specifications and committee documents etc. In addition, an ISO/IEC background could be given, so that a reader will know whenever official JTC 1 documentation will be read (and note when a pointer to non JTC 1 documentation is followed).
The items Contacts, etc. in the body are links to other pages with particular recommended formats (see subsequent pages of this document). Subitems are pointers to the headings within those pages.
If there are no items for an information topic, the item (e.g., "News") may be omitted from this list and no corresponding page need be generated. If a category name is not required (e.g., "Projects"), it may be omitted as well.
The page is designed to give a fair description about the committee at a first reading. The intended audience is users of the standards produced by the committee, that could be programmers, software architects, consultants, and other standardizers. That is a fairly technical audience - but these are the people that pay for the standards and pay attention to the work.
An emphasis is made on the products of the committee - what can be used by a broader audience.
For people that use the page as a way of looking up information there are hotlinks at the very beginning of the page. The same links are explained and hotlinked later, for more novice users.
The text is rather short, to convey the information to the user without having to look thru a lot of pages. The client user screen is normaly quite limited in size, so it is avoided to use a lot of graphics. The ISO/IEC logos are only about 5 k in total. The use of paragraph headings and paragraph numbers should be minimized, to make the page less formal and to conserve space.
For newcomers there is an initial statement indicating that this is an international standardization working committee.
The user is refered to the member body for further info. There are no long references to ISO, IEC etc., but hotlinks are provided. The casual user should not be tired by ISO administration, but get access to the products (the standards cannot be provided but maybe we can provide some interesting material to him/her).
Project numbers should be avoided on the index page, as they are quite formal and do not tell people outside the standardization committee anything. They may be included on followup pages. ISO is now using the final standards numbers as project numbers, eg JTC1.22.14652 .
For the committee member use there should be hotlinks in the very beginning of the homepage, making use snappy and easy. and also meeting information for upcoming meetings.
There is provision for restricted access to committee and ISO documents.
There is a news button in the hotlist which is not referred to in the rest. The news section should be first - but then writing "read all about the interesting news" as the first sentence would be overkill, and the news button is first anyway. And there may not be that much news anyway.
A "stop press" entry as the first part of the index page could be included, given that the news warrants it.
This contains news concerning the committee. It may be considered as an easy way of making press releases.
The newest news should be listed first.
All news should be retained, as a history stack.
ISO 8601 dates should be used, in the form of the format 1996-01-19, to faciliate easy searching on dates, in millenium-safe form, and intervals should use the notation 1996-01-19/24, using a "/" to indicate the interval.
This section should contain an overview of the standards produced by the committee. This could be just a list, but it could also include abstracts of each standard, possibly in the form of the scope of the standard. There could also be technical overviews produced specifically for the web. The standards themselves cannot be put here, except in cases where the ISO council specifically has decided to permit it.
This page contains information to the user which is more interested in the work of the committee, and what specifications are coming. It should thus be of a more technical nature than the standards page. The page should hopefully give a reader interest in becoming active in the committee.
The page should have a list of the projects assigned to the committee, and their status.
If there are no publications, the Publications section should contain merely "None."
The categories ("Committee Drafts", "Standards", "Technical Reports", etc.) are pointers to descriptions of the nature of these categories.
Pointers from the document should include all and only the public documents (active Standards, Committee Drafts available for review, Technical Reports, etc.) which have been produced by this committee.
The documents page contains a list of committee documents.
It might be convenient to have a newest document list, or latest mailing list separate from the full register.
The newest documents should be listed first to attact attention, so the list should be in reverse order.
Long tables should be avoided as the display of the table will only begin when all of the table is transferred. A list may better serve quick access to the information.
As minimum the document number, date, and title should be available in the main document register, and due date when applicable. Other document information could be available in a separate cover page.
There could be links to the actual documents here, with limited access to the restricted documents. The document number could point to a directory with different format versions of the document and cover pages, and the title could point to the most accessible document.
This page contains information on the future and past meetings.
Past meeting information should point to a working committee document, if any, containing the resolutions and minutes of the meeting. (Information about the meeting logistics, attendance, documents considered, etc. may be obtained from the minutes, which may itself contain hypertext pointers to home pages of representative bodies and committee documents.)
Future meeting information should point to a committee document containing details of the meeting plans and agenda, if available. Tentative meetings should be indicated as such.
Provisions should be made for signing up for the meeting easily - remembering that committee meeting is only open to member body representatives, committee officers and liaisons of the committee.
Information on meeting venue, hotels etc. should be available
Here a number of things internal to the committee can be given:
The information should be accessible via a group userid and password.
This page should list the officers of the committee, (chairman, secretariat, editors etc.), the members of the committee (as national bodies) and the liaisons, and the a number of links to related areas.
Contact information for both individuals and organizations might be "mailto:..." or conventional home page URLs.
Liaison information should only be provided for formal (committee-recognized) relationships.
Liaison can be listed with separate reference to liaisons from other committee to the committee, and to other committee from the committee. The name of the liaison can be listed, when explicit permission has been obtained from the person.
"name"-entries with the same name should be available for the following roles: chairman, secretariat, secretary, project editors, webmaster, postmaster, ftpmaster; project editors with the prefix "editor-" before the ISO number, for example "editor-99999-2".
The scope of the SC is to ....
To obtain the international standards from the SC, please contact your national member body.
The SC has the following working groups:
In addition SC22 has a prototype WG web page
In addition the SC is responsible within ISO/IEC JTC1 for the following projects:
ISO/IEC 11756:1992 MUMPS
Other information available is:
The SC secretariat report
The SC programme of work
The SC document register
Information on SC plenary meetings
Contacts: membership, liaisons and related work
If you want further information, or want to participate, please contact your national member body or one of the contact addresses.
N426 - Meeting announcement SC22 meeting April 1996
N425 - Acknowledgments Contributors IS 11404 and IS 13886
N424 - First CD of LIA-2
N423 - Final Text of IS 13886 - LIPC
N422 - Editor's Notes to the Final IS LID draft
N421 - Recommendations on JTC1 Document Formatting Guidelines
N420 - Minutes WG11 Meeting September 1995
N397 - WG11 Convenor Report to SC22; ref: email 355
N389 - Comments from Barkmeyer on LID DIS, and following email messages
April 15-19, 1996 - Copenhagen, Denmark
The call and draft agenda for the meeting and meeting place information are available. SC members and liaisons should send a message to the convener and local host on their plans to participate.
Past meetings were:
September 25-27, 1995 - Gaithersburg (MD), U.S.A.meeting report and resolutions
May 29 - June 1, 1995 - Amsterdam (Netherlands)
January 30 - February 3, 1995 - Maynard (MA), U.S.A.
secretariat: William C. Rinehuls ISO/IEC JTC1/SC22 Secretariat 8857 Rushing Creek Court Springfield, VA 22153 U.S.A. Tel: +1 703 912-9680 Fax: +1 703 912-2973 Email: email@example.com Email, web and ftp maintainer: Keld Simonsen DKUUG Fruebjergvej 3 DK-2100 København Ø Danmark Tel: +45 3122-6543 Fax: +45 3325-6543 Email: firstname.lastname@example.org
Australia Austria Belgium Brazil Bulgaria Canada China Denmark Finland France Germany Greece Japan Netherlands New Zealand Romania Slovenia Sweden Switzerland Ukraine United Kingdom United States
Argentina Cuba Czech Rep. Hungary Iceland India Italy Korean Republic Norway Poland Portugal Russian Federation Singapore Thailand Turkey Yugoslavia
Formal liaisons, working relations or cooperation agreements exist with the following:
ISO/IEC JTC1/SC24 - Graphics
ISO/IEC JTC1/SC26 - Microprocessors
Other related work that the SC follows are:
SC2 - Characters
97-06-22: news | faq | standards | projects | documents | meetings | contacts | procedures | internals
Approved international standards and other specificationsproduced include:
ISO/IEC TR 12345:1999 - Guide to Programming Language PROTO
ISO/IEC 12345-1:1999 - Programming Language PROTO
ISO/IEC 12345-1:1999 AM1 - Programming Language PROTO - Amendment 1
ISO/IEC 12345-1:1999 TCOR1 - Programming Language PROTO - Technical Corrigendum number 1
ISO/IEC 12345-2:1999 - Programming Language PROTO binding to Language Independent Datatypes
To obtain these international standards, please contact your national member body.
Work on projects and their milestones include:
Defect Reports and Record of Response
WI 12345-3: PROTO binding to POSIX
New work item proposal on PROTO binding to internationalization
Other information available is:
The WG document register
WG internal information
Information on WG meetings
Contacts: administration, membership, liaisons and related work
If you want further information, or want to participate, please contact your national member body or one of the contact addresses of the WG.
Comments are welcome! We can be reached at email@example.com
This Tips and Techniques Section is an aid to those involved in the creation submission, distribution and use of electronic documents on web-based JTC1 and SC sites. It contains guidance on documents in many of the formats specified in section 4.1 of JTC1 N5134 "JTC1 Policy on Electronic Document Distribution using the World Wide Web" in order to minimize the impact of problems experienced in the process. Any participant can, and is encouraged to contribute tips and information. Please send such contributions to the editor of this document, Keld Simonsen, firstname.lastname@example.org.
The information contained in this section is furnished on a "best efforts" basis and any errors or omissions are regretted. Where reference is made to a product or name to which copyright or a trade mark applies, the appropriate reference, where known, is made on the first occurrence of that term in the text.
In order to minimize change in the distribution process and thus increase the chances of error-free distribution of documents, the following aspects should be observed:
Submit the document in the word processing package, platform and release version in which it was originally prepared, provided that the format is one of the permitted formats.
When submission in another platform, release or word-processing package is necessary, then minimize the number of such changes and attempt to make them in the following order of preference:
Where possible, submit the document using one of the provided templates (Word)/ styles (Word Perfect). For many document types, a suitable template or sample document is to be found in JTC 1 N4737. Guidance on the choice of an appropriate format is contained in Annex E of ISO/IEC JTC1 N5348: JTC1 Policy on Electronic Document Distribution Using the World Wide Web, 1998-02.
In instances where a sample document is insufficient, change can be minimized by maintaining the original document in the form submitted by the originator and generating a separate cover page at the secretariat. To assist in this process, the document originator should supply their own template/style with the document. File naming considerations for this approach are documented in 4.4.2 of ISO/IEC JTC1 N5348: JTC1 Policy on Electronic Document Distribution, February 1998. Several examples, covering both simple and complicated cases, are contained in Annex B to JTC 1 N5348. It is important to note that the ability to leave the submitter's document unchanged will often outweigh the disadvantage of a document being a composite of more than one file.
Document originators should provide any relevant information they consider might be useful to the recipient of a document in order to enhance the recipient's chances of viewing the document in the way intended by the originator. Examples of information that might be of value to the recipient includes:
This information should be added to the preamble of the document.
There are many factors which result in discrepancies from the originator's layout being experienced by a receiver of a document. One contributory factor is the occurrence of font substitution in the recipient's machine environment. Font substitution results in different kerning and vertical spacing characteristics being used which upsets the original document format. In order to limit the occurrence of this phenomenon, it is recommended wherever possible, that the usage of fonts be limited to those shown in the table below:
|Font Type||Apple Macintosh and other environments 1||Microsoft Windows environment|
|Non-serif||ITC Helvetica||Arial TT (TrueType)|
|Serif||ITC Times Roman||Times New Roman TT|
|Fixed pitch font||Courier||Courier New TT|
Note 1. Other environments means any environment where Adobe Type Manager (for example IBM PC/DOS or equivalent) or Apple TrueType fonts are used.
It is recognized that observation of this recommendation may not always be possible in complex documents with specific font requirements (e.g. use of ASN.1 or test notations).
The character set used in text documents should be encoded according to ISO 8859-1 as defined in Annex D of ISO/IEC JTC1 N5348: "JTC1 Policy on Electronic Document Distribution Using the World Wide Web".
Adherence to the common printable area of A4 and 8.5" x 11" defined in Annex A of ISO/IEC JTC1 N5348: "JTC1 Policy on Electronic Document Distribution Using the World Wide Web" will reduce, but not necessarily eliminate, difficulties caused by the use of different paper sizes in North America from the ISO 216 standard sizes elsewhere. Particular attention needs to be paid to page layout in landscape format to ensure that the common area is utilized.
Particular care needs to be taken in the preparation of documents which require both portrait and landscape orientation. In order not to inconvenience recipients who may have widely different printing environments, the use of separate sections in a document for each orientation should be utilized. If, for some reason, this can not be accomplished, consideration should be given to making the parts of the document with separate orientations into separate documents.
As defined in ISO/IEC JTC1 N5348: "JTC1 Policy on Electronic Document Distribution Using the World Wide Web", February 1998, simple graphics may be embedded in revisable documents provided they are editable by the graphics applications of the accepted word processing packages. For other graphics the following approach should be considered:
In general, figures in documents (of certain types, especially developing standards) should be developed as separate files, using whatever application software is available and appropriate for the task.
Then, final figures should be converted into files using ISO/IEC 10918-1 (JPEG). Finally, the individual files are inserted into the word processing document at the appropriate points using, for example, Word's JPEG filter. Even when the figures are inserted into the document, it is important to consider the provision of the figures/graphics files as separate files in the original image file format.
There are several reasons for this approach.
Most commercial publication firms prefer separate text and figures files. This also can ease the conversion of the document to other formats.
There is a wide variety of application software for generating graphical figures. This approach allows the most appropriate software to be used for each figure, and yet requires that the figures in the final deliverable form will not require support of more than one standard file format. It must be emphasized that JPEG files can be very compact representations of bitmaps, but are still bitmaps. So the original files in the native format of the production application should be kept for future maintenance editing.
The figures and the text document can be worked by different editors in parallel. Having text place-holders in the document instead of the inserted figures can make the text editing task easier, since the file is smaller and graphics do not need to be rendered. The figures can be inserted only when a draft must be presented for consideration.
(There is a possibility of using other file formats during the transition: TIFF ,GIF and EPSF are generally acceptable.)
In the JTC1 Policy on Electronic Document Distribution Using the World Wide Web (ISO/IEC JTC1 N5348) the release versions of acceptable word processor software are stated as, for example, "Microsoft Word Version 2.0 - 6.0" or "Word Perfect Version 5.1 - 7.0". Clearly, difficulties can arise if one user is at a lower level of the software and another user utilizes a higher version which either stores the file in an incompatible format or uses functions which are unique to the higher version. However, the acceptable formats have been defined in this way in order to encourage a move towards the highest common factor of software use, rather than expressly limiting it to the perceived lowest common denominator. Two types of software can also be extremely useful in bridging the gap between different releases of word processor packages. They are in addition to the built-in capability of many word processor to convert from and save in many formats:
Converters which permit the conversion of earlier or even later versions of the same software. These are usually available form the software vendor, often at no extra charge. Examples are the availability of converters so that Microsoft Word 6.0/95 documents can be read by Word for Windows 2.0 software and, more recently, the provision of converters for the Word 97 format. With this capability a user may both read and revise a document from a different release.
Viewers which permit a user, usually at no charge, to read and print, but not modify, a document in a word processor form, without that user needing to have the word processing package itself. No charge Microsoft Word viewers are, again, an example.
RTF is one of the formats as defined in ISO/IEC JTC1 N5348: "JTC1 Policy on Electronic Document Distribution Using the World Wide Web". Care should be taken to ensure that the content of the document is such that fidelity of transfer can be expected when the document is transferred in RTF form. If the document contains aspects which are unlikely to be transferred with integrity in RTF, then distribution in a permissible word-processor should be considered. Guidance on format choice is given in Annex E of JTC1 N5348. Examples of technical aspects which may not be transferred with integrity in RTF are:
The use of revision marking such as the strike-out and underline approach for deleted and inserted text respectively. The strikeout and underlining may be lost in RTF, rendering the document unreadable.
The use of other than trivial graphics. For guidance see the section on Graphics.
Another aspect to be aware of when RTF is used as a transfer format is the possibility of losing space characters in the text. Many gateways, usually for performance reasons, are configured so that trailing blanks (i.e. space characters) at the end of each line are treated as nulls and stripped off before forwarding. This has no effect on transfer of ordinary ISO 646 data streams but can cause the loss of space characters between words in RTF data streams. As RTF data streams are a composite of control and text characters, the omitted spaces may occur anywhere in the document. If a user frequently experiences this phenomenon, it is likely that the source of the difficulty is close to that user (e.g. at the user's gateway) and it may be possible to arrange for the option of stripping trailing blanks to be suppressed.
Since RTF can be processed by many word processors, it is highly desirable to avoid the use of features which may not translate directly in another (or possibly the same) word processor environment. Examples of such features are:
The following are some of the areas which may affect the ability to reproduce a document with content and layout fidelity:
When moving between different platforms, font substitution may take place. Since this may result in the substitution of a font with different kerning characteristics, reformatting and re-pagination may well take place. This is particularly true when Macintosh fonts such as New York and Monaco are present in the incoming document. Word set-up can be varied to select a more appropriate font.
Similar to font substitution, style formatting alterations may take place. A typical problem is the substitution of 18-point for the "spacing before" paragraph attribute instead of the more typical settings of "single-space", zero point, or a point size equal to the point size being used in the paragraph. A global change to the document will help.
Submitters should try, wherever possible, to limit the size of an object such as a table or a diagram to a size which is equal to or less than the size of the common printable area of A4 and 8.5" x 11". The dimensions of this area are defined in Annex A of ISO/IEC JTC1 N5348: "JTC1 Policy on Electronic Document Distribution Using the World Wide Web", 1998-02. It is important to note that the sensitivity of word processors to changes in a document is such that changes of as little as 0.3mm can be sufficient to cause re-pagination of the document. Attempts to keep within the common printable area may therefore not be sufficient to prevent re-pagination taking place. If it is deemed to be of great importance to maintain the same pagination over different paper sizes, then consideration should be given to using the PDF file format as specified in 4.1 of JTC 1 N5348.
Many of these factors, as well as other important considerations associated with both moving to Microsoft Word and from one computer platform to another within Microsoft Word, are treated in detail in the on-line Microsoft Office webpages to be found at http://www.microsoft.com/office/ork/021/021.htm. Converters and viewers are available from the http://www.microsoft.com site.
Preparers of documents using Word for the Macintosh 5.1 should pay specific attention to the following points in order to increase the probability of trouble-free document distribution to other environments.
Word for the Macintosh 5.1 contains a filter which enables pictures generated on a MAC to be saved in PC Word format. The equivalent filter is not present in Word for Windows 2 or Word 6 in a PC Windows environment. Accordingly MAC Word 5.1 documents containing MACDRAW graphics should be saved as Word for Windows documents before attempting to export them to a PC environment.
Fonts used in drawing objects may not be preserved when moving from a MAC to a PC platform. Although it may be possible to edit the drawing and change the fonts, doing so on a PC may cause links to be lost. This difficulty can be minimized by a judicious choice of fonts at drawing creation time (see the font section ). There is a Truetype (TT) font for the MAC which is identical (from an identifier standpoint) to the Windows fonts (e.g. Arial TT). The easiest way of ensuring, in a MAC environment, that font conversion problems are minimized is to use the MAC version of the Windows fonts. These fonts are distributed with PowerPoint, but may also be purchased separately.
If conversion cannot be avoided, then the non-graphics fonts convert as defined in the font section, but the fonts in pictures convert to printer fonts which may well cause editing difficulties where Adobe Type Manager is not used. Printing difficulties may also occur where the printer fonts (PostScript Type 1 or 2) are not available.
There are a number of considerations on the preparation of documents created in WordPerfect 5.x (5.1, 5.2 or 5.2+) to be imported into Word 2 and Word 6. The character sets which can be successfully translated from and to WordPerfect and Word are the common sets of characters found in ASCII, Multinational 1 & 2, Box Drawing, Iconic Symbols, Math/Scientific Basic and Extension sets and Greek characters.
The website mentioned in the Microsoft Word specific section above http://www.microsoft.com/office/ork/021/021.htm is a useful source of information to use in minimizing difficulties when moving from one word processor package (or platform) to another.
When documents are intended to be distributed in text format, particular attention should be paid to the following considerations:
Adobe Acrobat software permits access to documents in their original form, independent of computer platform. With the Acrobat Reader, it is possible to view, navigate, print and present any Portable Document Format (PDF) file.
Acrobat Reader is distributed as a no-charge, licensed product and the latest version (3.0 at time of writing), maybe accessed from the Adobe homepage on the World-Wide-Web at http://www.adobe.com
It is permissible to re-distribute the Acrobat Reader program provided that the Read-Me file containing the license agreement is also re-distributed. The Read Me file contains installation instructions and product information for the Acrobat Reader program. There is also an On-line Guide (help_r.pdf) which provides essential information to help a user to begin using Acrobat Reader 3.0.
If redistributing Acrobat Reader, users should place the Read Me file standalone in the directory with the acroread.exe file to assist the end user with installation of the program. This file contains the following topics:
1) New features in Acrobat Reader 3.0
2) Installing Acrobat Reader
3) System requirements
4) Using the Weblink tool with Acrobat Reader
5) Known Problems
6) Creating your own PDF documents
7) Technical support
8) Electronic End User License Agreement
It should be noted that the ability to create PDF documents (in contrast to viewing and printing) requires the use of other at-a-charge software available from Adobe Systems Inc. More information can be found on the Adobe homepage at http://www.adobe.com
The recommended Compression/ De-Compression mechanism is to use PKZIP or PKZIP-compatible software. An uncompressed file or message should state which files are compressed and to indicate if any optional aspects of PKZIP have been used. Note that compression is an optional capability which is used for efficiency reasons and its use should be considered when a file in excess of 500KB.
The following software packages, in addition to those mentioned above, have been found to be of use for encoding/decoding in a Windows environment.
WinZip will zip and unzip files in the usual PKZIP form but also in LZH and ARJ formats. The latest version, WinZip 6.2, was released in October of 1996. This version allows the opening and extraction of UUencoded, XXencoded, BinHex, and MIME files. These files can be opened via the File/Open dialog or via drag and drop. WinZip 6.2 includes WinZip Self-Extractor Personal Edition. Both 32-bit (Windows 95 and Windows NT) and 16-bit (Windows 3.1 and Windows for Workgroups) versions are available. More information, including downline purchase and upgrade availability, is available from the WinZip home page: http://www.winzip.com
The mail address is Nico Mak Computing, Inc., P.O. Box 919, Bristol, CT 06011, U.S.A..
Editors in countries with national alphabetical extenders should be aware of how this might impact the JTC1 distribution and filing of the documents in electronic form.
When using national versions of word processing software in fixed set layouts, etc. text in the national language could be passed on, for instance, in headers or footers.
Document originators should also may attention to whether the text preparation software uses any national characters as control characters, etc. as their use can produce unexpected formatting results.
Acrobat is a trademark of Adobe Systems Inc.
Adobe is a trademark of Adobe Systems Inc.
Eudora is a trademark of the University of Illinois Board of Trustees, licensed to Qualcomm Inc.
IBM is a trademark of the IBM Corporation
Microsoft Word is a trademark of the Microsoft Corp.
Macintosh is a trademark of the Apple Corp.
PKZIP is a trademark of PKWARE Inc.
Portable Document Format (PDF) is a trademark of Adobe Systems Inc
PostScript is a trademark of Adobe Systems Inc.
PowerPoint is a trademark of the Microsoft Corp.
TrueType is a trademark of the Apple Corp.
Unix is a trademark of X/Open Corporation.
Windows is a trademark of the Microsoft Corp.
WinZip is a trademark of Nico Mak Computing, Inc.
WordPerfect is a trademark of Corel Corporation Ltd.