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)
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
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.
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
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-namehttp://www.w3.org/TR/SVG11/fonts.html#FontFaceNameElementelement 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?
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-namehttp://www.w3.org/TR/SVG11/fonts.html#FontFaceNameElementelement 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.
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
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
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
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-namehttp://www.w3.org/TR/SVG11/fonts.html#FontFaceNameElementelement 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.
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:
- Cairo doesn't have a user font API yet. It's due in November.
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
- 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.
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)
participants (9)
-
Aaron Spike -
Bryce Harrington -
Chris Lilley -
Felipe Sanches -
Jari Rahkonen -
Krzysztof Kosiński -
MenTaLguY -
Richard Hughes -
Terry Hancock