10:04 a.m.
I will apply for SoC on SVG Fonts implementation. My task will be basic SVG
Fonts support (i.e. reading of xml attributes, proper rendering and
editing). I imagine that there are some extra stuff that could be done but
would not necesarily be part of my task on SoC. I could work on those after
completing the basic SVG Fonts support.
I am starting this thread to discuss SVG Fonts related wished features. I
will choose among these, which ones I think make sense to add to my SoC
application and which I consider extra work to be done after SoC.
one idea (probably to be implemented after SoC):
Since SVG Fonts actually work as an alternative kind of font file (a font
can be saved as .svg and then used by other SVG drawings) inkscape could
have a font editing UI. It could have import scripts to load TrueType fonts
and export them as SVG Fonts and vice-versa. I could also do it for other
font types. One issue is in the exporters because obviously not everything
SVG is capable of doing is supported by TrueType, or other font formats. So,
we would commonly have to deal with glyph degradation when exporting fonts.
Felipe Sanches ("JucaBlues" on irc)
10:29 a.m.
Felipe Sanches wrote:
I will apply for SoC on SVG Fonts implementation. My task will be
basic
SVG Fonts support (i.e. reading of xml attributes, proper rendering and
editing). I imagine that there are some extra stuff that could be done
but would not necesarily be part of my task on SoC. I could work on
those after completing the basic SVG Fonts support.
I am starting this thread to discuss SVG Fonts related wished features.
I will choose among these, which ones I think make sense to add to my
SoC application and which I consider extra work to be done after SoC.
SVG font support will be truly awesome. I'm very happy that someone has
taken interest in this portion of the spec. I'm not particularly
familiar with it yet since Inkscape doesn't support it so I don't know
what to suggest. I'll forward to you off list one email of a short
conversation I had with Richard Hughes about SVG fonts.
Aaron Spike
6:14 a.m.
SVG font support will be truly awesome. I'm very happy that
someone has
taken interest in this portion of the spec. I'm not particularly
familiar with it yet since Inkscape doesn't support it so I don't know
what to suggest. I'll forward to you off list one email of a short
conversation I had with Richard Hughes about SVG fonts.
Did I? /me rummages through outbox. Oh yeah.
I reckon it would be really nice to use Cairo's user font API to
implement SVG fonts, so that we get good PDF output and suchlike for
free. There are just two minor problems with this plan:
1) Cairo doesn't have a user font API yet. It's due in November.
(http://cairographics.org/roadmap/)
2) Inkscape doesn't use enough of Cairo yet for this to be just a
simple plug-in job.
Since the API doesn't exist I have no idea what we would gain from
using Cairo rather than going it alone, however I strongly recommend
that you hook up with some of their people to talk about it. Get an
update on the status of the roadmap too while you're at it.
Richard.
7:23 a.m.
On Wed, 19 Mar 2008 21:14:04 +0000, Richard Hughes <cyreve@...400...> wrote:
I reckon it would be really nice to use Cairo's user font API to
implement SVG fonts, so that we get good PDF output and suchlike for
free.
How does the user font API integrate with Pango, out of curiosity?
-mental
12:55 p.m.
SVG1.1 spec, on session 20:
The purpose of SVG fonts is to allow for delivery of glyph outlines in
display-only environments. SVG fonts that accompany Web pages must
be
supported only in browsing and viewing situations. Graphics editing
applications or file translation tools must not attempt to convert SVG fonts
into system fonts. The intent is that SVG files be interchangeable between
two content creators, but not the SVG fonts that might accompany these SVG
files. *Instead, each content creator will need to license the given font
before being able to successfully edit the SVG file.* The
font-face-name<http://www.w3.org/TR/SVG11/fonts.html#FontFaceNameEleme...
indicates the name of licensed font to use for editing.
Am I getting confused or is this part of the spec really promoting the use
of DRM techniques for SVG Fonts?
4:49 a.m.
Felipe Sanches wrote:
SVG1.1 spec, on session 20:
The purpose of SVG fonts is to allow for delivery of glyph outlines in
> display-only environments. SVG fonts that accompany Web pages must be
> supported only in browsing and viewing situations. Graphics editing
> applications or file translation tools must not attempt to convert SVG
> fonts
> into system fonts. The intent is that SVG files be interchangeable
> between
> two content creators, but not the SVG fonts that might accompany these
> SVG
> files. *Instead, each content creator will need to license the given font
> before being able to successfully edit the SVG file.* The
>
font-face-name<http://www.w3.org/TR/SVG11/fonts.html#FontFaceNameEleme...
> indicates the name of licensed font to use for editing.
>
Am I getting confused or is this part of the spec really promoting the use
of DRM techniques for SVG Fonts?
I think it means that:
1. SVG fonts are used to enable rendering of SVG images that contain a font
that isn't on your system.
2. Because some fonts are copyrighted, if you have licensed i.e. a TTF font,
you should be able to convert it into an SVG font to allow other people to
see it on your web page, however others should not be able to take your
generated SVG font and recreate your licensed TTF font from it.
3. I also think it means that editing an SVG image that contains SVG fonts
created from licensed fonts should be impossible unless the original TTF
font is present in your system.
4. Because the SVG font has the full information required to display a
glyph, it means that respecting those restrictions is up to the goodwill of
developers.
I think this basically means that if an SVG font was created from a licensed
font, it's supposed to be "read-only", as well as any document that uses
it,
and converting such an SVG font to a system-readable font should be
impossible. I have the impression that this paragraph was put in to appease
font vendors (keep in mind that this spec was originally created by Adobe).
It doesn't advocate DRM in its regular sense, rather something like a
"please do not steal" sign. I think that an SVG font to TTF converter could
comply with this part of the specification, provided it refused to work on
SVG fonts derived from copyrighted fonts.
--
View this message in context: http://www.nabble.com/SVG-Fonts-tp16135096p16206446.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
12:24 p.m.
I think that an SVG font to TTF converter could
comply with this part of the specification, provided it refused to work on
SVG fonts derived from copyrighted fonts.
that's the issue: refusing to work.
I think that the user should be responsible for his acts and for eventual
copyright infringement. There is no general way to know whether he/she has a
license granting rights of use of a particular font. Even if the user don't
have a license, there are several exceptions for copyright scope of
protection. So, there are cases in which even a user without an explicit
authorization from the copyright holder, could effectively have the right to
use the work in question. Control should not be embedded on tools because it
would never be fair and it would never be accurate.
So, my conclusion is:
I think Inkscape should be able to convert from SVG Fonts to TrueType (or
other font formats) and vice-versa without artificial restrictions.
Respecting the law is an issue for the user (i.e. human beings), it should
not be enforced by code.
JucaBlues
6:54 a.m.
On Mon, Mar 24, 2008 at 12:24:51AM -0300, Felipe Sanches wrote:
> I think that an SVG font to TTF converter could
> comply with this part of the specification, provided it refused to work on
> SVG fonts derived from copyrighted fonts.
>
that's the issue: refusing to work.
I think that the user should be responsible for his acts and for eventual
copyright infringement. There is no general way to know whether he/she has a
license granting rights of use of a particular font. Even if the user don't
have a license, there are several exceptions for copyright scope of
protection. So, there are cases in which even a user without an explicit
authorization from the copyright holder, could effectively have the right to
use the work in question. Control should not be embedded on tools because it
would never be fair and it would never be accurate.
So, my conclusion is:
I think Inkscape should be able to convert from SVG Fonts to TrueType (or
other font formats) and vice-versa without artificial restrictions.
Respecting the law is an issue for the user (i.e. human beings), it should
not be enforced by code.
Agreed; we should be in the business of *facilitating*, not *enforcing*
copyrighting. DRM is bad.
Wouldn't it be annoying if you were the copyright holder, and inkscape
made things more difficult for you to edit your own font? ;-)
Bryce
9:30 p.m.
Bryce Harrington wrote:
On Mon, Mar 24, 2008 at 12:24:51AM -0300, Felipe Sanches wrote:
>> I think that an SVG font to TTF converter could
>> comply with this part of the specification, provided it refused to work on
>> SVG fonts derived from copyrighted fonts.
>>
> that's the issue: refusing to work.
>
> I think that the user should be responsible for his acts and for eventual
> copyright infringement.
IANAL, but...
Is the act above even considered infringement? I don't think so, at
least not under US law. Since the graphical appearance of fonts is
considered to fall below the threshold of creativity required for
copyright, you are not infringing if the appearance is all that you copy.
It is only the procedural hinting code in TrueType fonts that makes them
copyrightable -- if that is stripped by rendering the font into a new
representation, then no infringement occurs. If you then add NEW hinting
to the result, that hinting is copyright by you, and again, no
infringement occurs (IOW, you've "reverse engineered" the font, which is
legal).
I don't think it matters whether the font is rendered to pixels or
bezier curves in an SVG document.
Are there legal cases which challenge this interpretation?
I admit it's a borderline case, but (even if you do believe in
artificially imposed restrictions) you certainly shouldn't be
implementing code to enforce a restriction which only *might* be illegal.
Cheers,
Terry
--
Terry Hancock (hancock@...1838...)
Anansi Spaceworks http://www.AnansiSpaceworks.com
2:50 a.m.
On Friday, March 21, 2008, 9:49:07 PM, Krzysztof wrote:
KK> Felipe Sanches wrote:
> SVG1.1 spec, on session 20:
> The purpose of SVG fonts is to allow for delivery of glyph
outlines in
>> display-only environments. SVG fonts that accompany Web pages must be
>> supported only in browsing and viewing situations. Graphics editing
>> applications or file translation tools must not attempt to convert SVG
>> fonts
>> into system fonts. The intent is that SVG files be interchangeable
>> between
>> two content creators, but not the SVG fonts that might accompany these
>> SVG
>> files. *Instead, each content creator will need to license the given font
>> before being able to successfully edit the SVG file.* The
>>
font-face-name<http://www.w3.org/TR/SVG11/fonts.html#FontFaceNameEleme...
>> indicates the name of licensed font to use for editing.
> Am I getting confused or is this part of the spec really
promoting the use
> of DRM techniques for SVG Fonts?
KK> I think it means that:
KK> 1. SVG fonts are used to enable rendering of SVG images that contain a font
KK> that isn't on your system.
yes.
KK> 2. Because some fonts are copyrighted, if you have licensed i.e. a TTF font,
KK> you should be able to convert it into an SVG font to allow other people to
KK> see it on your web page, however others should not be able to take your
KK> generated SVG font and recreate your licensed TTF font from it.
correct.
KK> 3. I also think it means that editing an SVG image that contains SVG fonts
KK> created from licensed fonts should be impossible unless the original TTF
KK> font is present in your system.
It could be read that way. That isn't the intent. For one thing, there might not be an
'original' font in a different format.
KK> 4. Because the SVG font has the full information required to display a
KK> glyph, it means that respecting those restrictions is up to the goodwill of
KK> developers.
Yes.
KK> I think this basically means that if an SVG font was created from a licensed
KK> font, it's supposed to be "read-only", as well as any document that
uses it,
not exactly read-only. Editing of the SVG file is fine. SVG fonts are not however
particularly suitable to be converted to system (truetype) fonts, for a number of
reasons:
- truetype has restrictions on the type of bezier curves allowed, the placement of control
points, and the intersection of curves. SVG fonts need not follow any of these
restrictions, they are general SVG paths.
- truetype depends on (non-royalty free) hinting programs for high quality display of
small, high contrast, axis-aligned text. SVG does not have font hints - svg text can be
displayed at angles, skewed, in multiple colors, at sizes that are not integral multiples
of one pixel and in positions that are not axis aligned or pixel-grid aligned.
KK> and converting such an SVG font to a system-readable font should be
KK> impossible. I have the impression that this paragraph was put in to appease
KK> font vendors (keep in mind that this spec was originally created by Adobe).
The spec was not "originally created by Adobe".
The editor of the 1.0 spec, and one of the editors of the 1.1 spec, was from Adobe. The
list of authors can be seen in the spec and is rather extensive. A lot of different
companies and individuals contributed to the creation of the SVG spec.
KK> It doesn't advocate DRM in its regular sense, rather something like a
KK> "please do not steal" sign.
Yes.
KK> I think that an SVG font to TTF converter could
KK> comply with this part of the specification, provided it refused to work on
KK> SVG fonts derived from copyrighted fonts.
How would it know? The license info is not machine readable. A person has to make the
decision.
--
Chris Lilley mailto:chris@...157...
Interaction Domain Leader
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
6:54 p.m.
I accidentally sent this to Richard's address first, due to missing
reply-to headers. Would it be possible to make the list add those?
Richard Hughes wrote:
I reckon it would be really nice to use Cairo's user font API to
implement SVG fonts, so that we get good PDF output and suchlike for
free. There are just two minor problems with this plan:
1) Cairo doesn't have a user font API yet. It's due in November.
(http://cairographics.org/roadmap/)
Luckily Behdad Esfahbod's pretty much finished with the API and it's
about to land. You can read his mail at
http://lists.freedesktop.org/archives/cairo/2008-March/013396.html.
- Jari
2) Inkscape doesn't use enough of Cairo yet for this to be just
a
simple plug-in job.
Since the API doesn't exist I have no idea what we would gain from
using Cairo rather than going it alone, however I strongly recommend
that you hook up with some of their people to talk about it. Get an
update on the status of the roadmap too while you're at it.
Richard.
10:42 p.m.
On Wednesday, March 19, 2008, 2:04:16 AM, Felipe wrote:
FS> I will apply for SoC on SVG Fonts implementation. My task will be
FS> basic SVG Fonts support (i.e. reading of xml attributes, proper
FS> rendering and editing). I imagine that there are some extra stuff
FS> that could be done but would not necesarily be part of my task on
FS> SoC. I could work on those after completing the basic SVG Fonts support.
That would be excellent. Basic font rendering is a needed first step.
FS> I am starting this thread to discuss SVG Fonts related wished
FS> features. I will choose among these, which ones I think make sense
FS> to add to my SoC application and which I consider extra work to be done after SoC.
FS> one idea (probably to be implemented after SoC):
FS> Since SVG Fonts actually work as an alternative kind of font file
FS> (a font can be saved as .svg and then used by other SVG drawings)
FS> inkscape could have a font editing UI.
For an editing tool of course there is a lot that can be done, right
up to creating fonts. Although, fontforge already does that part
pretty well
In terms of conversion tools, Batik also does this conversion.
FS> It could have import
FS> scripts to load TrueType fonts and export them as SVG Fonts and
FS> vice-versa. I could also do it for other font types. One issue is
FS> in the exporters because obviously not everything SVG is capable
FS> of doing is supported by TrueType, or other font formats. So, we
FS> would commonly have to deal with glyph degradation when exporting fonts.
Yes. SVG fonts can do things other formats cannot (multicoloured
glyphs, animated glyphs, etc) and similarly other formats do things
SVG can't do (OpenType gsub tables, for example).
FS> Felipe Sanches ("JucaBlues" on irc)
--
Chris Lilley mailto:chris@...157...
Interaction Domain Leader
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
5534
days inactive
5550
days old
inkscape-devel@lists.inkscape.org
13 comments
9 participants
participants (9)
-
Aaron Spike -
Bryce Harrington -
Chris Lilley -
Felipe Sanches -
Jari Rahkonen -
Krzysztof Kosiński -
MenTaLguY -
Richard Hughes -
Terry Hancock