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

Re: Revisiting SVG Fonts

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 01 Nov 2011 19:02:31 -0700
Message-ID: <4EB0A4B7.5050903@jumis.com>
To: David Dailey <ddailey@zoominternet.net>
CC: 'Erik Dahlstrom' <ed@opera.com>, www-svg@w3.org
> 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 --

It needs to be pseudo-randomness, otherwise I can't reproduce the 
visualization.

We hit this issue when using randomness for user drawings... All of our 
Math.random
calls needed to be replaced.

I need the prng (pseudo-random number generator) to have some default value,
I'd like to be able to update that value with some seed value.

> 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>)

We do this, we even do this with replicate semantics along a path and/or 
series of points. Yes, it's handy. We stash the prng seed in with our 
data stream as part of the state.

I'd love to see replicate support the random selection of entries within 
a collection of values as an option.

> 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?

Seems to me that <altGlyph> could use some re-working to make this work.

Lets say I have a sheet of ~15 alternatives for each letter. As I do my 
editing, the authoring tool choses them in whatever manner it sees fit. 
Unfortunately, altGlyph may lead to some really dense DOM. Is there a 
short-hand for altGlyph?

http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlSVGWeb/text-altglyph-01-b.html
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-altglyph-01-b.svg


> Is this something for SVG 3.0 or 2.0?

Lets keep pushing the use cases for replicate, and lets see where 
replicate can be improved. We're not going to match the humanness of 
hand-written text, but we can certainly make it more dynamic while 
keeping the SVG markup understandable and efficient.

Replicate has been really important to me for presentational effects. It 
may be useful for "compressing" as well as extending the power of <use> 
and <altGlyph> calls.

Additionally, the advanced path semantics of InkML may be useful for 
describing glyphs that are not outlines. Metafont comes to mind.

http://en.wikipedia.org/wiki/Metafont

....

It sounds to me like there is still some push-back regarding SVG Fonts. 
Chris Lilley has expressed strong interest in seeing them added to WOFF. 
I've responded that I'm also interested, but that I think they ought to 
be supported inline, in SVG, regardless of the progress of a WOFF+SVG 
mixture.

Mozilla has not responded in this thread, though their coders have 
posted on the web several times.
Here's one of those responses:
http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html
"SVG Fonts ... would actually be very easy for us to implement. I 
honestly think we're doing the Web a service by resisting".

As for WOFF with SVG:
http://lists.w3.org/Archives/Public/www-style/2011Jun/0740.html
"SIL's Graphite engine... enables a few of those features you mentioned."

....

Opera and WebKit both seem to include sufficient support for SVG Font 
and ligatures to handle interesting use cases. I'm glad to hear from 
both groups that there's room for me to toy with using ligatures to 
display handwriting (basic/naive InkML).



> 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
>
>
>
>
Received on Wednesday, 2 November 2011 02:03:04 GMT

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