The Vision for pvPlayer
The purpose of this is to explain why your work has always been so exciting to me
and how it dovetails with mine.
I believe we are on the verge of doing something important,
so this explanation is timely.
I am always excited by what I'm doing
and sometimes ignore what somebody would say is good business sense,
however, so please filter my thoughts through your own vision and business sense.
Marshall McLuhan (sp?) said a few decades ago "The medium is the message".
I just typed that expression into Google and got "about 1,890,000" responses.
I can argue that it is, or I can argue that it isn't. Regardless,
I believe that the following strategy is emminently sensible.
Our storage and use of content (resources) should be platform independent.
Our facility should evolve as platforms change and new technology makes newer and better work possible.
We shouldn't have to hire somebody to convert all that good content to new technology.
So, here is my view of what we both are engaged in.
- Content (if it is valuable content) should be stored in unadorned format;
that means text vectors with some minimal markup (html), tif images, etc.
Archiving should absolutely be done in formats that are permanent and simple.
For me, even content (resources) I use frequently is stored unadorned.
- How we use resources should be easy, even for non-technical people.
To make this possible we need a scripting language.
are a path consistent with my views. Eric Lescasse's "Objects" are a wonderful example,
but presently not applicable outside of Windows.
I'll use an adaptation of NewLeaf/RainPro syntax as revealed in "ContinuousDocument"
together with work I've been doing with Bill Parke and earlier with Eric Lescasse
to create scripts which allow us to easily move among several platforms.
Using a "gallery" approach, I hope the scripts can be easy enough for a non-technical person to write,
or for an apl function to write based on prompts the non-technical user will give.
Platforms I'm working with are these.
- 1= lineprinter (simple apl literal matrix display, my traditional way)
- 2= NewLeaf/RainPro postscript (based on "ContinuousDocument")
- 3= NewLeaf/RainPro PDF (with high security and the ability to e-mail reports) (SVG later)
- 4= Excel (based on Eric Baelen's work)
- 5= Windows/APL2000 grid control/Objects (my work with Davin Church, Eric Landau)
- 6= Formula One (version 5 distributable as implemented by Eric Lescasse)
- 7= HTML/HTM2000/not on server (based on the work I've been doing on the web)
- 8= HTML/HTM2000/Jscript/Jsave for use on an internet server (inspired by Fred Waid)
- Why develop in multiple platforms ? Because each has elements of the script notation to be
integrated and because each platform has features especially applicable to one project or another.
For example, for serious data entry, Formula One might be better than the APL2000 grid control.
Comment on postscript. Postscript appears to be the common printer language that
all desktop publishing systems produce (send to the printer).
PDF is a form of postscript.
Comment on VML, PDF & SVG formats.
VML formats add a title & a frame which look nice for a chart but
they do not look nice when used with a report that is many pages of text.
Yup - VML is a bit of a Microsoft Kludge, it only controls the drawing
commands, so the text is placed by old-style CSS2 absolute positioning. This
means you are working in 2 completely different co-ordinate systems and
things get misplaced.
Rain compromises here and there and gets away with it!
I think the answer is almost certainly multi-page SVG for on-screen viewing and
PDF for electronic distribution (email attachments and downloads).
Shortlist of HTML syntax
Formats used by Causeway
Comparison of Platforms on Size