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_Feedback#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 17:52:58 UTC