On-line document writers should have the possibility to include moderate numbers of graphics or pictures in their documents. Why only moderate numbers? Simply because graphic files have two minor drawbacks:
Drawbacks inherent to inlining of graphics could be minimized by using vector graphic languages like FIG, supported in UNIX X-Window System. The graphic editor xfig implements many useful functions.
xfig enables saving of drawings in many different formats, FIG would take advantage of ClearCase, but forces the users to dynamically generate a GIF file for each FIG drawing. This would imply creation of a building process, probably implemented in a makefile attached to each document or document node. This somehow slightly complicates the process, and direct production of version-controlled GIF files, without saving FIG files, may sound easier to implement, at least in an early implementation phase of the Internal Documentation platform.
FIG drawbacks:
In any case, these drawbacks should not be fatal to insertion of graphics in HTML Internal Documents.
HTML Web browsers often support GIF, JPEG and sometimes other formats, even animated videos or sounds, JAVA applets, as well as scripting languages extensions like JavaScript. These pictures are actually always implemented as separated files but should be considered as source parts of the document, and, like any other HTML file, be always version-controlled. This is the case for inline pictures, but of course not for external links, by definition located in non managed server sites.
A major problem with all inline pictures is the lack of editing or creation facilities provided by most Web site editors. Thus, solutions for creating graphic files have to be found and must be investigated. In particular, legacy documents may requireMSto GIF or JPEG format converters .
Few Web page editors support: