I just took a look, and that bug seems to be a Type1 AFM/PS issue, different
from the enabling/disabling of base14 font kerning.

However, in the comment thread of it, you do make a point that is worth
repeating for those who aren't aware of it, namely, kerning occurs between
glyphs, and not characters.

The problem is that many readers do not distinguish between a character and
a glyph. I wrote a series of articles on this subject in 1991, a good deal
of which made it into ISO/IEC TR 15285 *Information technology - An
operation model for characters and glyphs*, which I co-authored. Some of
this information can also be found in http://www.w3.org/TR/charmod/, e.g.,
at Units of visual
rendering<http://www.w3.org/TR/charmod/#sec-VisualRenderingUnits>
.

In the context of FOP, it is important to keep in mind the distinction and
to translate when necessary. For example, Font.getCharWidth() returns the x
advancement of the glyph associated with the single Java char parameter,
which encodes a single UTF-16 code element, which is interpreted as a
Unicode scalar value (in the BMP), is then mapped through the CMAP (or
equivalent) to a glyph identifier (glyph code) associated with an x
advancement. One might have instead created three methods:

getXAdvanceUsingBMPCode(char code)         // 0 <= code < 65536; code !=
surrogate
getXAdvanceUsingUnicodeScalar(int code)    // 0 <= code < 1114112; code !=
surrogate
getXAdvanceUsingGlyphCode(int code)        // 0 <= code <
font.getGlyphCount()

At present, the method Font.getCharWidth(char) is equivalent to the first of
the above, getXAdvanceUsingBMPCode, though it does not check for invalid use
of surrogates.

Also, as I've pointed out in the past, there are more than a few places in
FOP where a Unicode Scalar should be passed as an int value instead of using
the Java char type, which technically denotes a UTF-16 encoding element.

G.

On Wed, Sep 8, 2010 at 9:52 PM, Vincent Hennebert <vhenneb...@gmail.com>wrote:

> Hi,
>
> I’m just remembering this bug, that may affect you:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48766
>
> Vincent
>
>
> On 06/09/10 06:58, Glenn Adams wrote:
> > Is there a reason that kerning of the base 14 fonts is disabled by
> default?
> >
> > Furthermore, except by programmatic means, there does not seem to be a
> way
> > to enable it except by using FontManager.setBase14KerningEnabled() or the
> > deprecated method FopFactory.setBase14KerningEnabled(). This technique is
> > used to enable it during testing in one test case:
> > layoutengine/standard-testcases/kerning_1_on.xml, by means of special
> code
> > in org.apache.fop.layoutengine.TestEnvironment.
> >
> > However, there appears no way for a user to enable it via non-programmitc
> > means. To support this (which I need in testing the new generalized
> position
> > adjustments for text drawing), I'm adding a base14-kerning element to be
> > placed in the top-level fop element in the FOP configuration file, e.g.,
> >
> > <fop>
> >   ...
> >   <base14-kerning>true</base14-kerning>
> >   ...
> > </fop>
> >
> > The rationale for making this a child of the top-level fop element is
> that
> > the enable/disable state is presently maintained in the singleton
> > FontManager instance, which is configured (in FontManagerConfigurator)
> from
> > other top-level children of the fop element.
> >
> > For consistency, it my be better to enable base14 kerning by default,
> then
> > allow a user to disable it using the above mechanism. However, I have not
> > made this latter change (yet).
> >
> > Comments?
> >
> > G.
> >
>

Reply via email to