If one takes a look at the kerning pairs of a font with many accented letters, for instance lmr10, there are many "duplicate" pairs, in the sense that in addition to "ko" there also appear "kó", "kò", "kô" and so forth, and "ke", "ké", etc., obviously with the same kerning value, and if we had \'k (accented k) then all of the combinations again. If a new accented letter gets added, all its pais have to be encoded. There is clearly some logic missing there. The idea is that something which is at the right like k, plus something which is at the left like o, needs a kerning of such and such. While the quadratic grouth of pairs is still tractable for normal text with the current speed and memory capacities of computers, it becomes out of control in math, where the possible pairs is beyond any tabulation capacity. I for example had recently Q\Sigma, which clearly requires kerning. The underlying problem is that TeX does not take into account the actual shape of the glyphs, but just its enclosing rectangle. Since this is not sufficent for high quality typesetting there are two pieces of information relating to the shape of the gliph beyond the enclosing rectangle that TeX knows about: the kerning pairs and the italic correction. There are just two patches that leave many situations to be manually adjusted by the editor (I refer to the person), depending on his patience and quality standards, specially in math, where both the pairs of gliphs that get combined and the relative position of them is virtualy unlimited. While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to the rectangle enclosing the glyph, another shape were known, not so complicated as a glyph's shape but not so crude as a rectangle. I could be restricted to a one-piece polygon without holes enclosing the character and leaving a little space between its border and the character (as the character's box currently does). For example, the polygon for the letter k could be a rectangle with a wedge intruding at the right side, while that of o, ó, e, etc. could be an octagon. So when these characters were placed together it would be done so that the respective polygons touch, instead of the rectangular boxes as is now the case, and the need of kerning would disappear. This approach would: -- reduce the kerning pairs drastically -- need a linear grouth with the number of glyphs in the font (the polygons) instead of a quadratic one. -- New glyphs, specialy adorned variants of existing ones, would automatically get the correct spacing with existing ones. -- Pairs that seldom appear and are thus not considered in the kerning tables, would also get the right spacing automatically. -- The unlimited possible combinations inside math would get handled correctly. Most of them or at least many. Thus, the need for dozens of \! \, \phantoms and like stuff would decrease substantialy. Here are some examples: \Bigg)_{\!0} (or was it even _{\!\!0}?) f^2\,) %here it is the left protruding of the )'s polygon that would come into play. 1/\!\sqrt{3} This requires adding another piece of info per-character in the font. Now I can't remember how the tables of an OT font are orginized and don't know whether this is possible or not. The inconvenience I see in trying to compute the spacements based directly on the shape of the gliph (with respect to the polygons I'm proposing), appart from the many bugs that could be present till it finally got properly programmed, is that it is too big a jump form the current glyph placement algorithms in math, but it may well be that my fears are unjustifed. The polygon approach has also the advantage that it is easier to define the polygons so as to obtain the current spacing between the most common kerning pairs, while it would be more difficult to program an algorithm based on the glyphs' shapes achieving the same effect, but on the other side it need not be better to exactly preserve the current kerning values. It may be too son for proposing this now, but I'm sure this will sooner or later (possibly later) come to be discussed, since for the finest text editor, a glyph placement in math based solely on the rectangle of the glyphs and the italic correction cannot possibly be the definitive solution. Cheers to all Javier A. Múgica
2009/10/20 Javier Múgica
While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to
It mustn't be. I think what you are looking for is optical kerning. InDesign does it: http://tinyurl.com/yh95sza And a short search found iKern: http://ikern.com/k1/ Best Martin
2009/10/20 Javier Múgica
: While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to
It mustn't be. I think what you are looking for is optical kerning.
I don't think so. I presume what he's proposing is something similar to what Microsoft is doing (or trying to do) in its new math font tables. Javier http://www.tex-tipografia.com
listas@tex-tipografia.com wrote:
2009/10/20 Javier Múgica
: While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to It mustn't be. I think what you are looking for is optical kerning.
I don't think so. I presume what he's proposing is something similar to what Microsoft is doing (or trying to do) in its new math font tables.
If something like that microsoft stuf was in the font, it would be quite easy for luatex to make use of it. Interpreting the actual charstrings would go too far, but applying some sort of blocky shape (especially if it only has horizontal and vertical lines) would be quite easy. It sounds like thus needs a lot of work on the font design side, though. Best wishes, Taco
Taco Hoekwater escribió:
If something like that microsoft stuf was in the font, it would be quite easy for luatex to make use of it. Interpreting the actual charstrings would go too far, but applying some sort of blocky shape (especially if it only has horizontal and vertical lines) would be quite easy. It sounds like thus needs a lot of work on the font design side, though.
Microsoft calls them "cut-ins" and they are defined in the MATH table. They are intended for sub- and superscript (ie, apparently not for general combinations of characters), and may be specified for each quadrant (each quadrant may have multiple cut-ins). Lines are horizontal and vertical. Cheers Javier
Javier Bezos wrote:
Taco Hoekwater escribió:
If something like that microsoft stuf was in the font, it would be quite easy for luatex to make use of it. Interpreting the actual charstrings would go too far, but applying some sort of blocky shape (especially if it only has horizontal and vertical lines) would be quite easy. It sounds like thus needs a lot of work on the font design side, though.
Microsoft calls them "cut-ins" and they are defined in the MATH table. They are intended for sub- and superscript (ie, apparently not for general combinations of characters), and may be specified for each quadrant (each quadrant may have multiple cut-ins). Lines are horizontal and vertical.
I know, and luatex already does that. Best wishes, Taco
Javier Múgica
While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to the rectangle enclosing the glyph, another shape were known, not so complicated as a glyph's shape but not so crude as a rectangle.
This is roughly what I do with my (unfortunately not documented) "spacing by anchors" fontforge scripts at sortsmill.googlecode.com. I say "roughly" because I use only a very limited number of manually chosen horizontal cross-sections of a "virtual" surrounding shape, and because the samples are not stored in the font (there being no typesetting or word processing software that can use them) but used to compute class-based kerning tables. Also I have made no attempt to support mathematical typesetting. The idea, though, that typesetting software could use such an approach to space glyphs rapidly, on the fly, given the shape-approximations, has occurred to me. (With fontforge one could look at the spacing point placements of my fonts, for instance http://code.google.com/p/sortsmill/source/browse/lindenhill/LindenHill.sfd which I have been working on recently.)
I went on Hollydays the day after sending the message. That's why I didn't reply to the messages. What I mean is that the glyphs be placed so that their polygonal shapes touch, instead of their boxes. For example, if that of the k has a triangular hole at the right and that of the o is an octagon, then placing these glyphs together within a word, first the k and then the o, would make the octagon of the o to go inside the hole of the k, so that both shapes touch. This is why most kerning pairs would not be needed any more. The idea that the polygons touch need not be restricted to letters within a word but may be applied also to math.
but applying some sort of blocky shape (especially if it only has horizontal and vertical lines) would be quite easy.
Maybe diagonal lines could be faked by a series of small steps. --Javier A.
participants (6)
-
Barry Schwartz
-
Javier Bezos
-
Javier Múgica
-
listas@tex-tipografia.com
-
Martin Schröder
-
Taco Hoekwater