Re: SVG Fonts [...]

On 6/2/10 9:57 PM, Robert O'Callahan wrote:
> On Thu, Jun 3, 2010 at 4:35 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>     There's a reasonable chance of success, of processing an SVG file
>     using ECMAScript
>     and existing browsers. Rendering an SVG file with some fidelity to
>     the embedded
>     profile, whether falling back on VML, the HTML Canvas Tag, or
>     other technology,
>     is doable with SVG Fonts, and far more difficult with only a WOFF
>     binary.
>
>
> None of the SVG-to-VML or SVG-to-canvas solutions are actually very 
> good, so I don't think they're all that important. Anyway, you could 
> easily convert WOFF to TTF or EOT and load those fonts directly in any 
> browser.
I see no technical barrier for SVG-to-canvas solutions in the future.
Is it an unnecessary use-case, that a person may want to apply a "filter"
to the paths in an font? Path filters can't access the underlying
data of a binary font, without a descriptive API above the font.

Any chance of getting more data than "width" for WOFF?
>
>     By committing solely to WOFF, SVG - ECMAScript font generation
>     would be hackish at best,
>     as would embedded font resources. WOFF could work with with
>     data:-url, but that's stretching things.
>
>
> Why? Typekit serves fonts as data: URLs.
Cool.
>
>     In most cases, an SVG file will not include the full font, but
>     only a subset of glyphs, possibly
>     to be viewed independently of a web browser.
>
>
> You can subset Opentype fonts.
>
> Even if there are real use-cases for SVG Fonts not handled by 
> Opentype, we still run into the i18n issues, that SVG Fonts will only 
> work for simple scripts and Arabic.
Agreed.
> It's not satisfactory to say that those use-cases only work for those 
> scripts, and as I said in a previous email, I don't think adding 
> complex script shaping to SVG Fonts is feasible. I think we'd be 
> better off extending Opentype, or adding SVG features that work in 
> conjunction with Opentype.
I agree, adding any complexity to SVG fonts is not a good use of resources.

I'd like to have access to font outline data. Opentype certainly 
contains bitmap/outline data,
what are the chances of making that transparent through an API as an SVG 
path string?

By making path data available, I can still apply edge filters, things 
similar to Vector Effects,
and show the modified version as an SVG graphic or Canvas rendering.


> Rob
> -- 
> "He was pierced for our transgressions, he was crushed for our 
> iniquities; the punishment that brought us peace was upon him, and by 
> his wounds we are healed. We all, like sheep, have gone astray, each 
> of us has turned to his own way; and the LORD has laid on him the 
> iniquity of us all." [Isaiah 53:5-6]