On SVG (X)HTML etc, for Distance Education and Related Areas ------------------------------------------------------------- Here are some remarks on role of SVG. I believe this is very important We have perhaps 3 ways of specifying Information that are relevant 1. Information as an Object: This is illustrated best by IMS and ADL SCORM or by GXOS locally This uses XML to specify meaning of information 2. Information Optimally Presented or Information on the Printed Page Here SVG and at a lower level PDF gives you precise specification where graphics and text are to be placed for (in the eye of the author) maximum value. DHTML (with
and ) also address this issue at level of text and bitmap/JPEG/GIF type images 3. Information Readily Available Here (X)HTML and Browsers provide a convenient way for presenting Information in an easily authored and easily viewed fashion There is in general no way of knowing "exactly" how page will look in a given browser and how different components of a page will be aligned with each other. Constraints or Requirements from User (Distance Education) 1. Distance Education will promote (demand) higher quality web-based curricula material because more students allows more funding for authoring and technology will allow greater competition. This suggests "winners" will have more students and better quality curricula than now. This suggests one use "Information Optimally Presented" and not the more informal browser. 2. Universal Access. Curriculum should easily be retargeted between PDA's and PC's and between users of different sensory optimizations. 3. Collaboration technology is heart of distance education and especially for synchronous learning, it is not trivial to share material. There are three types of sharing: a) Shared Display b) Full Shared Application and c) Shared Export a) Shared Display is clumsy especially if "sharee" has lower resolution than original display. b) Shared Application. This is technically hard as one needs to trap each event in Every application one wishes to share. c) Shared Export. This is like b) but we export "all" applications to some common intermediate form where we produce some elegant collaboration system. I see b) as common use now and as very promising with SVG in future. Note for PowerPoint, Centra (like Tango) uses GIF/JPEG export and WebeX uses some patented technology which is perhaps equivalent to PDF Export. GIF/JPEG Export has two problems: Voluminous size compared to original and does not easily scale. (need to export multiple resolutions) PDF automatically scales but is also very voluminous and cannot easily be "cut-up" into components for natural way of displaying on PDA's. I built a very good shared browser (HTML export) but one major limitation is that layout client dependent. Therefore this only preserves "overlays" (pointer and highlight) between identical browser environments SVG is attractive for shared export as it is Scalable; Has a well defined DOM so can be cut up for small clients; Is minimal voluminosity as uses Vector graphics where possible; has deterministic layout so overlays (also naturally done in SVG) can share client dependent coordinate transformations. 4. Compared to "corporate web pages", education needs produce a lot of high quality pages "quickly" (So can keep curriculum up to date). For instance a single lecture is likely to be say 20 pages and a semester course totals from 500-1000 pages. It seems impractical to author these "elegantly" with a GUI system needed to customize each page for layout -- rather one needs some way of reusing a "high quality skin" with different text. SVG versus DHTML ****** Looking at PowerPoint 2000 Web Export you see that MicroSoft represents text as either DHTML or as VML (SVG for our purposes). Netscape 6 uses DHTML version; IE5 VML and both work. DHTML does not represent the PowerPoint Graphics. DHTML text scales in a similar way to SVG. Note in export, only one line of text is allowed in each box. This way we do NO text layout (breaking of lines and spacing) when rendering PowerPoint 2000 Web Export FrontPage MacroMedia Adobe etc. ************* Systems like FrontPage produce pleasing non scalable Web Pages using very complex HTML involving tables and a slew of spacer images. The resultant HTML is unreadable and editing requires one to go back to FrontPage. My experience with a diverse set of Authors and use of FrontPage and NetObjects Fusion is that this is not a good technology. One needs distributed editing and in a University environment one cannot and should not require everybody to use a given Authoring environment. Macromedia and Adobe products produce the best Web Pages with Macromedia the leader with Flash. Adobe already produces SVG for their core products and hopefully they will soon add this to GoLive. They also have an SVG plug in for IE5 and Netscape 4. Netscape 6 is meant to support SVG directly but this didn't work when I tried it. I assume that in the quite near future we can assume 1) Leading Browsers can (with plug-in) support SVG 2) Adobe will support SVG export for their major products. Flash (Shockwave) appears attractive for authoring and produce the best web pages today. It has two serious disadvantages 1) Flash is a proprietary binary format 2) There is weak support for re-use of Flash "skins" between different curriculum pages. Macromedia Generator does a few things but my preliminary conclusion is that is quite inadequate to allow multiple curricula pages to share a high quality Flash "skin" I think SVG and Adobe will force Macromedia to either switch to SVG or make Flash an open non binary format. I think it is relatively trivial to build tools on top of SVG (or some future open Flash) to allow much more powerful authoring environments which separate Curriculum from elegant rendered display. I assume that open interface will allow multiple academic and commercial activities in this area. Further Remarks *********************************** 1) I am not ceretain but I think we can reverse Engineer MicroSoft's PowerPoint 2000 export and convert it into SVG 2) I think that SVG will not support layout of HTML in SVG "boxes". Here an SVG Box differs drom DHTML
and . 3) Note Mozilla Gecko (open source Layout engine) is meant to support SVG and latest HTML 4) One can produce Scalable Text Output either with SVG text boxes or with HTML
Microsoft uses div and span for text and VML (SVG) for vector drawings and in IE5, exported PowerPoint scales nicely 5) So I am unclear exactly best way of defining a "Virtual Environment" -- a 2D world containing various components. What is outer shell -- a Browser or an SVG viewer. I think in many ways an SVG viewer is most logical but I think a browser (Gecko layout engine) can invoke an SVG viewer but NOT vice versa. 6) Excel exports using HTML tables for text in boxes. If you have placed Windows Meta files (e.g. pasted from Powerpoint) in Excel sheets these do NOT seem to be exported in same way as PowerPoint. They do use some VML and some wmz (Compressed Windows Metafile) I have not checked Word export in detail.