SVG Fonts
svgNick
I mean the font tag defined in the SVG spec as distinct from fonts
installed on the user computer. An example of what I'm talking about
is the Chess
Sophia Font produced by Max Froumentain formely of W3C.
the first part of it looks like this:
<font horiz-adv-x="0">
<font-face font-family="ChessSophia" units-per-em="1000" panose-1="0 0
4 0 0 0 0 0 0 0" ascent="1000" descent="0" alphabetic="0"/>
<missing-glyph horiz-adv-x="500" d="M63 0V1000H438V0H63ZM125
63H375V938H125V63Z"/>
.....
The font module has been implemented in Adobe & batik - I would like
to see it in Firefox as well.
If anyone is developing SVG fonts for Firefox I would be willing to
help.
HelderMagalhaes
> Are there any plans to implement SVG fonts in Firefox?
Don't have a clue about if/when, but bug 119490 [1] specifically aims
at that. You are invited to vote for it and/or CC yourself to it in
order to receive updates on its status.
> If anyone is developing SVG fonts for Firefox I would be willing to
> help.
Great news! :-) Help is always welcome. You may take a look at the
specific bug [1] in order to get familiar to what's happening there
and, if you are willing to help on other SVG-related work, you may
also look at JWatt's note [2]. ;-)
Cheers,
Helder
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=119490
[2] http://jwatt.org/moz/svg/help-out/
Robert O'Callahan
> Are there any plans to implement SVG fonts in Firefox? By SVG fonts
> I mean the font tag defined in the SVG spec as distinct from fonts
> installed on the user computer. An example of what I'm talking about
> is the Chess
> Sophia Font produced by Max Froumentain formely of W3C.
>
> the first part of it looks like this:
> <font horiz-adv-x="0">
> <font-face font-family="ChessSophia" units-per-em="1000" panose-1="0 0
> 4 0 0 0 0 0 0 0" ascent="1000" descent="0" alphabetic="0"/>
> <missing-glyph horiz-adv-x="500" d="M63 0V1000H438V0H63ZM125
> 63H375V938H125V63Z"/>
Recently I've been wondering what the actual need is for SVG fonts. What
can SVG fonts do that you can't do with a custom Truetype/Opentype font?
Rob
Rick
From: Rick <graha...@gmail.com>
Date: Sun, Sep 6, 2009 at 9:52 PM
Subject: Re: SVG Fonts
To: Robert O'Callahan <rob...@ocallahan.org>
SVG fonts rock. THEY ROCK!
Mostly because you can provide exact geometry for the whole page, and not
worry about the registration of the text. Because you provide it. But
also, if you like, you can do a lot of cool things with a font that you
design.
This is one of the reasons that Batik is a really useful tool. It will
encode fonts for you.
I'm curious, as one of the early adopters, why SVG fonts are not widely
implemented.
You have font metrics, you have SVG. It's not rocket science. (I've been
dying to say this, thank you)
MAKE IT HAPPEN!
> _______________________________________________
> dev-tech-svg mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-svg
>
--
Cheers!
Rick
--
Cheers!
Rick
Robert O'Callahan
> Mostly because you can provide exact geometry for the whole page, and not
> worry about the registration of the text. Because you provide it. But
> also, if you like, you can do a lot of cool things with a font that you
> design.
But you can do these things with Truetype/Opentype fonts as well. Right?
(In fact you can do more since you can have a proper shaping engine,
hinting, etc.)
Rob
Rick
therefore you do not control the geometry.
So, there is an issue here about bandwidth and document size.
If you can get away without specifying the exact font, SVG, via CSS allows
ways for you to try to pick the best font for an OS/browser. You can
provide a list that will iterate through your choices, but eventually, given
total failure, will drop down to the default font for the browser. Which
differs for different OS/browser combinatons. If you can dictate the the
OS/browser, fonts are not an issue. Narrow audience though. If we had wide
adoption of stadard fonts, so that "font family" would have a chance of
sucess across browsers, that would help. That has been attempted with web
fonts (and I may need education here) but I don't see that happenning.
I really don't understand why more engines do not implement SVG fonts. You
have text metrics, you have path. That will solve 99% of all requirements
and provide an excellent test bed to implement the rest.
Sorry, but we did this at BitFlash ~7 years ago. In fact Chris demoed
dynamic flowing SVG text for BitFlash in Zurich in 2002? on an IPaq. (Ask
him) It's not that hard.
(Rick shuts up)
Rick
of browsers. I don't feel that way. Truth is, I think that it's totally
cool that browsers today can do what they do. Thanks for the effort, maybe
you could do SVG fonts? :)
On Sun, Sep 6, 2009 at 10:21 PM, Rick <graha...@gmail.com> wrote:
>
> Well, yeah, you can. But you don't embed the encoding in the document, and
> therefore you do not control the geometry.
>
> So, there is an issue here about bandwidth and document size.
>
> If you can get away without specifying the exact font, SVG, via CSS allows
> ways for you to try to pick the best font for an OS/browser. You can
> provide a list that will iterate through your choices, but eventually, given
> total failure, will drop down to the default font for the browser. Which
> differs for different OS/browser combinatons. If you can dictate the the
> OS/browser, fonts are not an issue. Narrow audience though. If we had wide
> adoption of stadard fonts, so that "font family" would have a chance of
> sucess across browsers, that would help. That has been attempted with web
> fonts (and I may need education here) but I don't see that happenning.
>
> I really don't understand why more engines do not implement SVG fonts. You
> have text metrics, you have path. That will solve 99% of all requirements
> and provide an excellent test bed to implement the rest.
>
> Sorry, but we did this at BitFlash ~7 years ago. In fact Chris demoed
> dynamic flowing SVG text for BitFlash in Zurich in 2002? on an IPaq. (Ask
> him) It's not that hard.
>
> (Rick shuts up)
>
>
Robert O'Callahan
> Well, yeah, you can. But you don't embed the encoding in the document, and
> therefore you do not control the geometry.
I'm suggesting using a downloadable, custom Truetype font via CSS
@font-face.
These can even be embedded directly into the document using data: URLs.
The question is, what are SVG fonts good for that is not solved by CSS
@font-face and Truetype/Opentype support.
Rob
Felipe Sanches
You could have colourful glyphs, with transparency, with filter
effects, even with animation. You could even dinamicaly manipulate it
though DOM. The sky is the limit!
One could do wild things with SVG fonts!
Off course these things are not the usual basic demand for fonts...
JucaBlues
Inkscape.org
Robert O'Callahan
You could. Does anyone actually want to do those things?
Rob
Felipe Sanches
But while geeks dont get a working playground with full SVG fonts
support in order to tinker with it, we´ll probably not have too much
innovative uses of this tech.
roc,
At the moment I am focusing on development of a subtitling addon for
html5 video. But in the future I´d like to work a bit on SVG rendering
in Firefox, since I have already implemented SVG Filters and initial
support for SVG Fonts in Inkscape. It would be great if you could give
me some advices on firefox development. I am still not much familiar
with the codebase.
Felipe "Juca" Sanches
Inkscape.org
svgNick
SVG allows you to specify or embed a font in a document & be sure the
user will not get a lot of missing-glyph symbols when a suitable font
is not installed on their machine.
My special interest is chess - there are Unicode points for all pieces
but very few fonts implement them (Arial Unicode MS &/or MS Gothic in
windows).
SVG fonts also work well with Apache FOP (implementation of xsl-fo).
This can save you the trouble of generating a font metrics file from
an installed ttf when the font you want is not one of the 14 core pdf
fonts.
Another thing I like about SVG fonts is that anyone who can specify a
path can avoid copyright issues by developing their own font.
James Cloos
files to render.
Because most renderers fail to support SVG fonts, typical SVG-outputting
software uses what are essentially sprites for each glyph, placing them
just like setting text. Cairo and Ghostscript are two examples.
Were they able to use SVG fonts — and expect rendering software to
support that — then the original text would be available in the SVG,
enabling accessibility support at the very least.
-JimC
Chris Lilley
JC> The point is that SVG files should not have to depend on other, external
JC> files to render.
I agree that being contained in the same file is another advantage of SVG fonts.
JC> Because most renderers fail to support SVG fonts, typical SVG-outputting
JC> software uses what are essentially sprites for each glyph, placing them
JC> just like setting text. Cairo and Ghostscript are two examples.
"Most" is not correct. Opera, Batik, Ikivo and Bitflash all support SVG fonts (to name the most popular implementations; the latter two being the arket leaders on mobile). Quite a bit of mobile or set-top box content uses SVG fonts in fact. There is also good authoring support in terms of converters or direct authoring tools - Inkscape most recently, but also Corel Draw and Adobe Illustrator will export them and there are conversion tools from Batik, and axport options from fontforge.
Certainly, lack of SVG font support and lack of animation support are the two major dips in the Mozilla results over the SVG 1.1 test suite. And I understand both areas are being actively worked on?
JC> Were they able to use SVG fonts — and expect rendering software to
JC> support that — then the original text would be available in the SVG,
JC> enabling accessibility support at the very least.
That is also true.
--
Chris Lilley mailto:ch...@w3.org
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
James Cloos
> "Most" is not correct. Opera, Batik, Ikivo and Bitflash all support
> SVG fonts (to name the most popular implementations; the latter two
> being the arket leaders on mobile). Quite a bit of mobile or set-top
> box content uses SVG fonts in fact.
I'm glad to know I was out of date on that. Thanks for the heads-up.
From their websites, it looks like Ikivo and Bitflash target proprietary
mobile platforms, which is why I had not heard of Ikivo and was unaware
of how much of SVG Bitflash supports. I was thinking primarily of Free
Software.
In any case, I would argue that the fact that SVG fonts are getting used
in the mobile sector is an important reason for gecko to support them too.
-JimC
Boris Zbarsky
> In any case, I would argue that the fact that SVG fonts are getting used
> in the mobile sector is an important reason for gecko to support them too.
I don't see why.
Let's be clear. What we have here are two different technological
solutions to the same problem: that of creating custom fonts to use with
a web page (defined as something present on the web; doesn't have to be
HTML). The question is whether to implement one or the other or both.
Things that _are_ relevant to this decision (not exhaustive; just off
the top of my head):
1) Comparative capabilities of the two technologies in terms of the
fonts they can define.
2) Availability of authoring tools and other sources (e.g. font
foundries) for the fonts.
3) Ease of authoring web pages using the technology.
4) Whether existing web content relies on one or the other (or both).
5) Whether web content will be able to use one or the other (or both)
in the near future.
6) Whether there are pressing reasons why we think one or the other is
better for the web,
7) What the implementation and maintenance costs are for the two
technologies.
One thing that is NOT relevant is which technology is used as an
intermediate serialization format in a closed-loop process. This
includes mobile walled gardens, on-the-wire data formats for printer
drivers, interface description languages for UI toolkits and so forth.
The two obvious exceptions are if we want Gecko to be used as part of
such a closed-loop process (which is not high on our priority list) or
if there is a good chance that the data involved will end up on the web
(see points 4 and 5 in the "relevant" list).
Put another way, just because there's lots of software that deals with
VBScript doesn't mean we should implement VBScript. That would remain
true if VBScript were a W3C standard (and is in fact true of a number of
W3C standards today).
-Boris
P.S. No actual opinion on the relative merits of svg fonts and
@font-face per my 7-item list above. Just trying to head off logical
fallacies before they get too far.
Robert O'Callahan
> SVG allows you to specify or embed a font in a document& be sure the
> user will not get a lot of missing-glyph symbols when a suitable font
> is not installed on their machine.
> My special interest is chess - there are Unicode points for all pieces
> windows).
> SVG fonts also work well with Apache FOP (implementation of xsl-fo).
> This can save you the trouble of generating a font metrics file from
> an installed ttf when the font you want is not one of the 14 core pdf
> fonts.
> Another thing I like about SVG fonts is that anyone who can specify a
> path can avoid copyright issues by developing their own font.
You can do all those things with CSS @font-face downloadable fonts and a
custom Truetype/Opentype font.
Rob
Robert O'Callahan
> The point is that SVG files should not have to depend on other, external
> files to render.
You could use CSS @font-face with the font in a data: URL.
Rob
Robert O'Callahan
> But while geeks dont get a working playground with full SVG fonts
> support in order to tinker with it, we�ll probably not have too much
> innovative uses of this tech.
Other SVG UAs apparently support the full SVG fonts spec already, so
there is nothing stopping people coming up with innovative uses for it.
I'm reluctant to add SVG Fonts to Gecko and acquiesce to having them be
an essential part of the Web platform forever just so that people can
play with them to see if they're useful.
Rob
James Cloos
> James Cloos wrote:
>> In any case, I would argue that the fact that SVG fonts are getting used
>> in the mobile sector is an important reason for gecko to support them too.
>
> I don't see why.
Marketing.
The other poster’s statement that SVG fonts have gained traction in the
mobile sector implies that sites are using them on pages intended for
those users. That implies that SVG font support will help gecko gain
traction in that segment.
And if the trend towards mobile is as real as many claim, traction there
is important for gecko and mozilla.org.
-JimC
James Cloos
> What we have here are two different technological solutions to the
> same problem: that of creating custom fonts to use with a web page
> (defined as something present on the web; doesn't have to be HTML).
I don't think that the above is a complete depiction of the raison
d'etre of SVG fonts. Perhaps that is how there are currently used in
the mobile sector, but the mobile sector was only part of the argument
for SVG font support.
I maintain that SVG should be used for all artwork in XML (and html5)
documents and that said SVG should not have to depend on external
resources.
(That does not mean that all fonts have to be included, just that --
like the text portions of a document -- the renderer is free, w/in the
contraints of the users' preferences, to choose any available font to
render generic text elements. Font support in SVG should be used for
those cases where appearance and such are semantic.)
And I have to say, this discussion seems a bit long winded for something
which ought to be easy to write. Libraries like cairo already use a:
<symbol><path/></symbol>
blob for each glyph when creating text-using SVGs and <xlink> them into
place. A practice gecko supports. Supporting SVG fonts to do the same
thing should be *easy*.
I just do not understand the resistance.
Which is -- given the trust of the post I'm replying to here -- not to
denigrate support for @font-face. Or, more importantly, support for
arbitrary URLs (if not URIs) pointing at raw SFNTs. (Does it support
any font freetype can render? Or just SFNTs?) Please do stick to you
guns and avoid limiting @font-face to eot-next-gen or simiar.
But that is orthogonal tothe need for full support of SVG.
-JimC
Boris Zbarsky
> The other poster’s statement that SVG fonts have gained traction in the
> mobile sector implies that sites are using them on pages intended for
> those users.
To me it implies that they are being used in walled-garden content, not
in web sites intended for mobile users. Did I misunderstand?
> That implies that SVG font support will help gecko gain
> traction in that segment.
Gaining traction in the walled-garden "segment" is somewhat of a
non-goal, as I said. At least last I checked.
Note that walled-garden content isn't really using a web browser at all,
typically, so Gecko wouldn't be a good fit anyway.
-Boris
Boris Zbarsky
>> What we have here are two different technological solutions to the
>> same problem: that of creating custom fonts to use with a web page
>> (defined as something present on the web; doesn't have to be HTML).
>
> I don't think that the above is a complete depiction of the raison
> d'etre of SVG fonts.
It's a depiction of the main reason typically given for having them.
> I maintain that SVG should be used for all artwork in XML (and html5)
> documents and that said SVG should not have to depend on external
> resources.
That's fine, and you're welcome to your beliefs. ;)
Does "external resources" include data: URLs?
> And I have to say, this discussion seems a bit long winded for something
> which ought to be easy to write.
I'm sure roc would be happy to at least evaluate a patch you produce.
But seriously, the discussion isn't about "can we do this?" but "should
we do this?". That is, which approach is better for the web platform?
All else being equal, having multiple ways of doing the same thing
increases platform complexity for authors, forces more code on all
implementors, and is generally undesirable unless there are _very_ good
reasons for having both ways available. So the question is basically
"is this spec worth implementing at all?" For some specs the answer is
clearly yes; for some clearly no. For this one, it's clearly a tough
call for some people, a clear yes for others. I'm not seeing any clear
nos, but I _am_ seeing strong reasons to raise the question.
> I just do not understand the resistance.
See above.
-Boris
James Cloos
>> The other poster’s statement that SVG fonts have gained traction in the
>> mobile sector implies that sites are using them on pages intended for
>> those users.
> To me it implies that they are being used in walled-garden content,
> not in web sites intended for mobile users. Did I misunderstand?
Or I did. At least as likely, I suppose.
-JimC
Chris Lilley
ROC> On 8/09/09 4:14 AM, Felipe Sanches wrote:
>> But while geeks dont get a working playground with full SVG fonts
>> support in order to tinker with it, we´ll probably not have too much
>> innovative uses of this tech.
ROC> Other SVG UAs apparently support the full SVG fonts spec already, so
ROC> there is nothing stopping people coming up with innovative uses for it.
ROC> I'm reluctant to add SVG Fonts to Gecko and acquiesce to having them be
ROC> an essential part of the Web platform forever just so that people can
ROC> play with them to see if they're useful.
To be clear - they already are useful and already are used. However, content tends to break in Mozilla because they are not supported, so a fallback font is used with greater or lesser breakage in terms of design intent and legibility.
codedread
>
> Recently I've been wondering what the actual need is for SVG fonts. What
> can SVG fonts do that you can't do with a custom Truetype/Opentype font?
>
> Rob
Accidentally replied to just roc earlier.
What I've always liked about SVG Fonts is that they are part of the
Web. I've always used this article as a reminder of why the Web is
great: http://shaver.off.net/diary/2007/05/10/the-high-cost-of-some-free-tools/
- SVG Fonts can be analyzed by View Source
- SVG Fonts can be edited in a text editor (for removing or adding
specific glyphs)
- SVG Fonts glyphs can be inspected/tweaked in Firebug
These are the same reasons that I prefer SVG over Canvas actually
(though I acknowledge that Canvas has some really good use cases, I
just wouldn't ever want to try and build, say SVG-edit, using Canvas).
Regards,
Jeff Schiller
Robert O'Callahan
> To be clear - they already are useful and already are used. However,
> content tends to break in Mozilla because they are not supported, so a
> fallback font is used with greater or lesser breakage in terms of design
> intent and legibility.
>
But what are they used for that a custom, downloadable TTF/OTF font could
not be used for?
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]
Robert O'Callahan
> What I've always liked about SVG Fonts is that they are part of the
> Web. I've always used this article as a reminder of why the Web is
> great: http://shaver.off.net/diary/2007/05/10/the-high-cost-of-some-free-tools/
>
> - SVG Fonts can be analyzed by View Source
> - SVG Fonts can be edited in a text editor (for removing or adding
> specific glyphs)
> - SVG Fonts glyphs can be inspected/tweaked in Firebug
Thanks, this is more like what I'm looking for.
Rob
codedread
> On Thu, Sep 10, 2009 at 2:51 AM, Chris Lilley <ch...@w3.org> wrote:
> > To be clear - they already are useful and already are used. However,
> > content tends to break in Mozilla because they are not supported, so a
> > fallback font is used with greater or lesser breakage in terms of design
> > intent and legibility.
>
> But what are they used for that a custom, downloadable TTF/OTF font could
> not be used for?
>
The same question could be asked about Flash vs. Canvas/SVG. The
point is that this:
http://www.microsoft.com/typography/otspec/otff.htm
or
http://standards.iso.org/ittf/PubliclyAvailableStandards/c052136_ISO_IEC_14496-22_2009(E).zip
do not look like the Web to me. Do they to you?
Primarily because I cannot view source, I therefore cannot easily hack
the font or learn from the format directly. I have to find a tool
(other than a text editor) and maybe read another several hundred page
technical document (we web developers already have a lot of those:
HTML, CSS, DOM, SVG, JavaScript). It also doesn't take advantage of
existing skillsets (markup, DOM, SVG).
I've been told that TTF/OTF fonts can provide better hinting or
whatever. That's great and I'm glad that browsers support @font-face
for this purpose, but to me this is something like the equivalent of
linking to a raster image: it's a binary blob. As a developer I have
to do a lot more research to be able to view the source, hack it,
change it, inspect it, mash it up, etc. This lowers the barrier of
entry and means that probably that many less people will do it.
Jeff
Rick
From: Rick <graha...@gmail.com>
Date: Wed, Sep 9, 2009 at 5:34 PM
Subject: Re: Fwd: SVG Fonts
To: rob...@ocallahan.org
On Wed, Sep 9, 2009 at 4:10 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> On Thu, Sep 10, 2009 at 2:51 AM, Chris Lilley <ch...@w3.org> wrote:
>
> > To be clear - they already are useful and already are used. However,
> > content tends to break in Mozilla because they are not supported, so a
> > fallback font is used with greater or lesser breakage in terms of design
> > intent and legibility.
> >
>
> But what are they used for that a custom, downloadable TTF/OTF font could
> not be used for?
>
There isn't anything a TTF font can do that SVG Fonts can't do, the only
thing SVG fonts can do that TTF fonts can't do is merge SVG rendering with
text semantics.
But that one thing is very powerful.
And if you have text metrics/semantics and SVG rendering, the job is almost
done for you already.
>
> 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]
> _______________________________________________
> dev-tech-svg mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-svg
>
--
That which is proposed without evidence can be dismissed without evidence.
Rick
--
Cheers!
Rick
Felipe Sanches
mistake.
---------- Forwarded message ----------
From: Robert O'Callahan <rob...@ocallahan.org>
Date: Wed, Sep 9, 2009 at 6:21 PM
Subject: Re: Fwd: SVG Fonts
To: Felipe Sanches <felipe....@gmail.com>
On Thu, Sep 10, 2009 at 8:24 AM, Felipe Sanches <felipe....@gmail.com>wrote:
> one example:
> http://code.google.com/p/typism/
>
>
Interesting, please forward this to the newsgroup discussion.
Robert O'Callahan
> There isn't anything a TTF font can do that SVG Fonts can't do
There certainly is: for example hinting and advanced shaping. But that's
not really relevant to this discussion, so never mind.
> the only thing SVG fonts can do that TTF fonts can't do is merge SVG rendering with
> text semantics.
>
> But that one thing is very powerful.
Potentially yes; the question is how useful it is.
> And if you have text metrics/semantics and SVG rendering, the job is almost
> done for you already.
Not really. Implementing the rendering for <glyph d="..."/> looks pretty
easy. But the glyph elements can contain arbitrary SVG --- and via
foreignObject, non-SVG --- content and the spec requires that content to
be treated as a per-glyph <use> element with CSS cascading into the
cloned anonymous content in a complicated way. For example, consider a
font whose "G" glyph is an HTML <iframe> containing www.google.com, we'd
have to create a bunch of anonymous iframes somehow associated with each
text node, figure out what happens to the state of those iframes as the
node is edited, etc.
However, I just tried to see how Webkit and Opera handle arbitrary SVG
content in glyphs, using this simple example:
<svg xmlns="http://www.w3.org/2000/svg" >
<font id="Font">
<font-face font-family="Test" units-per-em="2048"/>
<glyph unicode="@" horiz-adv-x="1000" d="M128 0V1638H896V0H128zM256
128H768V1510H256V128z">
<rect x="0" y="0" width="1000" height="1000" fill="cyan"/>
</glyph>
</font>
<text x="0" y="100" style="font-family:Test; font-size:80px;">@@@</text>
</svg>
... and they don't seem to be rendering the <rect>. Is something wrong
with my example?
I also notice that the SVG 1.1 test suite doesn't test anything but
<glyph d="..."/>.
Rob
Robert O'Callahan
> On Sep 9, 3:10 pm, "Robert O'Callahan"<rob...@ocallahan.org> wrote:
>> But what are they used for that a custom, downloadable TTF/OTF font could
>> not be used for?
>
> The same question could be asked about Flash vs. Canvas/SVG.
Sure. The main problem with Flash is that Adobe controls it. Secondary
problems are that it duplicates a ton of functionality in deployed Web
specs and doesn't integrate well with them either.
The OTF spec seems more open to me: no one vendor's implementation
completely determines what OTF is, and no one vendor controls its
evolution. It doesn't duplicate deployed Web functionality, and
integrates reasonably well (in that Web apps hardly ever need direct
access to glyph data). So I don't think the situations are very similar.
> The point is that this:
>
> http://www.microsoft.com/typography/otspec/otff.htm
> or
> http://standards.iso.org/ittf/PubliclyAvailableStandards/c052136_ISO_IEC_14496-22_2009(E).zip
>
> do not look like the Web to me. Do they to you?
I agree that View Source and having a DOM are good features of SVG Fonts.
> I've been told that TTF/OTF fonts can provide better hinting or
> whatever. That's great and I'm glad that browsers support @font-face
> for this purpose, but to me this is something like the equivalent of
> linking to a raster image: it's a binary blob. As a developer I have
> to do a lot more research to be able to view the source, hack it,
> change it, inspect it, mash it up, etc. This lowers the barrier of
> entry and means that probably that many less people will do it.
I'm sympathetic. The only thing is that the font design community is
already entirely committed to TTF/OTF and there are lots of good tools
from many vendors for working with it (including free ones). I don't
believe that being able to modify SVG fonts with a text editor is going
to open up font design to a much greater community.
I'm honestly trying to gather information here --- I'm currently unsure
in my own mind whether SVG Fonts is worth doing or not.
Rob
John Daggett
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/fonts/mark-generate.py
SVG fonts also make it possible to use script to modify fonts on the fly, to algorithmically create a bold face on the fly for example. Many font licenses don't allow the form to be altered, using a font editor to make modifications for example, but I don't think this applies to on-the-fly modifications via script. In general, having fonts as a more malleable resource within the browser is a good thing. But I do agree with roc, general font development is better supported in OpenType, SVG fonts lack the richness of typographic controls available in OpenType.
The idea of sticking arbitrary content in the definition of a glyph is a concern, that's essentially using text as a short hand for general graphic content. Text rendering is a critical path in a browser, having arbitrary content in glyphs means you need to run the font matching algorithm on text spans before you know whether a text run contains a set of simple glyphs or something that's the moral equivalent of an iframe.
I think the simple thing is to support SVG fonts that only contain simple path definitions with Cairo user fonts and segregate out fonts with arbitrary content and treat them as inline images.
John
Chris Lilley
ROC> On Thu, Sep 10, 2009 at 2:51 AM, Chris Lilley <ch...@w3.org> wrote:
>> To be clear - they already are useful and already are used. However,
>> content tends to break in Mozilla because they are not supported, so a
>> fallback font is used with greater or lesser breakage in terms of design
>> intent and legibility.
ROC> But what are they used for that a custom, downloadable TTF/OTF font could
ROC> not be used for?
They tend to be used for short, decorative, one-off text strings. Kerning, glyph shapes may be modified for the one pieve of artwork.
They can be used for less common languages.
The glyphs don't have the same constraints that TT/OT glyphs have, in terms of placement of control points, winding rule, avoidance of overlap and self-intersection. They can mix cubics, quadratics, and straight line segments as needed.
In other words, if you can draw it, you can make it a glyph. And the SVG engine can already render it because it already knows about paths, fill, stroke, opacity etc.
Of course, the temptation is to just draw something which looks, visually, like text. SVG gives the option to make it real, searchable, accessible and updatable text, for very little more effort.
Chris Lilley
ROC> I'm honestly trying to gather information here --- I'm currently unsure
ROC> in my own mind whether SVG Fonts is worth doing or not.
And that open-mindedness is appreciated, believe me.
Chris Lilley
ROC> However, I just tried to see how Webkit and Opera handle arbitrary SVG
ROC> content in glyphs, using this simple example:
ROC> <svg xmlns="http://www.w3.org/2000/svg" >
ROC> <font id="Font">
ROC> <font-face font-family="Test" units-per-em="2048"/>
ROC> <glyph unicode="@" horiz-adv-x="1000" d="M128 0V1638H896V0H128zM256
ROC> 128H768V1510H256V128z">
ROC> <rect x="0" y="0" width="1000" height="1000" fill="cyan"/>
ROC> </glyph>
ROC> </font>
ROC> <text x="0" y="100" style="font-family:Test; font-size:80px;">@@@</text>
ROC> </svg>
ROC> ... and they don't seem to be rendering the <rect>. Is something wrong
ROC> with my example?
There is an ambiguity in the 1.1 spec, which says
The graphics that make up the ‘glyph’ can be either a single path data specification within the ‘d’ attribute or arbitrary SVG as content within the ‘glyph’.
but also says
If the ‘glyph’ has both a ‘d’ attribute and child elements, the ‘d’ attribute is rendered first, and then the child elements.
I believe that some implementations ignore child elements if there is a d attribute. (This ambiguity is the subject of a current errata item).
ROC> I also notice that the SVG 1.1 test suite doesn't test anything but
ROC> <glyph d="..."/>.
Actually, we noticed that too, fairly recently. The next release will fix that.
Robert O'Callahan
> I believe that some implementations ignore child elements if there is a d attribute. (This ambiguity is the subject of a current errata item).
I thought it was pretty clear myself. However, that's not the problem
here because if you removed the "d" from that testcase you get the same
result: Opera and Webkit don't render the rect.
> ROC> I also notice that the SVG 1.1 test suite doesn't test anything but
> ROC> <glyph d="..."/>.
>
> Actually, we noticed that too, fairly recently. The next release will fix that.
I was actually wondering whether it would make sense to remove that
feature for the Web, since it seems really hard to implement in general
and as far as I can tell no Web browser implements it.
Rob
Robert O'Callahan
> ROC> But what are they used for that a custom, downloadable TTF/OTF font could
> ROC> not be used for?
>
> They tend to be used for short, decorative, one-off text strings. Kerning, glyph shapes may be modified for the one pieve of artwork.
>
> They can be used for less common languages.
>
> The glyphs don't have the same constraints that TT/OT glyphs have, in terms of placement of control points, winding rule, avoidance of overlap and self-intersection. They can mix cubics, quadratics, and straight line segments as needed.
>
> In other words, if you can draw it, you can make it a glyph. And the SVG engine can already render it because it already knows about paths, fill, stroke, opacity etc.
>
> Of course, the temptation is to just draw something which looks, visually, like text. SVG gives the option to make it real, searchable, accessible and updatable text, for very little more effort.
Thanks, those are really good points.
Rob
Robert O'Callahan
> I was actually wondering whether it would make sense to remove that
> feature for the Web, since it seems really hard to implement in general
> and as far as I can tell no Web browser implements it.
Although it seems that the best use-cases for SVG Fonts over TTF/OTF are
when you use arbitrary SVG content...
Maybe we have an opportunity to redefine how glyphs containing arbitrary
SVG content are rendered, so that it's more sane. I'll post to www-svg.
Rob
svgNick
Thanks for the info - I tried downloadable fonts through CSS a few
years ago and they simply didn't work.
The only way I could find was an MS proprietary method that only
worked in IE.
I obviously need to look into it again.