Hello,

thanks for the feedbacks! I will try to reply to each of them bellow.

And there is one more thing -- I am not really skilled in C or C++. While I tried to use the former one, I very much prefer Python and I am not sure how this might fit into your plans. If an python extension is not exactly what you were expecting, what would do it?

On 5/1/06, bulia byak < buliabyak@...400...> wrote:

On the other hand, such autokerning algorithms almost certainly have been researched, and maybe even implemented in some software. How aware are you of other similar efforts? In what ways your proposal is different or better? What aspects are you planning to take into account? For example, relative kerning should ideally change depending on the letterspacing (tracking). Also, diacritical marks have less "visual importance" than parts of the letter proper, and therefore should less affect kerning. Please share as much details as possible about the algorithm you have in mind.

From what I saw till now, following works might be worth reading:

Han The Tanh: Micro-typographic extensions to the TeX typesetting system David Kindersley: Optical letter spacing for new printing systems Michael F. Plass: Optimal Pagination Techniques for Automatic Typesetting Systems Stefan Wohlfeil: On the Pagination of Complex, Book-like Documents

However, it seems to me that various informations at least as useful as the above mentioned ones can be found in numerous forums and discussion groups. For instance: http://mail.gnome.org/archives/gtk-i18n-list/2002-October/msg00037.html

To be honest, I was thinking that the actual research would be part of the project. There are several places where I could start searching though: from balancing the closest distances between two glyphs, balancing the (black) area taken by the letters or comparing the dominant angles of the letters; to quite heavy ones, like maintaining the appearance of "grayness" of the text or analyzing the actual shapes to find relevant features. Or maybe, approach similar to how Nikon's matrix metering works, that is, breaking down the scene or glyphs into segments and finding the most appropriate preset and to kern by that preset. But then again, these are really wild guesses.

It seems that the question is to find what exactly would work. If the method would be just plain simple, that will be only a plus.

There are a few aspects to better take into account. The most important thing is to find out how to auto kern one trivial line with Latin characters. Then, where to place the letters lying on the edge of a text block ( e.g. "A" or "-" should lean out a bit from the block). Next, if the text is justified (aligned to both left and right) how to fill best the block. This sounds similar to your relative kerning vs. letterspacing (tracking). It all may depend on the actual size of the letters as well but right know this is all I can say about it.

Another useful thing could be to document well the whole procedure so other people could easily pick it up and extend it.

Of software which implements similar ideas I know InDesign and iKern. I also read that Ikarus' Kernus and Fontographer are capable of automatic kerning but I have not tried. However, these applications are closed sourced which means it is more difficult to take advantage of the implementations for another applications. This is another aspect I am trying to address here.

On 5/1/06, Bryce Harrington < bryce@...961...> wrote:

Yes, we're quite open to ideas beyond what's listed. In your proposal make sure to explain the need, and include links to Inkscape feature requests where possible.

By "kerning" I hope for better laid out documents for more pleasant reading and "automatic" should save time, effortlessly. Another good thing would be, if people could re-use this kind of thing in their software, read open source.

The closest feature request I found is this: http://sourceforge.net/tracker/index.php?func=detail&aid=1083697&gro...

And from Scribus: http://nashi.altmuehlnet.de/pipermail/scribus/2005-September/013235.html

On 5/1/06, Tavmjong Bah < tavmjong@...8...> wrote:

Extending optical kerning for text on a path might be an interesting challenge if optical kerning for normal text not a big enough SoC project. It could be useful even for fonts with kerning pairs.

While undoubtedly useful, I believe the auto kern of normal text alone can keep me quite busy. If not, it is definitely worth considering and perhaps it would be also useful to try to integrate this more tightly into Inkscape (via, err, C++).

On 5/1/06, Richard Hughes < cyreve@...400...> wrote:

It may be more sensible to do the sort of low-level trickery I think you're thinking of in Pango rather than Inkscape, particularly since the criteria for ideal spacing could depend on the script the text is using (and don't get me started on kashida spacing, spawn of Iblis that it is).

Alternatively, Tav's textpath suggestion is a good one. We don't support either the method="stretch" or spacing="auto" attributes on <textpath>, both of which you could have fun with. (see http://www.w3.org/TR/SVG11/text.html#TextPathElement).

In my opinion, the question is not whether integrate this into Pango, Inkscape or Scribus -- it looks like there is surprisingly little information on how the algorithm to implement looks like, how exactly does the auto kern works. To try to find the answer is the very basis of my proposal.

Ok. Thanks for the inputs! I'll write down the proposal then.

On 5/3/06, bulia byak <buliabyak@...400...> wrote:

I agree with others that you should start with text on path. First, because this is required SVG functionality that we miss (spacing="auto"); second, because typically gaps in the text on path are much worse than in plain text and would benefit more from an automatic spacer; and thid, because this problem is more general, and if you find a good solution for it, you will have no problem adapting it for the simpler horizontal text case.

Those all are sound reasons, so ok, I agree, too.

I'm not sure it's possible to do this as an extension, though, because

this is core SVG functionality. But you can code a prototype in Python and then port it into Inkscape with our help.

Yes, please. Any help would be mostly welcomed!