Re: Declarative Randomization (RE: Revisiting SVG Fonts)

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 Thursday, 3 November 2011 22:59:27 UTC