LinguaGrafica
Thursday, July 31, 2003
Now here's something interesting...
I came across an interesting product today—Lazlo Systems. I haven't had much time to really look at it carefully yet, but I found some interesting references to SVG on the Lazlo developer board. It seems it is a mix of XML, JavaScript, CSS, and Flash for developing rich media that is delivered in the Flash MX player.
see This lead to some interesting postings from Macromedia's Mike Chambers. Note, Macromedia is apparently also has their own designs on the same market with a product code-named, "Royale".
This certainly starts to explain why Macromedia people like JD and Mike have been frequenting the SVG forums for the last year or so.
Saturday, July 26, 2003
Article about Corel's "Smart Graphics"
Source: http://www.globetechnology.com/
A good article about Corel's SmartGraphics products. However, I was a little disappointed by the article's conclusion. It suggests that the only SVG Viewer is Corel's SVG Viewer which is, of course one of many including Adobe's , Batik's Squggle and mobile viewers like Bitflash. By omitting these other viewers, it makes Corel's products seem dependent on Microsoft (IIs web server, and client platforms). Of course, SVG is not dependent on Microsoft platforms for success and Corel's only current limitation is Microsoft for their server--which they could easily port to Linux, Unix, etc. if they chose to and at SVG Open last week, I had the impression from their development team that is on their radar for a future release.
Monday, July 21, 2003
Keynote--The next Generation Web Client Chris Lilley
Chris continued discussing a theme that had come up during the week. Netscape has ended it's involvement with Mozilla with the exception of $2 million in guilt money (my comment, not Chris's) Microsoft's announcement that Mac IE is no more and that IE for Windows is 100% part of the OS means we are in a different world. Moreover, Since there will be no IE release until Longhorn(2 years?) and mass adoption won't happen for a year or two after that, Microsoft has said that innovation is over. This creates a potential vacuum for other to fill. Chris calls this "vacuum time".
This got my attention right off because I have come to the same conclusion over the last few months. Microsoft is clearly taking this opportunity to steal sever business by completely owning the client. This creates a risk to many companies who thrive on server and desktop products, as well as integration services.
Will big companies feel this threat and decide to invest in client platforms? I think so. If they leave it to Microsoft, they will be marginalized more and more over time as Microsoft dominates all segments of computing.
Then Chris talked about some differences between HTML and SVG. HTML specifies a file format. That's all. While SVG specifies a format, a reader (tools), and viewer (user agent). He went on to list a multitude of things that we have with SVG:
XML Namespaces -> XML -> Unicode -> XML Linking (XLink) -> SMIL animation -> XSLT -> PNG -> JPEG, CSS2 -> HTTP-> DOM. If you have all of this, how far are you from having a very comprehensive user agent? The answer is, you are very close indeed. And each incremental addition become easier rather than harder. Note, as I listened to Chris I bean to think about the possibility of a browser built this way. It could even support the ubiquitous Netscape 4.x browser plugin APIs to allow for backward compatibility with all of the old plugins including QuickTime, Acrobat, etc.
Note XML + CSS = picture of a webpage
However, SVG 1.0/1.1 had simple XLInk (that is only one target for a given link.) What's wrong? What happens when you have several desired targets like, Stock price, company home page, recent product release? It is ugly today, but not for much longer. We'll have multi-ended inline links!
What is missing from a user agent?
XForms XMLEvents XFRames SMIL audio/Video, SOAP, XPath
Now take a look at SVG 1.2.
Then Chris went on to some more interesting remarks. He noted quite unabashedly that plugins suck. He did thank companies like Adobe and Corel for their efforts, but he insisted that they suck out of necessity. Why? Because they are a poor concept. They treat whatever file type as a second class citizen. You can't inline SVG with other XML namespaces like XHTML or MathML well or consistently. You can't view source of everything. You have to keep SVG in it's own little box separate from the HTML. You can find text in a web page or in SVG but not both at the same time. Users have to know too much about where to look for content. Search engines are limited in what they can do. This was all very compelling to me--even though I was the Product Manager for ASV. The problem has always been that we don't have a lot of choice given Microsoft's lack of support and market domination. Also, legacy browsers will be a problem for a long time to come.
Now look at what an SVG enhanced client would offer: DOM, CSS, Text flow, font control, complete and precise layout control...a browser that finally gives people a reason for "upgrading" away from IE. Furthermore, RCC gives the ability to render arbitrary XML like MathML, CML, and GML.
MyVertialML + RCC = dynamic styling
NOT:
MyEditorML + RCC = not really SVG Export.
Now for the Really Big news!
Chris has organized the first of a series of SVG design competitions. This is an SVGT 30K MMS greeting card. Winner will get Google-Karma and a prize (a Nokia phone!) I have to say I was flattered that Chris mentioned my blog in his keynote. I think that may have brought me up to an audience of 5!
More contests will continue throughout the coming year and we will have a competition at the next SVG Open. Details will be posted on the W3C site soon.
WOW! What a way to end the conference.
Actually, that wasn't quite the end. There was some Q&A where someone quoted my comments on the "Branding" panel about forming a consortium. Chris called upon me to respond to this. Basically the idea is still being worked out, but if anyone is interested they should get in touch with me.
Lastly, I'd like to add to what others have said about the great people I met and enthusiasm I gained from being around them while at SVG Open. Without exception, these are amazingly bright, positive, and fun people. And thanks to all of the organizers who worked so hard to pull it together!
Keynote--The Art of SVG-- Phillip Mansfield
Phillip gave some excellent examples of how powerful CSS (style sheets) can be in SVG. One SVG can have several style sheets for different purposes. For example, FAX, Web, mobile devices. Style sheets can control layout of items as well as behaviors (e.g. mouse overs) and patterns. He even showed an example of a pattern that was created with a nested style sheet which was very clever.
Then, Phillip talked about how XSLT can transform any ML into SVG. He considers this valuable, whereas transforming SVG into alternate SVG with XSLT was not as good an idea. Examples of the former include GML, World 3D the XML for his presentation, and GUI web apps.
SVG styles are unique (compared to, say HTML styles). For example, markers and text can be styled. he showed an example of dashed lines with text as a marker ("cut" to show where to cut in an origami example.)
Then the reverse--using a text to create a marker. An example could be creating a custom SVG font with a character that looks like a bicycle chain and then repeating that text along the path and animating it. (this is my example actually.) Animation can also be controlled by style sheets for example a shimmering mirror or a moving light source. You can animate CSS properties like fill, patterns, and stroke.
He showed a clever way to use a gradient to create a chess board very easily.
Then Phillip challenged tool vendors to create a UI aligned with objectives, not SVG primitives. This was interesting because one of the problems with existing tools is so many of them do not treat SVG primitives as first class citizens. But I suppose one can't create a tool that is aligned with objectives without also considering SVG primitives. Anyway, he also suggested that workflows of these products be tightly aligned with the designer and developer. This is important. He specifically didn't suggest that developers or designers can do the job alone--at least not as well as they can do by working together. On the other hand, Phillip gave a rousing appeal for SVG Developers to become more knowledgeable about design principles by taking a design class. Then, learn to combine (SVG) features to archive your goals.
Develop the craft of SVG!
A Configurable SVG Magnifying Glass--Dr. Phillip Mansfield
This was a wonderful talk about how to build a magnification interface with nothing but SVG (and a little JavaScript).
I lost some of my notes when my laptop battery died for the last time...so here's what I remember.
The problem with many magnification solutions like ASV or some of the examples that have been posted which use a magnifying glass analogy is that you loose the context of the surrounding information. This is really undesirable.
So, Phillip came up with the algorithms for accomplishing a much better solution in SVG. Without MathML it would have been hard for me to represent them here, so I won't try. :) Phillip said that he would be (and probably has by now) posting the slides. He's not as sure about sharing the implementation. He has this thing about making money for his company and something about paying employees. I have to say that I like hearing Executives saying things like that for a change.
The examples were wonderful. Basically, you have two concentric circles where the outer one defines the edge of the magnification and between it and the inner circle you have a distortion field which gives a gradual change in magnification from the default to the magnified size inside. This allows the viewer to have the context of the information (e.g. roads and train tracks can be followed from outside the magnified area to the inside.
Phillip had several adjustable UI components including: the size of the magnification, the size of the distortion field, The magnification itself, and obviously the location of the magnifying glass. This UI has a multitude of uses for densely formatted information including maps, wiring diagrams, and Excel spreadsheets (see http://www.svgmaker.com/gallery/marketing.svgz for example.)
The rest of Thursday...
I spent the afternoon catching up on impromptu meetings. Not much I can share yet but I hope that some of them will turn into great news I can share soon.
“SVG in 3GPP” (sorry, I didn't get the presenter's name)
This talk is about SVGTiny and SVGBasic which are intended for use in mobile devices like small phones and appliances and PDAs respectively.
Example applications:
Custom Postcards (including a picture taken on the phone)
Cartoons
Applications (including games)
Tips for developing SVGT/SVGB content:
Pogressive downloading allows you to play a scene from a cartoon while the next downloads. Games also can be downloaded progressively.
Progressive downloading allows you to download the next segment (game screen, cartoon scene, etc.) while the previous one(s) are playing. Combined with compression, makes it possible to have complex content in “bite size chunks”. Disguarding the progressive download after it is done using gzip’s extended headers which can include information such as how long to keep the SVG aorund, should it be cached, etc.
Lessons learned:
Always test on every target device because of Perfomance problems, bugs, etc.
Make every effort to minimize size. Make use of the ‘use’ element, etc.
Never define complex animation in a frame by frme basis.
Be sensitive to the form factor (screen size, interaction points )
Consider use of text (size, etc.)
Use percentage based viewports (not fixed size) to accommodate numerous devices.
Beware of localization issues.
Why SVG? Two reasons: Nokia loves open standards and doesn't like licensing costs (of Flash).
“XHTML and SVG: Publishing with concept” Benjamin Jung
Benjamin comes from an “XML” “text” world. Now wants to solve more graphical publishing problems.
Intro:
Separation of:
Content
Transformation
Semantic, Links
Logic, scripting
Presentation
Why
Maintenance
Extensibility
Reusability
Consistency
MERC!
(Great acronym!)
Enabling technologies:
Presentation: CSS, XSL
Linking: XLink, Xbase, Xpointer
Semantics: Topics Mps, RDF
Structure: XML Schema, RelaxNG, RDF Schema, DTD
Syntax: XML Namespaces, XML 1.0
History of Textual publishing
General markup language (GML) and Document composition Facility (DCF)
SGML and Doc Style and Semantics Specification Language (DSSSL)
XML/XSL
History of Graphical Publishing
XML and XSL
Publishing Matrix
Concept Information Technology
Display Reader Open eBook
Rendering Printer CSS/FO
Metadata Editor XSLT
Content Author DocBookX
Schema Publisher DTD
Content flow -> can be flowed to:
CSV WML
DOC OEB
HTML HTML/CD
XML HTML/Web
DB PDF
Value: Enables multi-source publishing (both directions!) Even formats we can’t imagine today via transformations
Two image types
Real world images (raster) Photo/video
Hard to do much here
Synthetic images (vector) CG, CAD, etc.
Text/ Graphics/ Audio/ Video
Application Layer-XHTML PDF/SVG JPG/MIDI PDF/MPEG-4
Presentation Layer -> CSS, FO/ CSS/ Final Template/ MPEG-4
Transformation Layer -> XSLT, DSSSL, FXP
Content layer-> Structure->XML vocabularies (DTD, XML schema)
Syntax -> XML
Storage-> File system, XML, database
Authoring in SVG
Problems
Content does not fit SVG vocabulary (domain specific information like relationship (e.g. CML, GIS, etc)
Abuse of SVG vocabulary for content definition
Re-engineering into original data model is difficult, or impossible
Solution: Domain specific XML vocabulary and transformation into SVG
SVG is visualization of ‘ML”
Excellent point. Don’t loose track of semantic and structural information by mis-using SVG.
Rich Markup Language http://www.kinesissoftware.com
AnyML-> RVML->SWF OR SVG
Allows you to roundtrip but it seems like you first have to transform you’re your domain specific ML to RVML so I’m not sure if there is a “win”.
Easy to go from Rich content to poor (incomplete or “dumb” content). Harder to build information. (Point made via a raster by successively deleting first the color then, elements of the graphic.
It is hard to separate content like rasters:
Content
Abstract the description of the image
Transformation
Select, add, edit, and delete parts
Define and transform into user format
Presentation
Color schemes
Light
This is often domain specific (e.g. satellite photo different than crime scene photo (my example)
Autonomous graphics
Single source publishing
Single target format
(e.g. a Dilbert cartoon with localized text)
Integrated Graphics (data-driven)
Single source publishing
Multi-target (hand-held, print, etc.)
PPT example
Slide view
Note view
Web, etc.
Summary
Equivalent 5-tier XML architecture
Content
Transformation
Semantic
Logic
Presentation
“SVG, PDF and ImageViewer” Jon Ferraiolo
Jon began by going over the SVG world according to Jon and Adobe. This is useful context. As Paul (and Winston Churchill) said in his keynote, "The farther back we look, the farther forward we can see." well, that's a bit of paraphrasing I guess.
Pre 1982: Xerox [JAM]
1982: Adobe founded as a postscript company
1986: Illustrator – “postscript editor”
1993: Acrobat and PDF launched
1998: SVG started at W3C
2001: SVG 1.0 Recommendation, Illustrator 10, ASV 3
2002-2003: Photoshop Album & ImageViewer
The PostScript story:
A presentation language for printers
Open (I would clarify “published”) specification
Build a business around a common language
The Acrobat and PDF story
A presentation language for electronic documents
Open standard
SVG Story
The presentation language for the web
Open standard (again, I would clarify “published” is not the same as an Opens standard)
Strategy: Build Adobe’s brand as preferred implementer
Revenue model:
SVG workflows: Illustrator, document server, etc.
Future (?)
Additional indirect benefit to Adobe
PhotoShop Album (aka PSA)
Uses a few key files
Master-1up.svg
Master2up.svg
Etc.
(Templates)
The template builder (not available to the general public at this time)
Party Template.xml
ProperTemplate.xml
Etc.
AI is used to create template (1-up, 2-up, 3-up, etc.)
Then in album, you select a template that uses a DOM to pour photos into a template:
PDF+SVG
SVG autoplay CDs
VideoCD
Demo:
Use AI to create a PhotoShop album file. Using AI’s variables palate. Jon didn’t show how one actually imports a new template into PSA because this is not a step available to anyone outside of Adobe.
ImageViewer extensions (now in ASV 6)
Video
Transitions
Text wrapping
Cursors
Some drag/drop
Some on-screen text editing
Work as a plug-in to Acrobat and Adobe Reader
"Dirty details"
SVG provides alternate presentations in PDF
Other Acrobat/Imageviewer details
Note, right now, although SVG allows for a completely different (or "alternate" as Adobe calls it) presentation, this is not included in PSA 1.0. What you see in the slide show is the same as the PDF. This is pretty disappointing and makes the purpose for an alternate presentation less than obvious. However, the functionality for SVG to have real value inside PSA is now part of PDF and that is a wonderful thing.
New concept in Acrobat 5.1/6
First incarnation slideshow viewer
Image viewer plugin registers an SVG Viewer
Album-generated PDF file says to use SVG for slideshows
Bootstraps off of PDF/ Catalog
PDF can now have an “alternate rendering” for any content, which can be SVG. PDF is now a file system for ‘xlink:href’s Note, major assets (e.g. photos, audio, etc.) are shared between the PDF and SVG.
JavaScript trigger that is executed when Album PDF file is opened
Necessary to bootstrap imageviewer
Prompt user to download imageviewer if not installed
(More difficult than you would expect)
Floating annotation to rerun slideshow
(More difficult than you would expect)
Acrobat 6 has new multimedia plugin architecture in Acrobat 6
Supported by Imageviewer5
SVG can now be used as an annotation of PDF. This can be on top of part of a page, or cover an entire page.
Though I have been a little disappointed in PSA 1.0 as a product, Jon's talk inspired me to see many great things that can come in the future.
Thursday, July 17, 2003
Schemasoft did the Visio SVG import/export for Microsoft
Sorry for the poor formatting. This will be fixed soon.
Visio began 11 years ago Mission "Drawing and diagramming for the rest of us"
Original target for graphics was print
Support for "Web graphics" grew over time
Grown over releases
GIF, JPG, PNG, Save As Web" HTML/VML
So Why SVG?
Partly as a way to depreciate some of the 27
different formats that Visio currently supports!
Partly because SVG is powerful and can be extended (my summary)
Visio 2003 has:
SVG/SVGZ support
High visual fidelity
Text flow
Load SVG DOM
Iterate over elements, translating to equivalent Visio
construct using Bridger API to construct a VisoDoc
Scenarios:
SVG Open
Insert SVG (into an existing Visio document)
Demo:
Export AI document
Export CorelDraw document
Import both into Visio! COOOOL!
Then, ungroup them and move around pieces independently.
Some Limitations though:
Gradients
Pattern elements
Line pattern styles
Font glyphs
Clipping of text and markers
Text on a path
Filter effects
Interactivity (hyperlinks only)
SVG concepts not supported in Visio
Scripting
Animation
Aural & XSLT style sheet
Masking & Compositing
Conditional processing
Export:
SVG/SVGZ
High visual fidelity
<title> and <desc>
CSS and selectors
SVG relative units for text sizing and layout
Demo: Org chart export
Export Selected content
Export everything (default when nothing is selected)
Export multiple pages (uses "Save for web" (SAW)
option and you choose SVG instead of a raster
format.
All of the exports were fast and well done!
Export limitations
Custom fill & Line patters
Custom line ends
Font width scaling and text scaling
Image effects processing
Pre-defined fill patterns
Denoise image effect
Visio concepts not exported to SVG
1D shapes-return as 2D
Connectivity relationships are lost
Formula driven graphics (shame sheet formulas
are lost)
Visio extensions
Layers (retain layer membership)
Shadows (geometry that should not round-trip
Annotation overlay pages
Group/Shape/Sub-shape structure
Formatting
Fills--colors (fore/back, Visio patterns, Visio
shadow type
Lines--Pattern, Visio line types and ends
Images--brightness, contract, etc.
Foreign options
Images
Graphic metafiles
OLE objects
Non-graphic properties and semantics
Visio custom properties
Visio user cell data
Partner opportunities
Rich property data
Embedded Solution XML= embedded
solution/customer XML
Inlcuded & accessible SVG
Graphic representation for LOB apps & Data
Demo:
Manufacturer’s order status web site
Graphics status reporting using SVG
Back-end ASP.NET server
HTTP handler customizes SVG with status
SVG graphics are used to dynamically change a
graphic that shows the progress of an order tracking
system.
Next steps
Input to SVG working group based on experience
Improvements for Visio
Masking/clipping
Text on a path
Improved gradients
Support for text stroke & fill
colors/patens
Export
Custom fill & line styles, and line end
styles
Shape Sheet formulas
1D shapes and connection relationship
Round-trip
Animation
Scripting
Aural & XSLT style sheets
It was awesome to see what the next version of Visio will do for SVG. It was also wonderful to see any part of Microsoft embrase SVG. During the Q&A I asked if Microsoft would ship ASV (or another SVG viewer with IE or with Visio. The answer was no. There are also no plans currently for Microsoft to extend one of their other viewers (e.g. the VML player) to support SVG.
All in all this was a fantastic presentation and very exciting.
Schemasoft did the Visio SVG import/export for Microsoft
Visio began 11 years ago Mission "Drawing and diagramming for the rest of us"
Original target for graphics was print
Support for "Web graphics" grew over time
Grown over releases
GIF, JPG, PNG, Save As Web" HTML/VML
So Why SVG?
Partly as a way to depreciate some of the 27
different formats that Visio currently supports!
Partly because SVG is powerful and can be extended (my summary)
Visio 2003 has:
SVG/SVGZ support
High visual fidelity
Text flow
Load SVG DOM
Iterate over elements, translating to equivalent Visio
construct using Bridger API to construct a VisoDoc
Scenarios:
SVG Open
Insert SVG (into an existing Visio document)
Demo:
Export AI document
Export CorelDraw document
Import both into Visio! COOOOL!
Then, ungroup them and move around pieces independently.
Some Limitations though:
Gradients
Pattern elements
Line pattern styles
Font glyphs
Clipping of text and markers
Text on a path
Filter effects
Interactivity (hyperlinks only)
SVG concepts not supported in Visio
Scripting
Animation
Aural & XSLT style sheet
Masking & Compositing
Conditional processing
Export:
SVG/SVGZ
High visual fidelity
<title> and <desc>
CSS and selectors
SVG relative units for text sizing and layout
Demo: Org chart export
Export Selected content
Export everything (default when nothing is selected)
Export multiple pages (uses "Save for web" (SAW)
option and you choose SVG instead of a raster
format.
All of the exports were fast and well done!
Export limitations
Custom fill & Line patters
Custom line ends
Font width scaling and text scaling
Image effects processing
Pre-defined fill patterns
Denoise image effect
Visio concepts not exported to SVG
1D shapes-return as 2D
Connectivity relationships are lost
Formula driven graphics (shame sheet formulas
are lost)
Visio extensions
Layers (retain layer membership)
Shadows (geometry that should not round-trip
Annotation overlay pages
Group/Shape/Sub-shape structure
Formatting
Fills--colors (fore/back, Visio patterns, Visio
shadow type
Lines--Pattern, Visio line types and ends
Images--brightness, contract, etc.
Foreign options
Images
Graphic metafiles
OLE objects
Non-graphic properties and semantics
Visio custom properties
Visio user cell data
Partner opportunities
Rich property data
Embedded Solution XML= embedded
solution/customer XML
Inlcuded & accessible SVG
Graphic representation for LOB apps & Data
Demo:
Manufacturer’s order status web site
Graphics status reporting using SVG
Back-end ASP.NET server
HTTP handler customizes SVG with status
SVG graphics are used to dynamically change a
graphic that shows the progress of an order tracking
system.
Next steps
Input to SVG working group based on experience
Improvements for Visio
Masking/clipping
Text on a path
Improved gradients
Support for text stroke & fill
colors/patens
Export
Custom fill & line styles, and line end
styles
Shape Sheet formulas
1D shapes and connection relationship
Round-trip
Animation
Scripting
Aural & XSLT style sheets
It was awesome to see what the next version of Visio will do for SVG. It was also wonderful to see any part of Microsoft embrase SVG. During the Q&A I asked if Microsoft would ship ASV (or another SVG viewer with IE or with Visio. The answer was no. There are also no plans currently for Microsoft to extend one of their other viewers (e.g. the VML player) to support SVG.
All in all this was a fantastic presentation and very exciting.
Creating SVG Brand Recognition
Next was the panel I was invited to participate on. It was hosted by Chris Komnick (SchemaSoft) myself, Tim Bray, Rob Williamson (Corel), Richard See (Microsoft), Jonas Lindgren, and Alexander Adam. The conversation was good. In brief, we discussed the challenges SVG has faced in the past and some that it still has to over come. We also discussed briefly what we could do. I think I will probably discuss this in detail in a future blog--it is almost 3am and I want to finish up and get some sleep. However, one of my contributions to the discussion was that we need to provide a great deal more education about SVG. We need to get the press, developers and CIO/CTOs asking about it. The best way to archive this is probably not by having a single vendor beating the drum. Customers see that as too self-serving and if they believe that the "open standardness" of SVG is important they are more impressed if they see several vendors agreeing on a technology direction and delivering tangible solutions that provide value. Otherwise, they put off getting "in" until they are convinced that it is "real". Therefore, I suggested that an SVG consortium of some sort be formed to aid in the marketing and education of SVG. Others added that perhaps SVG "Branding" also be addressed. "SVG Inside"?
I believe that people found the session valuable and I was honored to participate. Several people commented that the session was far too short. They suggested the session should have been two or three times as long because they are all concerned about SVG in the marketplace. All week I have seen a lot of people walking around asking, "Why doesn't the whole world thing SVG is ready yet?" Perhaps we can start addressing this in a serious way soon.
To conclude, we wandered over to the Vancouver aquarium and had a wonderful afternoon seeing fish and enjoying the scenery. Later, 15 of us went to dinner and had more good food and lively discussion. (Mostly about Symbols, use elements, and markers. Compare/contrast and discuss amongst yourselves!) Later we debated the future of paper books and music CDs. But these are off topic for this blog and it is late so I will conclude for now.
SVG Working group Q&A
I wish I had seen this whole session. It is rare for all the Working group to be together in a public forum. Given the new things in SVG 1.2, this was a particularly auspicious time. Topics of interest were the Corel proposal for Script (standard GUI controls) www.corel.com/smartgraphics/resources/dSVG11 some issues regarding markers, and some requests for clarifications of issues in the spec. I haven't read the Corel proposal or gotten detail of the RCC stuff, but it seems that RCC may provide the benefit of the Corel proposal and a whole lot more. This is just an early impression and I could be wrong.
The single most significant take-away for me was that Chris and Dean urged everyone to contact the working group regarding 1.2 and especially areas like RCC and Corel's proposal. SVG Developers can and do make a considerable difference when the working group considers any given issue and resolution. My two cents: The time to discuss is now--not later and certainly not after the fact.
After lunch, a certain company (which I won't name) showed me an Illustrator plugin that could export animated SVGB or SVGT! The animation worked a lot like ImageReady's animated GIF palate. Also, I've seen many examples of SVG running on cell phones including Bitflash's player and a KDDI phone. If you haven't seen SVG on a phone, get ready. You will. The performance is quite good and the content examples range from great games (that are easier to create, port, and maintain for developers) and are spiffier than games currently on cell phones which often use Java and bitmaps. But SVG is not just games on cell phones. Maps easily provide location based services like the location of the closest pub or movie theater. Want to buy a ticket? why not? need to scan the ticket? Just display it on the cell phone's screen. Oh yeah, baby!
A side note: there is a great deal of SVG development that isn't public because it is going on inside companies and they consider it a proprietary advantage for now. This is understandable but a shame from an SVG-centric view because no one has a true measure of how big SVG is. (more later)
Time to Panel!
"SVG in Manufacturing: Current Possibilities and Future Perspectives" Rob Williamson--Corel
About a dozen people attended Corel's talk on SVG in manufacturing applications. In my opinion, this wasn't due to a lack of interest in the topic. On the contrary, I think this was a good example of the diversity of topics at this year's conference. Literally SVG is being used for everything from Origami to Rocket Science. WOW.
Some of Rob's observations:
Technical documentation is often a good application for SVG. Why?
Technical documentation must live 30 years in many environments. (that is, no dependencies on a particular piece of software, OS, etc.)
Must be simplified (because field crews may not or may not be technically savvy and their time is critical. (Save a technician 15 min/per call might increase the number of repairs completed in a day by say, 20%.--my example)
Problems in technical publishing: (some of these are my own filling in.)
multiple vendors
multiple systems (and versions of them)
standards (poor implementations)
multi-channel publishing (print, web, mobile, etc)
updates
collaborative authoring
standards (e.g. FAA, FDA, etc.)
Documentation systems
Rules and logic--business logic can be represented such as, inventory, quantity of a part required for an assembly, etc
Authoring
CAD Conversion tools
CGM Authoring Tools
SVG Authoring tools
Serving
CGM-SVG Conversion
CAD-SVG Conversion
Interaction (aka client side)
SVG Viewer
CGM Viewer
Who cares about SVG?
Users don't. Developers do.
Cost of tools cheap (relatively) and they interopperate easily (relatively)
By tying repair manuals to supply chain systems, you can increase sales. Interesting observation.
XML can save $2.5 M (annually?) in a commercial aircraft
(source: www.airlines.org/public... (looking for the URL but can't find it yet.)
"Wednesday morning at SVG Open" or SVG as we know it is dead.
Slept in a bit late because of the fun last night. (SVG folk know how to have fun and engage in great conversations about a wide range of topics. Also, this is one of the friendliest "conference" crowds I've experienced.
Unfortunately, there were more cancellations of talks this morning. Many people were upset by this and felt let down by the presenters they were interested in hearing from. On the other hand, there is often just as much value and enjoyment from just being around so many of the famous and infamous SVGers and seeing their SVG on every laptop you walk by the hallway and the computer lab, lobby, etc.
<rant>(Not enough wireless connections and not enough room in the lap! Also, not enough power outlets in the conference rooms. Laptop batteries just don't last long enough.</rant>
WE MUST HAVE AN SVG HACKING CONTEST at the next SVG Open. :)
The 11 am sessions were too hard to choose from. The most popular seemed to be Jon Ferraiolo's talk on RCC. The room was pretty well packed. As everyone knows, RCC is pretty damn exciting stuff. SVG as we know it is dead.
Yes, that's right. This is not your Dad's web graphics format anymore. SVG is now approaching (or become?) a true programming language that happens to be targeted at delivering web applications (aka web services). Can it do other things? Of course...too many to mention here. At least now. Bad news: If you thought you knew everything about SVG you don't. Good news: So many things are going to be easier to build now.
The ability to render arbitrary XML inside SVG and some of the other changes discussed mean that SVG is not just a graphics format (if it ever was). It isn't just an XML markup for graphical (and textual) information. It is really an application development language for interactive, dynamic content that is often web delivered (via a browser or not--but using appropriate web protocols and standards. I don't think the full implications can be fully appreciated until we all start to play with the new capabilities. (more on this later.)
I confess, I actually didn't go to Jon's talk because there were a few other talks that were compelling and I figured that I could get Jon to show me some of his presentation later. (Actually, I believe it will be posted if it hasn't already.)
Wednesday, July 16, 2003
Miscellaneous Tuesday ramblings
My apologies for not being able to post sooner. In fact, I haven't the time to post extensively right now either. :) There is just too much great stuff here at SVG Open. I will do a quick rehash of yesterday.
Yesterday's keynotes were really interesting. Tim and Paul both gave wonderful but someone different views on SVG and its future. I will comment more on their conversation more later. Right now I have to think about what I will say in the panel I was invited to this afternoon and get over to some great sessions this morning such as, “Rendering Arbitrary XML in SVG 1.2” by Jon Ferraiolo “SVG in Manufaturing: Current Possibilities and Future Perspectives” by Stephen Kingston. Unfortunately I have to choose between several great topics.
After the keynotes yesterday, I intended to learn about ShapVectors. However, I made the mistake of popping into the Exhibit floor and ended up spending the entire afternoon talking with people I knew and a few new ones. (Actually, as it turns out I heard the Sharpvectors talk was cancelled so I didn't miss it afterall. Oh well.) Perhaps the most interesting new product was www.MOBIFORM.com. They have a C# SVG viewer that runs on Windows and Pocket PC. It is tiny, (few hundred Kb I think) and has a binding to C#. This opens up some very interesting possibilities for web application development. There are some limitations too, though currently. It isn’t a browser plugin, it depends on C# (no JavaScript or Java bindings), and it doesn’t have full support for any of the SVG specs yet. But the performance was good, and it was able to demonstrate how a protocol like SOAP can be used to deliver SVG DOM information (the “y value of a few ‘rect’ elements) to a web service and have the web service return a computed value back to the DOM (a ‘y’ value for another ‘rect’ element) to create an animation. Very interesting possibilities. Hmmm….
Well, after some really great conversations, it was time to go out on the boat cruise on the harbor. This was a great time— beer, wine, some good food, more interesting conversation, etc. The cruise was very nice and just about the right amount of time. When we got back to shore, a dozen of us went bar hopping. My wife and I hung out until about 1am and then a bunch of us called it a night. Several people partied late into the night, including Mike Kidson, Ronan, Chris Komnick, Don Liberty, and Seth. I might have been easily persuaded to hang out with them until 3 or 4, but as it was I knew it would be hard to get up this morning. Sure enough it was hard to get here before 10 so I missed the first round of talks this morning. Now I’m off for now! More later.
Monday, July 14, 2003
"Building Smart Graphics Solutions with Corel Smart Graphics Studio"
Presented by Tom Hoferek, User Interface Designer
Back from lunch and I’m refreshed and ready to hear what Corel has to say about their spiffy SVG authoring tool!
Tom began by clarifying that he isn't a developer so he might not be able to cover some really detailed questions.
What is Smart Graphics Studio?
Allows a designer to use an SVG authoring tool (e.g. CorelDraw) to make static SVG dynamic and interactive.
Components of Corel’s SG Studio:
Developer SG
Server SG
SVG Viewer
All are essential to making a “Smart Graphics” solution. (E.g. requires the Corel Server to work and it only runs on Windows IIs.)
Project components
SVG template
Data mapping
Dependencies
Processes
Data sources->Process->data mapping->template
My first question: (How dependent on Corel apps is the template creation?) I was eager to find out. After listening to the presentation, I’m not sure I can say for sure.
Modular design was the goal: don’t bind directly to an SVG—but rather allow, “loose coupling” (my description) of data to SVG. Also this allows designers to design and developers to develop. This is great! It is definitely the right approach to a Visual Integrated Development Enviornment (or VIDE in case I ever refer to that again :^))
You can open one project at a time but a project may have more than one component and you can open many components at the same time.
Workspaces:
Design Editor
Template builder
Data mapper
Example: Draw a pie chart in CorelDraw. Use object and layer names, which are later bound to data in Developer SG. More on this later.
You then go to Developer SG and include the exported graph. Developer SG provides a DOM tree view, a code view, and a “preview”. Some surprises: for example, you can’t rearrange the tree view to change the Z-stack. You have to do it through the graphical view only. Also, the preview mode was amazingly slow even for a simple object. Also, some of the dialogs that look modal aren’t, etc. Okay, the Developer SG’s UI is a little rough around the edges. I’m sure that will come with time.
(The code view looked rather limited and unfortunately there is no way for a user to define a code editor of their choice and launch it automatically from within Developer SG. There is also an ability to click on an object and edit its attributes ala JASC’s WebDraw.
When you create an element it is given a default value for all required attributes but there is no designation per se of required vs optional attributes.
You can add buttons, checkboxes, and other GUI elements—“DSVG” elements (Dynamic SVG Elements). These are combinations of SVG and JavaScript that are written for the developer. There are also “behaviors” which can change an object’s attributes (e.g. display, color, stroke, etc.) to activate these, you have to know an “ActionScript” like language which is no doubt documented somewhere. For example, “callback” was apparently one method to say do something after an action had occoured such as a mouseover. However, there was no easy dropdown list in the Developer SG interface nor did it follow any standard convention (like using a JavaScript function call).
There is no interactive way to make these changes. For example, you can create a button (a DSVG element) with a behavior (hide a rectangle on the page). However it is unlike ImageReady where you set things the way you want them for a given state of a rollover, etc. and there is no way to select the target of an action. Instead you have to set things things manually. Tom reminded us that this is a 1.0 product. J
As you would expect, behaviours can be added to any object (e.g. a circle, rect, etc.)
Tom claims the behaviours and UI elements work with ASV but he couldn’t show us because he didn’t have ASV on his machine. This was understandable for technical reasons, but I’d be skeptical about using these elements until I was satisfied that they did work reliably with ASV because the Corel viewer has no distribution to speak of at this time.
You can also add “tooltips” to any object.
Demo:
Draw a simple (static) bar chart in CorelDraw. Import to Designer SG. Modify the lengths of the bar chart and put the value of the bar at the top of the graph. Tom chose to create four different text elements for this instead of changing the value of a single text element. I’m not sure if this was just to simplify the demo or because of some limitation but it seemed to me that this should have been a relatively straightforward type of thing to do. Next, you go to the template builder and find data sources to bind to the dynamic elements. Here you can add a range of functions like concatinate, round, multiply, subtract, min, max, etc. To paint a picture, this sort of feels like a Flash ActionScript window but lacks autocompletion. Instead, users are encouraged to drag functions from a pallate.However, unlike ActionScript, you don’t seem able to just edit the text. Some developers may feel constrained by having to use the Corel enviornment for all of this editing. Repetive tasks like assigning a behavior to several objects seem a little arduous in the current UI to me. However, some may feel liberated by the drag-and-drop nature and it means no typos. Next, you actually select a data source, and then you have to “compile” the SVG component. This gathers the files you need together. I’m not sure what else happens behind the scenes. It seems to try to take care of making relative paths so you can relocate you project from a developent machine to a production server, etc.
Currently, you can copy a single behavor and paste it to several objects, but not multiple behaviors at once. This is on the list of things to add to the product in the future.
All “behaviors” are JavaScript based (none are declarative). This might make it more difficult for Corel Smart Graphics to be viewed in some enviornments (e.g. SVGT) Also, there are currently no “profiles” that you can write out to such as SVGB, SVGT, Batik, or a developer-defined profile.
You can make any object dynamic at any time. There is a “Dynamic Elements and Attributes” dialog, which allows you to organize all the dynamic elements (e.g. text, strokes, etc.) in whatever way you wish. You can also see these dynamic attributes in the DOM view.
The Corel tools are a very nice start. I’m not sure they are quite ready for prime time—at least not everyone will find them to be up to par but some early adopters may find that they make the job a bit easier.
I asked Sara what she thought of SG Studio because she’s a good representative of a designer who even happens to have some interest and experience with SVG. She felt that it was far too intimidating for a designer. I’m not sure that it is quite right for a developer either. Perhaps this will all come with time and refinement.
Well, the sessions are done for the day. Time to see about having some dinner and fun.
Other Sources:http://www.globetechnology.com/servlet/story/RTGAM.20030718.gtfrontlinesjuly18/BNStory/Technology/
Jim Ley's talk "Getting the server involved in SVG"
As can be expected, Jim did a wonderfully through talk on using servers to create SVG. As also can be expected, Jim was not shy about sharing his biases on certain topics.
Jim's session was well attended--something over twenty some odd people crowded into the small room.
GetURL and PostURL have some serious limitations. For example, they don't return errors such as page not found. Therefore, you also can't parse an error to see if perhaps there was useful information about the error and take appropriate action.
Jim talked about the whiteboard example he posted on SVG developers a few years back. (I had sort of goaded him into creating that example and was very pleased indeed he had risen to the occasion.) Because the common web protocols lack the ability to "push" data down to a client, this is a difficult task unless you use something like a Java applet to listen to a port and keep a connection live. An SVG whiteboard simply requires too many "pushes" of data on too frequent a basis to too many clients to scale well. Jim also complained that GetURL doesn't allow the use of the HTTP timestamp which would allow the server to say if something new since last time, send so this has to be done more manually.
So, why send SVG to the client? Or as I would ask, the question *when* do you send SVG to the client? Why not use an intermediate format of your choice (XML?) to send a format appropriate for the client or application (e.g. HTML for a legacy browser, XML for a web application, or SVG of one sort of another for a desktop or SVGT or SVGB for a mobile device. Using an intermediate format on the server makes the content for more reusable for a wide variety of applications.
For browsers, Jim urged not using XML but rather use JavaScript Object Notation (JSON) because it is exceptionally fast. However, sometimes XML is really the only choice--such as with web applications.
Jim loves RDF. He's applying it to wide range of applications and finding it very useful.
He opined that XMLHTTP would have been superior to GetURL because it includes more information about headers, encoding, etc.
Next, he suggested that we not bother with using the ability of viewers like ASV to talk to the browser. Jim's stated that this only works on WIndows IE which is a bit of an overstatement, but it is true that there are some tricky issues to making this work reliably. Jim prefers using GetURL directly instead of going through the browser.
Time for lunch!
SVG DOM for Mobile
SVG has several profiles besides "full"
SVG T (tiny)
SVG B (basic)
Both are proper subsets of SVG Full. SVGT lacks elements that require more footprint or processing power than typically found on minimal devices (simply cell phones) SVGB intended for PDA class machines and "Nokia Communicator" level phones.
SVGB has two additional profiles:
Basic DOM
Extended DOM
A JavaScript binding is not required for the basic DOM because of the significant difference in footprint and the constraints of the target devices. (JavaScript doubled or tripled the client footprint)
C++ is the preferred DOM binding because of efficiency.
Example Application: BeSmiled (styled after "Bejewled" by PopCap games or Diamondmind on PocketPC
SONY Ericson 210 Mhz processor running Symbian OS
Nokia 7650
SONY P800
Notes:
Original application had no animation
Input stylus or trackwheel.
Sample application written all in SVG including logic and rendering
Demo requirements:
Fast execution
Responsive UI
Smooth animation
small footprint
port to at least three devices
show internationalization and localization
How did the port compare?
Component Size (kb)
App code 33
Mobile SVGB DLL 282 (150 SVGT DLL)
Data 28
Total 345
PocketPC "Bejeweled" 540Kb
Note, the SVG version could have been 61k if the SVGB DLL was already installed on the phone
Porting time for each platform: 1 day
Implemented in Russian and English
The BitFlash SVG Viewer is ~150K (SVGT) and ~280K (SVGB)
by modifying the DTD, Bitflash can create custom solutions for a customer. For example, adding JavaScript or gradients to an SVGT implementation.
Why use SVG over Java for game development?
Smaller
Animation (Java apps often depend on rasters (perhaps because of the difficulty in designing custom Java graphics?)
Java graphics are harder to port: SVG scales easily to different viewport and preserveAspect ratio
Easier to port because the SVG DOM abstracts any device specific logic
The game was developed with three screens:
Title
Main
High Score
The application required 7 emocons which were defined as symbols and used throughout the game for greatest efficiency. Note that this allowed for a high degree of maintainability:
single code source for all devices
designer (graphics) and developer (logic) could work in parallel and new versions of the game could be developed (e.g. skins, branding, etc.) without touching code.
Time for a coffee break.
Unfortunately, I met up with Sara, Ronan, and assorted other people while having coffee and never made it back to finish the session. This was no reflection on Andrew's talk--it was simply that I was having far too good a time.
Nine of us went out to dinner at a Greek restaurant named Kalypso which was wonderful. They even allowed Seth's dog "Svig" in. He was well behaved and stayed under the table the entire time. Pictures to follow soon!
Sunday, July 13, 2003
Missed the morning sessions unfortunately (I was too tired to get moving that early) but this afternoon looks very promising. I plan to go to the second half of the XSLT Quickstart--although the Cross platform applicaiton development using the Mobile DOM looks very tempting. Hmm... choices, choices.
So, here is my BLOG from SVG Open. Note, they are not meant to be complete. Partially because I assume the presenters will post the slides and there is no way I could do justice to the presentations in such a small space and the time I have between some really great presentations. Rather, these are meant to give a flavor for what I learned and my thoughts as I went through the sessions.
By the way, I hope that this will inspire discussion and that people will correct me where I've gotten something wrong. Particularly the presenters since I'm summarizing their words I'd like to be as correct and fair as possible.
