W3C home > Mailing lists > Public > www-svg@w3.org > November 2011

Re: Declarative Randomization (RE: Revisiting SVG Fonts)

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>
Message-ID: <CAD95B1A.3151%b.kay@hull.ac.uk>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT