RE: Declarative Randomization (RE: Revisiting SVG Fonts)

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:45:58 UTC