I apologise to the list, but I cannot help but add more on a slightly dif= ferent aspect of my previous post.
And I must add a strange rider on oddities in how I am presenting things.= 1) I have not attempted to learn REBOL yet, let alone script with it, in = fact I am confining myself to reading about it. 2) I will learn REBOL from the basics up when R3 appears, the reason is s= imple, I intend to write a conceptual introduction to REBOL, based on wha= t I learn in practice, as I am leaning it (for the simple reason that cap= turing the moment of understanding soon escapes when the knowledge is est= ablished, I need to make notes as each idea sinks in rather than try and = reconstruct it inaccuratetly - I believe REBOL is significantly different= from other script langauges and that there is a gap in documentation tha= t needs to be filled). So I only know REBOL in outline at this time and no-doubt my inexperience= is fairly obvious, and could be annoying to some. There is an advantage = however to comming from the outside - though I may say things that are pr= etty stupid, I hope it also contains some useful genralizations. STYLESHEETS Which brings me to the topic of going well beyond GUI design in seeking a= framework that is flexible, robust and easy to apply. I am talking here about stylesheets, not the rendering of them (AGG, PS, = EPS, OpenGL). In a rough and ready manner I assign data to XML formats, easily translat= ed into REBOL series. Aside from processing code, the rest is a question = of rendering to the right medium. Here in a nutshel is the whole problem CSS3 does just about everything th= at is needed, but as a language it is far too limited to use and relies o= n different browsers to implement it consistently (historically this has = been a failure). XSLT works with much the same limitations, but you have = to be a mad to use it unless you are more or less a fulltime coder. We need a stylesheet system, that is as consistent as PS in rendering, ca= n be transposed perfectly from one medium to another, or adapted seamless= ly to another. Either PS or EPS could be adapted to produce stylesheets, the latter more= effectively because APPLE has done the work to provide a reader already = plugged into browsers. REBOL language is ideal for web pages, but a reall= y good rendering engine (not speedy but precise) would make a big differe= nce in how well things could be done and how they can be used. However, OpenGL and perhaps AGG could equally be used (I think there woul= d be a massive amount of programming involved). Speed may well be an issue in any of these. I know an effective stylesheet language for net and local use is well bey= ond R3's scheme, but consider the effect of breaking with browser depende= nce for static rendering at least. REBOL as it stands seems easily capable of out perfoming XSL manipulation= of XML data. Inherently it is a better basis for stylesheet rendering, a= nd I am most unhappy with the choatic implmentation of CSS. Making a REBOL browser may be good in the long term, but as it has to dea= l with all the accumulated sludge of the net compatiblity issues will be = a nightmare. Far better to use existing browsers as a vehicle for a bette= r REBOL way of doing things at least in the short term. A critical compon= ant of that is the rendering. In this REBOL could take a decent lead, with a language plugin, and a con= sistent multiplatorm rendering engine with borrowed (PDF) or created (PS,= EPS, OpenGL, AGG), or anything else for that matter. What does matter is= the stylesheet dialect. If this hits a chord, I have some equally odd suggestions about how such = a dialect might be constructed (Ultra-Verbose Generated scripts - sounds = silly, as a tighter script - better still a GUI, generates a verbose sty= lesheet, that includes a DTD, but I will not burden the list with any mor= e rantings). However, the critical bit is to have a rendering engine capa= ble of painting a screen or a printed page precisely. Also consider the ability to solve printer driver issues by creating a co= nsistent raw raster for the printer and using a REBOL interface for page = control (including page imposition), it might not remove all the problems= , but it would significantly simplify many aspects (EPS and PS have a cle= ar lead in this re colour separation etc,). Just a simple example: -------------------------------------------- I have a set of particular problems in mind. As an English teacher I need= electronic resources, that can be easily transformed. In this example: http://members.iinet.net.au/%7Egreg.schofield/Literature/The%20War%20of%2= 0the%20Worlds.pdf I have reduced a 269 page book to 28 pages (14 sheets) so it can be phtoc= opied for each student. I also need to use a plain text version for Voice Synthesis (accelerated = reading program), and in the future marked-up for voice synethesis. I need a fully marked-up XML version (TEI) for reference purposes amongst= other things. I would like to attach to it other material for use by teachers - MP3 of = Orsen Welles' radio version, etc., I would like to have screen readable version available as well. I would like, for other teachers to use, a dynamic system that allows the= m to combine various forms making their own package of resources. Maintaining severval printed versions (A4, A5 compressed, A4 normal, poss= ible page impositions, plus all the rest) is mind boggling, especially if= my library grows. However, a XML version of the text, the separate files (MP3 etc, bibliogr= phies, handouts, pictures, etc), filtered through a standard set of my ow= n stylesheets, generating useful packages, makes managing and improving m= y site easy. Plus I deliver a very useful product for my fellow teachers = and the energy I spend in making things for my own classes has wider appl= ication. It all depends on having reliable and precise rendering tools - and CSS a= nd XSLT are simply never going to do that. =20 The Philosophy behind it is simple - never reproduce data unneccessarily = (the text once in XML may be re-edited, but never duplicated on site), ne= ver construct a rendering agent that cannot be potentially used elsewhere= , use shared modules to do the same tasks in different conditions. If I m= ake improvements I want all documents to share it, I don't expect to get = things right first time. I have one more point - no sane person can read a long document on screen= - until technology catches up with paper there is a need to print and re= ad - however what appears on screen has to be spacy, print that and reams= of paper are wasted. Print and screen are two different things. Same dat= a, but different stylesheets is the answer. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
