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.