well... in general terms, what I need to do is:

Render glyphs (a) using paths described using the same syntax as path:d attribute or (b) using arbitrary chunks of SVG drawing.

I have built two examples and attached to this message their respective rendering in batik.

example1: (batik output: svgfont-batik.png)

<?xml version="1.0" standalone="yes"?> <svg width="400px" height="300px" version="1.1" xmlns = 'http://www.w3.org/2000/svg'> <defs> <font id="Font1" horiz-adv-x="1000"> <font-face font-family="Super Sans" /> <glyph unicode="!" d="M0,0h500v500h-500z"> <circle r='500' cx='500' cy='500' style="fill:none;stroke:green;"/> </glyph> <glyph unicode="@" d="M500,500h500v500h-500z"> <circle r='250' cx='500' cy='500' style="fill:blue;"/> </glyph> </font> </defs> <text x="100" y="100" style="font-size:70;font-family:'Super Sans';fill:red;">A!@A</text> </svg>

The squares are drawn using the path description in the glyph:d attribute The circles are arbitrary SVG declared in the childNode of the glyph nodes.

example 2: (batik output: svgfont-batik-kerning.png)

<?xml version="1.0" standalone="yes"?> <svg width="400px" height="300px" version="1.1" xmlns = 'http://www.w3.org/2000/svg'> <defs> <font id="Font1" horiz-adv-x="1000"> <font-face font-family="Super Sans" /> <glyph unicode="!" d="M0,0h500v500h-500z"> <circle r='500' cx='500' cy='500' style="fill:none;stroke:green;"/> </glyph> <glyph unicode="@" d="M500,500h500v500h-500z"> <circle r='250' cx='500' cy='500' style="fill:blue;"/> </glyph> <hkern u1="!" u2="@" k="1000" /> </font> </defs> <text x="100" y="100" style="font-size:70;font-family:'Super Sans';fill:red;">A!@A</text> </svg>

It is the same as example 1 except that this one has a hkern tag which specifies the kerning between the chars ! and @ With the kerning value k=1000, the two glyphs will overlap so that the center of the circles will be the same and the squares will have a common vertice.

What is needed to make inkscape render this? I suppose that I should provide the kerning info to cairo userfonts and then cairo-user-fonts would call my glyph-rendering functions providing me the proper x,y coordinates. But how do I enable this behaviour just for Super Sans font? I guess there must be a way of registering new fonts with pango. I just don't see exactly how these pieces fit together.

Juca

On Tue, May 13, 2008 at 12:41 PM, Gail Carmichael <gail.banaszkiewicz@...400...> wrote:

Hey Felipe, I forwarded some of the conversation I had with the Pango folks in case it helps. One issue me right now is that I haven't done any specific research regarding SVG fonts (since that wasn't my project). So I'm not completely familiar with what you need to do.

What I was going to do originally was simply to attempt getting Pango to be able to "store" information about more fonts, since the structures we are currently using in memory can't describe anything beyond what CSS can do. The font-specification attribute I added to the style for text is a string generated by Pango and describes a font fully as a result. If I could get Pango to be able to describe more fonts, then the font-specification would in turn be used to represent these fonts in XML (while including as much of the CSS attributes as possible for other programs or for Inkscape to fall back on).

I hope that helps clarify what's going on on my end...?

Gail

Sorry for a late response, but I thought I need to comment on this...

On Tue, May 13, 2008 at 5:29 PM, Richard Hughes <cyreve@...400...> wrote:

There are probably three components involved:

• The text layout stuff in libnrtype/, which I have described to you

already

• livarot/, which is a computational library providing curve and shape

manipulation, including some of the backend support for rasterisation. The path manipulation parts of livarot are in the process of being rewritten as lib2geom.

• display/, which is the controller for rasterising shapes and

presenting them to the canvas. Large chunks of this should get replaced by calls to Cairo.

The important point is that cairo is already used for text when you're in Outline mode. It simply takes the glyphs as paths and renders them using cairo's path calls. So no cairo text handling is involved at all. Here's where the text outlines are obtained in nr_arena_glyphs_group_render:

NArtBpath *bpath = (NArtBpath *) g->font->ArtBPath(g->glyph);

where g->font is font_instance*. Therefore, all the pango magic, figuring out glyphs etc. is apparently all done within font_instance. Sure I'd prefer to keep it that way, as it will make cairofication of the main rendering easier. But if you have reasons to change that, please feel free to discuss that.

...

• does that mean we need to replace livarot? How to proceed?

Eventually yes, as it is very hard to maintain - hairy code, unfixable bugs etc.

Yes, but that's not your job. The difficulty is that the text code spits out these Path and Shape types, which are not at all conducive to being fed into Cairo.

Actually it also spits out NArtBpath*, which is then easy to feed to cairo, as the above shows

It is interesting to note, however, that you'll have to change the Path/Shape stuff anyway even if you don't go with Cairo because user glyphs can be so much more than just style+outline: they can be entire groups of multicoloured objects.

Path and Shape classes eventually should be eliminated in favor of 2geom path representation and/or NArtBpath which has an easy 1:1 mapping to 2geom (or so I was told by Johan).

...

"Getting text layout to use Cairo for output rather than libnr."

...

Can you show me where does that output reside in the code?

libnrtype/FontInstance.cpp, RasterFont.cpp

I'm not sure this is what was asked here - output is actually in nr-arena-glyphs and it already uses cairo in outline mode, changing it to use it for normal mode too will be easy. Again, all we need is a way to get the path outlines from font_instance or some equivalent.