- From: Ben Kay <b.kay@hull.ac.uk>
- Date: Fri, 04 Nov 2011 09:04:26 +0000
- To: Charles Pritchard <chuck@jumis.com>, David Dailey <ddailey@zoominternet.net>
- CC: Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>, "<www-svg@w3.org>" <www-svg@w3.org>
The declarative randomization element would be useful for non-scripted scenes (or non-scriptable scenes). The specific use-case I have in mind is implementations where script is not supported (or discouraged), but SVG is supported - specifically in e-Reader / tablet devices that support the EPUB format. On 03/11/2011 22:58, Charles Pritchard (chuck@jumis.com) wrote: > Yes, please extend the replicate proposal. As roc pointed out, random is > useful for non-scripted scenes. I'm using <img> references with svg these days > and it's ever-so-pleasant. > > > > > On Nov 3, 2011, at 3:43 PM, "David Dailey" <ddailey@zoominternet.net> wrote: > >> Thanks Cyril, >> >> I'm aware that random numbers can be called from script, so I'm still not >> completely convinced that exposing them declaratively is a bad idea. >> Graphics can be created with script as well without having to have SVG, >> which is part of why Apple seems to have been so enamored by <canvas>. >> >> But I can understand the working group's thinking here, and while I >> disagree, I'm not likely to file a formal objection or even fuss too loudly. >> We may build it into <replicate> though with a representative syntax for how >> it might work. I think at the heart of the issue is the question of how many >> people are going to be using packages to generate their SVG as opposed to >> hand-crafting it. Once there are packages that hide even the declarative >> code from the end user, then the issue might become moot. It is just that in >> approx. 10 years of having SVG around, we are only beginning to see the >> emergence of those packages. So I think the job still remains to enable the >> non-programming artist to help show people that SVG exists. Once all the >> killer-apps exist, then maybe we can quit adding new constructs to the >> language, but until then I'd argue the language isn't yet finished. >> >> Regards >> David >> >> >> -----Original Message----- >> From: Cyril Concolato [mailto:Cyril.Concolato@cisra.canon.com.au] >> Sent: Wednesday, November 02, 2011 12:50 PM >> To: www-svg@w3.org >> Subject: Declarative Randomization (RE: Revisiting SVG Fonts) >> >> Hi David, >> >> During the F2F prior to TPAC, the SVG WG discussed your proposed requirement >> to have declarative randomization support in SVG 2 (see >> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedba >> ck#Randomization). We decided not to include this requirement mainly because >> we thought that this can already be done in script today and we did not see >> the reason to make it native in the browser. >> >> Regards, >> >> Cyril >> >> -----Original Message----- >> From: David Dailey [mailto:ddailey@zoominternet.net] >> Sent: Wednesday, 2 November 2011 11:46 AM >> To: 'Charles Pritchard'; 'Erik Dahlstrom' >> Cc: www-svg@w3.org >> Subject: RE: Revisiting SVG Fonts >> >> So long as we're meandering a bit on the topic of stretching the use of >> fonts, I wanted to re-raise the issue of declarative randomness -- >> >> Things like <someSVGtag cx=random(20%, 80%) fill= >> random(R(0,ff),G(88),B(random(88,ff)) > where a random position in a certain >> range is provided in the context of a random color (restricted somewhat on R >> and B but fixed at 88 on G). Not sure of the syntax. >> >> It could be very handy for filling in random textures in backgrounds of >> scenes, random breezes in our forests, and for creating a sort of >> declarative noise (particularly in the context of <replicate>) >> >> But in Boston two weeks ago, someone pointed out to me the sumptuousness of >> a hand drawn blackboard-menu. The calligrapher had used chalk and had come >> up with very clever ways of forming the glyphs. Some of it could be handled >> with ligatures, but a part of the beauty of it was the unpredictable >> humanness of the writing. The ability to insert randomness in our writing, >> and indeed randomness in general imparts a great sense of realism to our >> work. Client side declarative randomness is pretty necessary ¿que no? >> >> Is this something for SVG 3.0 or 2.0? >> >> Cheers >> David >> >> -----Original Message----- >> From: Charles Pritchard [mailto:chuck@jumis.com] >> Sent: Tuesday, November 01, 2011 6:27 PM >> To: Erik Dahlstrom >> Cc: www-svg@w3.org >> Subject: Re: Revisiting SVG Fonts >> >>> On Mon, 31 Oct 2011 18:21:02 -0700, Charles Pritchard >>> <chuck@jumis.com> wrote: >>> >>> ... >>>> What's the status of ligatures on those SVG Tiny viewers? >>>> >>>> Is there a maximum length that a ligature can be? >>>> For instance, could 80 characters be used? >>> >>> There probably is some implementation-dependent limit yes. The spec >>> itself doesn't limit the string length for @unicode on <glyph>. >>> >>> I'm pretty sure it would work ok if you happened to have an 80 >>> characters ligature in an svgfont, but it's not really a common case >>> :) >>> >>> >> Consider it a very nasty hack/work-around to display scanned text or >> hand-written text while maintaining machine readable DOM. >> >> <text class="line1">first line of text</text> or even: >> <text>[unicode private char] another line of text</text> >> >> I'm just brainstorming here, but it's been in my mind awhile... >> representing non-standard scripts, scanned text and hand-written text. >> >> Of course it breaks down quickly when editing, but it does break-down into >> human readable form. >> >> Thanks for engaging me in this. I'll take a peek inside some of the code >> bases to see what WebKit and Moz setup for their buffer lengths. >> >> This thread has been about stretchin the use of SVG fonts (as well as >> implementing them sooner rather than later re: embedding svg in WOFF). >> So, I hope I didn't stray too far off topic. >> >> -Charles >> >> >> >> >> >> The information contained in this email message and any attachments may be >> confidential and may also be the subject to legal professional privilege.. If >> you are not the intended recipient, any use, interference with, disclosure >> or copying of this material is unauthorised and prohibited. If you have >> received this email in error, please immediately advise the sender by return >> email and delete the information from your system. >> >> >> >> >> >> >
Received on Friday, 4 November 2011 16:24:16 UTC