You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/05/16 13:58:39 UTC
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Some background on my latest change. I found out that certain TrueType
fonts were off vertically inside their line area. It turned out it has
to do with different interpretations of the "ascender" and descender"
values which are part of font metrics and which FOP uses to determine
the baseline placement. FOP currently works with the assumption that the
ascender+descender fit into the "em box". However, in some TrueType
fonts the ascender is sometimes given as the maximum elevation of a font
which can go way beyond the em box. BTW, this is always true for
Java2D/AWT which makes determining the baseline difficult. I've recently
implemented similar "hacks" in the AWT font metrics adapter which I'll
commit shortly.
You can see the effect of rev 406917 here:
http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk.before.pdf
http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk.after.pdf
The second and third lines are painted using TrueType fonts, the first
is a base 14 font and the last a Type 1 font.
IMO, my change is an improvement but not a clean fix. I think TrueType
has better information on the baseline somewhere (havn't found it, yet).
I didn't look closer into the cases where multiple accents are stacked
on a glyph. That's basically the reason why the fonts can go beyond the
em box. At some point we may need to revisit our model of line building
to accomodate these glyphs. I guess I have to buy a book about
typography one day... :-)
On 16.05.2006 13:45:01 jeremias wrote:
> Author: jeremias
> Date: Tue May 16 04:44:57 2006
> New Revision: 406917
>
> URL: http://svn.apache.org/viewcvs?rev=406917&view=rev
> Log:
> Improved baseline detection in TTFReader for TrueType fonts. Ascender and descender values were sometimes not in line with FOP's expectations.
> Changed some log output from debug to trace level.
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFile.java
> xmlgraphics/fop/trunk/status.xml
<snip/>
Jeremias Maerki
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk:
src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, May 17, 2006 at 09:20:55PM +0800, Manuel Mall wrote:
> On Wednesday 17 May 2006 15:47, Gennadiy Tsarenkov wrote:
> > Jeremias,
> >
> > Wednesday, May 17, 2006, 10:17:36 AM, you wrote:
> >
> > JM> On 17.05.2006 02:02:52 Manuel Mall wrote:
> > >> I don't know anything about LaTeX. Does it understand TrueType
> > >> fonts? If so would it be worthwhile to check its source code?
> >
> > JM> I don't think so. I can't find any reference. But I've never
> > worked with JM> LaTeX.
> <snip/>
> > Anyway, for correct baseline-ing it requires only text
> > metric files for any used font to be present.
>
> Exactly, but that is the problem here. How to generate the correct text
> metric data for baselining from a .ttf file given that it appears it
> can contain conflicting and/or not Open/TrueType spec compliant
> information?
TeX does indeed not know anything about TrueType fonts, or about any
font for that matter. TeX has a strict separation between layout and
rendering. TeX creates the layout in a dvi file, renderers do the
rendering, e.g. a dvi viewer, the dvi to PS converter. PdfTeX does
both, however.
The knowledge about TrueType font metrics resides in the utilities
that generate TeX font metrics (tfm files) from the ttf metric files. I
do not remember which utility does that; the freetype library is very
popular in those areas. In my notes I find the following tools:
ttf2tfm, ttf2pk, ttf2afm, ttf2pfb, ttf2pt1. And an article 'Using
TrueType fonts with teTEX and dvips'. All on the TeXLive7 cdrom (a few
years old now); I suppose the most recent TeXLive distribution has the
same or similar tools.
ttf2tfm does the metrics conversion.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Manuel Mall <mm...@arcus.com.au>.
On Wednesday 17 May 2006 15:47, Gennadiy Tsarenkov wrote:
> Jeremias,
>
> Wednesday, May 17, 2006, 10:17:36 AM, you wrote:
>
> JM> On 17.05.2006 02:02:52 Manuel Mall wrote:
> >> I don't know anything about LaTeX. Does it understand TrueType
> >> fonts? If so would it be worthwhile to check its source code?
>
> JM> I don't think so. I can't find any reference. But I've never
> worked with JM> LaTeX.
<snip/>
> Anyway, for correct baseline-ing it requires only text
> metric files for any used font to be present.
Exactly, but that is the problem here. How to generate the correct text
metric data for baselining from a .ttf file given that it appears it
can contain conflicting and/or not Open/TrueType spec compliant
information?
Manuel
Re[2]: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Gennadiy Tsarenkov <g....@sam-solutions.net>.
Jeremias,
Wednesday, May 17, 2006, 10:17:36 AM, you wrote:
JM> On 17.05.2006 02:02:52 Manuel Mall wrote:
>> I don't know anything about LaTeX. Does it understand TrueType fonts? If
>> so would it be worthwhile to check its source code?
JM> I don't think so. I can't find any reference. But I've never worked with
JM> LaTeX.
Neither TeX or LaTeX understand TTF fonts. They used much more complex
(and thus much more flexible) font system comparing to the FOP.
Anyway, for correct baseline-ing it requires only text metric files
for any used font to be present. At the translation moment it converts
text metric files into binary representation to speed up generation
procedure. Real font files are used only in rendering driver to
consider various device resolutions. So, to compare FOP and TeX
baseline behavior it would be enough to compare metric files.
As you know, we were working on MathML rendering using JEuclid. In
order to solve the baseline problem (and not only base line, there is
bigger problem with some TrueType fonts when you try to put
superscript or subscript after the italic text) we modified the FOP
metric files. Within next couple of days I'll release JEuclid 3.0
which uses updated metrics. May be this would help you to decide which
way this baseline have to be solved.
--
Best regards,
Gennadiy mailto:g.tsarenkov@sam-solutions.net
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk:
src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
<snip/>
>>Also do we know what Foray Fonts does?
>
>
> Prefers the OS/2.sTypeAscender over hhea.Ascender just like FOP did
> before my patch.
FWIW: I've just noticed Victor of the issue. Just waiting for his
comments.
BTW, my work on fonts (which already wasn't going very fast) may further
suffer from my participation in the SoC. If anyone wants to take the
lead...
Vincent
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 17.05.2006 02:02:52 Manuel Mall wrote:
> On Tuesday 16 May 2006 19:58, Jeremias Maerki wrote:
> > Some background on my latest change. I found out that certain
> > TrueType fonts were off vertically inside their line area. It turned
> > out it has to do with different interpretations of the "ascender" and
> > descender" values which are part of font metrics and which FOP uses
> > to determine the baseline placement. FOP currently works with the
> > assumption that the ascender+descender fit into the "em box".
> > However, in some TrueType fonts the ascender is sometimes given as
> > the maximum elevation of a font which can go way beyond the em box.
> > BTW, this is always true for Java2D/AWT which makes determining the
> > baseline difficult. I've recently implemented similar "hacks" in the
> > AWT font metrics adapter which I'll commit shortly.
> >
> > You can see the effect of rev 406917 here:
> > http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk
> >.before.pdf
> > http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk
> >.after.pdf The second and third lines are painted using TrueType
> > fonts, the first is a base 14 font and the last a Type 1 font.
> >
> > IMO, my change is an improvement but not a clean fix. I think
> > TrueType has better information on the baseline somewhere (havn't
> > found it, yet). I didn't look closer into the cases where multiple
> > accents are stacked on a glyph. That's basically the reason why the
> > fonts can go beyond the em box. At some point we may need to revisit
> > our model of line building to accomodate these glyphs. I guess I have
> > to buy a book about typography one day... :-)
>
> Your fix triggered me looking into the specs and some actual ttf files
> and I can't make proper sense of it all as well. The whole vertical
> font metrics area seem to be quite messy, see for example:
> http://typophile.com/wiki/Vertical%20Metrics%20How-To
Very interesting article. What's important for us is that the
hhea.lineGap value is uninteresting/irrelevant for us since we have the
line-height property (default to 1.2) which we use for
baseline-to-baseline measurement. That means we can't really follow the
recommendation to only use OS/2.winAscender and OS/2.winDescender. :-(
> I don't know anything about LaTeX. Does it understand TrueType fonts? If
> so would it be worthwhile to check its source code?
I don't think so. I can't find any reference. But I've never worked with
LaTeX.
> Also do we know what Foray Fonts does?
Prefers the OS/2.sTypeAscender over hhea.Ascender just like FOP did
before my patch.
http://svn.sourceforge.net/viewcvs.cgi/foray/trunk/foray/foray-font/src/java/org/foray/font/format/TTFFont.java?view=markup
> Until someone comes up with a better (cleaner?) solution to determine
> the actual baseline position for a given truetype / opentype font your
> patch looks good to me.
>
> <snip/>
> >
> > Jeremias Maerki
>
> Manuel
Jeremias Maerki
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Posted by Manuel Mall <mm...@arcus.com.au>.
On Tuesday 16 May 2006 19:58, Jeremias Maerki wrote:
> Some background on my latest change. I found out that certain
> TrueType fonts were off vertically inside their line area. It turned
> out it has to do with different interpretations of the "ascender" and
> descender" values which are part of font metrics and which FOP uses
> to determine the baseline placement. FOP currently works with the
> assumption that the ascender+descender fit into the "em box".
> However, in some TrueType fonts the ascender is sometimes given as
> the maximum elevation of a font which can go way beyond the em box.
> BTW, this is always true for Java2D/AWT which makes determining the
> baseline difficult. I've recently implemented similar "hacks" in the
> AWT font metrics adapter which I'll commit shortly.
>
> You can see the effect of rev 406917 here:
> http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk
>.before.pdf
> http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk
>.after.pdf The second and third lines are painted using TrueType
> fonts, the first is a base 14 font and the last a Type 1 font.
>
> IMO, my change is an improvement but not a clean fix. I think
> TrueType has better information on the baseline somewhere (havn't
> found it, yet). I didn't look closer into the cases where multiple
> accents are stacked on a glyph. That's basically the reason why the
> fonts can go beyond the em box. At some point we may need to revisit
> our model of line building to accomodate these glyphs. I guess I have
> to buy a book about typography one day... :-)
Your fix triggered me looking into the specs and some actual ttf files
and I can't make proper sense of it all as well. The whole vertical
font metrics area seem to be quite messy, see for example:
http://typophile.com/wiki/Vertical%20Metrics%20How-To
I don't know anything about LaTeX. Does it understand TrueType fonts? If
so would it be worthwhile to check its source code?
Also do we know what Foray Fonts does?
Until someone comes up with a better (cleaner?) solution to determine
the actual baseline position for a given truetype / opentype font your
patch looks good to me.
<snip/>
>
> Jeremias Maerki
Manuel