Re: [tex-live] Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
"GW" == George Williams writes: >> Then they have to be there in the CFF separately. The H/D can be >> different from the outlines, eg. due to overshoot. GW> What do you mean by overshoot? GW> Remember tfm metrics are not perfect. There are only 16 possible GW> values for depth or height, and one of these is required to be GW> 0. So in a font with many different glyph sizes the tfm file has GW> already done some kind of grouping operation which can lose a lot GW> of information. GW> All the information about the glyph's shape is contained in its GW> outline. It's going to be far more accurate than a rounded tfm GW> value. No, the glyph height, for example, is used by TeX to put calculate accent positioning over the glyph. And by design, some glyphs like "o" have small "overshoots", which should not lead to a change in caculated accent position. So having glyph dimentions as separate entities (rather than obtained from glyph outline) seems the right thing to do. (added Cc to [EMAIL PROTECTED], as this discussion is most relevant to that list). Best, v. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
On Tue, 2005-01-04 at 15:40, Han-Wen Nienhuys wrote: > Then they have to be there in the CFF separately. The H/D can be > different from the outlines, eg. due to overshoot. What do you mean by overshoot? Remember tfm metrics are not perfect. There are only 16 possible values for depth or height, and one of these is required to be 0. So in a font with many different glyph sizes the tfm file has already done some kind of grouping operation which can lose a lot of information. All the information about the glyph's shape is contained in its outline. It's going to be far more accurate than a rounded tfm value. Now admittedly there an outline may not reach it's extrema at an on-curve point, but finding extrema on a cubic/quadratic is fairly trivial. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
On Tue, 2005-01-04 at 14:11, Han-Wen Nienhuys wrote: > Hmm. I'd say it should contain all info from the TFM > > * metrics (these are entirely unrelated to the extents of the > outlines) The advance widths have their natural place. Height/Depth information: Per glyph Bounding box information is stored before every glyph in a tt file (more accurately than in a tfm file). These data are not stored in a cff file but are easily calculated from outlines. > > * 30 spacing parameters I'm not sure what you mean by this. Are these the font parameter words? If so there may be 8 or 23 or 14... Oh, perhaps I see, if you don't overload them then there are 30 of them. > > * checksum Why? It has no meaning in an sfnt. Sfnts have their own checksums. > > * design size As Rogier van Dalen points out this should be stored as a feature. So I the only things I hear as being needed in a separate table are the spacing parameters -- which I presume to be the font parameter words -- and possibly the checksum -- if someone can explain why this is relevant. Any thoughts on a tag for the table? "TEX ", "TeX ", "TFM " ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
> Remember tfm metrics are not perfect. There are only 16 possible > values for depth or height, and one of these is required to be 0. > So in a font with many different glyph sizes the tfm file has > already done some kind of grouping operation which can lose a lot of > information. Whatever the TeX height and depth values look like, they should be exactly represented in the OpenType font -- remember that those values are *completely independent* from the real glyph shape. Replacing them with bbox values is not possible. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
On 04 Jan 2005 08:04:23 -0800, George Williams <[EMAIL PROTECTED]> wrote: > > Maybe these things ought to be discussed on the OpenType mailing list too? > I brought up ITLC on the OpenType list some time ago, hoping to get it > added to the standard feature list. I was unable to do so. Perhaps if > other people expressed interest we could bring it up again? I didn't even remember that; but looking at the archive it seems there just wasn't much of a discussion. I'd suggest we try again. Note that the Adobe people may not feel the necessity of italic correction with an optical kerning feature built into InDesign. A fair amount of discussion could follow; I, for one, think that there ought to be italic correction on the left side as well. Regards, Rogier ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
[EMAIL PROTECTED] writes: > On Tue, 2005-01-04 at 14:11, Han-Wen Nienhuys wrote: > > Hmm. I'd say it should contain all info from the TFM > > > > * metrics (these are entirely unrelated to the extents of the > > outlines) > The advance widths have their natural place. > Height/Depth information: >Per glyph Bounding box information is stored before every glyph in a >tt file (more accurately than in a tfm file). These data are not >stored in a cff file but are easily calculated from outlines. Then they have to be there in the CFF separately. The H/D can be different from the outlines, eg. due to overshoot. > > * 30 spacing parameters > I'm not sure what you mean by this. Are these the font parameter words? > If so there may be 8 or 23 or 14... Oh, perhaps I see, if you don't > overload them then there are 30 of them. in my TFM reader it says, /* The maximum number of global font parameters we allow. */ #define TFM_MAX_FONTDIMENS 30 I guess they're font parameter words. > > * checksum > Why? It has no meaning in an sfnt. Sfnts have their own checksums. Hmm. Good point. TeX reads checksums when it writes DVI files. I suppose that they're moot as long as TeX itself doesn't read Sfnts > Any thoughts on a tag for the table? "TEX ", "TeX ", "TFM " ... TeX seems nice. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
[EMAIL PROTECTED] writes: > > mailing lists. George already has started with three SFNT tables in > > fontforge: > > > > ITLC italic correction > > TCHL TeX charlist > > TEXL TeX extension list > Actually I didn't add tables, I added new feature tags. > ITLC is a GPOS format 1 feature (allows positioning changes to > single glyph) > TCHL is a GSUB format 3 feature (replaces one glyph with one of > many glyphs) > TEXL is a GSUB format 2 feature (replaces one glyph with many). > > > > Maybe we should add a fourth table to hold the missing bits... > I'd be happy to add a 'TEX ' table (or something similar) to hold TeX > font parameters. What should go in it? (I'd rather have a separate > meaning for each parameter slot than overload them as the tfm file > does). Hmm. I'd say it should contain all info from the TFM * metrics (these are entirely unrelated to the extents of the outlines) * 30 spacing parameters * checksum * design size of course if anything fits elsewhere in the OT font, then it should be stored in the natural location. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
On Tue, 2005-01-04 at 00:09, Werner LEMBERG wrote: > > > Ideally, those OpenType TeX fonts should behave similar to any > > > other OpenType font; this means the loss of italic correction > > > (which isn't available in OpenType fonts), for example, but it > > > assures that the font interface doesn't have to cope with > > > special cases. > > > > That's not going to work completely, not only do we loose italic > > correction, but also design size. Can't we agree with other parties > > (tetex?) on a standard SFNT table for TeX specific information? > > That's an excellent idea, so I'm forwarding this to the relevant > mailing lists. George already has started with three SFNT tables in > fontforge: > > ITLC italic correction > TCHL TeX charlist > TEXL TeX extension list Actually I didn't add tables, I added new feature tags. ITLC is a GPOS format 1 feature (allows positioning changes to single glyph) TCHL is a GSUB format 3 feature (replaces one glyph with one of many glyphs) TEXL is a GSUB format 2 feature (replaces one glyph with many). > > Maybe we should add a fourth table to hold the missing bits... I'd be happy to add a 'TEX ' table (or something similar) to hold TeX font parameters. What should go in it? (I'd rather have a separate meaning for each parameter slot than overload them as the tfm file does). I think information that applies to single glyphs (italic correction, etc.) is better done as GPOS/GSUB features if it can fit in that format. > FWIW, design size information is already in the OpenType specs: "size" > feature (rather than a table). ff doesn't currently support this, but I could add that. > Maybe these things ought to be discussed on the OpenType mailing list too? I brought up ITLC on the OpenType list some time ago, hoping to get it added to the standard feature list. I was unable to do so. Perhaps if other people expressed interest we could bring it up again? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fontforge-devel] Re: UTF8 and (La)TeX backend?
On Tue, 04 Jan 2005 09:09:16 +0100 (CET), Werner LEMBERG <[EMAIL PROTECTED]> wrote: > > > > Ideally, those OpenType TeX fonts should behave similar to any > > > other OpenType font; this means the loss of italic correction > > > (which isn't available in OpenType fonts), for example, but it > > > assures that the font interface doesn't have to cope with > > > special cases. > > > > That's not going to work completely, not only do we loose italic > > correction, but also design size. Can't we agree with other parties > > (tetex?) on a standard SFNT table for TeX specific information? > > [...] > Maybe we should add a fourth table to hold the missing bits... FWIW, design size information is already in the OpenType specs: "size" feature (rather than a table). Maybe these things ought to be discussed on the OpenType mailing list too? Regards, Rogier ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
