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 Glenn Adams <gl...@skynav.com> on 2010/09/06 07:58:41 UTC

base 14 font kerning

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.

Re: base 14 font kerning

Posted by Glenn Adams <gl...@skynav.com>.
Agreed. That is why I thought it best not to change that, while still adding
the ability for the user to configure it.

G.

On Tue, Sep 7, 2010 at 5:00 PM, Chris Bowditch
<bo...@hotmail.com>wrote:

> Glenn Adams wrote:
>
> Hi Glenn/Jeremias,
>
>
>  I've already implemented in my complex scripts work, so it will make it
>> into trunk in due time. However, I think I'll leave the default setting as
>> it is for the time being. Users can explicitly enable it via their config.
>> We can take up the issue of whether to change the default at a future time.
>>
>
> I do not like the idea of changing the default value of Kerning from off to
> on. The reason being that users who decide to upgrade their FOP version will
> suddenly find the appearance of their documents changing. Better to let
> users who are unsatisfied with the default inter character spacing to go and
> enable kerning than force users to regression test every document to make
> sure the changes to appearance is acceptable.
>
> Thanks,
>
> Chris
>
>
>> G.
>>
>>
>> On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki <dev@jeremias-maerki.ch<mailto:
>> dev@jeremias-maerki.ch>> wrote:
>>
>>    I think that is for historical reasons. When this was implemented (I
>>    think it was me) I guess we didn't want to change the layout behaviour
>>    for existing users. For a long time, kerning for base 14 fonts was not
>>    supported.
>>
>>    http://svn.apache.org/viewvc?view=revision&revision=389086
>>    <http://svn.apache.org/viewvc?view=revision&revision=389086>
>>
>>    You're right: this setting doesn't seem to be tied into the
>>    FontManagerConfigurator. It would be great if you added that.
>>
>>    That said, I'm not sure if enabling that would be so bad. I guess I'm
>>    not opposed to it.
>>
>>    On 06.09.2010 07:58:41 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.
>>
>>
>>
>>
>>    Jeremias Maerki
>>
>>
>>
>

Re: base 14 font kerning

Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,

On 07/09/10 10:00, Chris Bowditch wrote:
> Glenn Adams wrote:
> 
> Hi Glenn/Jeremias,
> 
>> I've already implemented in my complex scripts work, so it will make
>> it into trunk in due time. However, I think I'll leave the default
>> setting as it is for the time being. Users can explicitly enable it
>> via their config. We can take up the issue of whether to change the
>> default at a future time.
> 
> I do not like the idea of changing the default value of Kerning from off
> to on. The reason being that users who decide to upgrade their FOP
> version will suddenly find the appearance of their documents changing.
> Better to let users who are unsatisfied with the default inter character
> spacing to go and enable kerning than force users to regression test
> every document to make sure the changes to appearance is acceptable.

I disagree. New users don’t care whether kerning was enabled in previous
versions or not. They just want their documents to look good and don’t
want to be told about some obscure configuration option. In fact, they
may not even know what kerning is and they don’t want to be bothered
with that.

Kerning is something that font designers spend time to define in order
for their fonts to look good, and not handling kerning is a bug. Kerning
should be enabled by default.

For users who are upgrading their version of FOP, a warning in the
release notes should be enough. They /will/ have to regression test
their documents anyway.


Vincent


> Thanks,
> 
> Chris
> 
>>
>> G.
>>
>> On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki
>> <dev@jeremias-maerki.ch <ma...@jeremias-maerki.ch>> wrote:
>>
>>     I think that is for historical reasons. When this was implemented (I
>>     think it was me) I guess we didn't want to change the layout
>> behaviour
>>     for existing users. For a long time, kerning for base 14 fonts was
>> not
>>     supported.
>>
>>     http://svn.apache.org/viewvc?view=revision&revision=389086
>>     <http://svn.apache.org/viewvc?view=revision&revision=389086>
>>
>>     You're right: this setting doesn't seem to be tied into the
>>     FontManagerConfigurator. It would be great if you added that.
>>
>>     That said, I'm not sure if enabling that would be so bad. I guess I'm
>>     not opposed to it.
>>
>>     On 06.09.2010 07:58:41 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.
>>
>>
>>
>>
>>     Jeremias Maerki
>>
>>
> 

Re: base 14 font kerning

Posted by Chris Bowditch <bo...@hotmail.com>.
Glenn Adams wrote:

Hi Glenn/Jeremias,

> I've already implemented in my complex scripts work, so it will make it 
> into trunk in due time. However, I think I'll leave the default setting 
> as it is for the time being. Users can explicitly enable it via their 
> config. We can take up the issue of whether to change the default at a 
> future time.

I do not like the idea of changing the default value of Kerning from off 
to on. The reason being that users who decide to upgrade their FOP 
version will suddenly find the appearance of their documents changing. 
Better to let users who are unsatisfied with the default inter character 
spacing to go and enable kerning than force users to regression test 
every document to make sure the changes to appearance is acceptable.

Thanks,

Chris

> 
> G.
> 
> On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki <dev@jeremias-maerki.ch 
> <ma...@jeremias-maerki.ch>> wrote:
> 
>     I think that is for historical reasons. When this was implemented (I
>     think it was me) I guess we didn't want to change the layout behaviour
>     for existing users. For a long time, kerning for base 14 fonts was not
>     supported.
> 
>     http://svn.apache.org/viewvc?view=revision&revision=389086
>     <http://svn.apache.org/viewvc?view=revision&revision=389086>
> 
>     You're right: this setting doesn't seem to be tied into the
>     FontManagerConfigurator. It would be great if you added that.
> 
>     That said, I'm not sure if enabling that would be so bad. I guess I'm
>     not opposed to it.
> 
>     On 06.09.2010 07:58:41 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.
> 
> 
> 
> 
>     Jeremias Maerki
> 
> 


Re: base 14 font kerning

Posted by Glenn Adams <gl...@skynav.com>.
I've already implemented in my complex scripts work, so it will make it into
trunk in due time. However, I think I'll leave the default setting as it is
for the time being. Users can explicitly enable it via their config. We can
take up the issue of whether to change the default at a future time.

G.

On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:

> I think that is for historical reasons. When this was implemented (I
> think it was me) I guess we didn't want to change the layout behaviour
> for existing users. For a long time, kerning for base 14 fonts was not
> supported.
>
> http://svn.apache.org/viewvc?view=revision&revision=389086
>
> You're right: this setting doesn't seem to be tied into the
> FontManagerConfigurator. It would be great if you added that.
>
> That said, I'm not sure if enabling that would be so bad. I guess I'm
> not opposed to it.
>
> On 06.09.2010 07:58:41 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.
>
>
>
>
> Jeremias Maerki
>
>

Re: base 14 font kerning

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I think that is for historical reasons. When this was implemented (I
think it was me) I guess we didn't want to change the layout behaviour
for existing users. For a long time, kerning for base 14 fonts was not
supported.

http://svn.apache.org/viewvc?view=revision&revision=389086

You're right: this setting doesn't seem to be tied into the
FontManagerConfigurator. It would be great if you added that.

That said, I'm not sure if enabling that would be so bad. I guess I'm
not opposed to it.

On 06.09.2010 07:58:41 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.




Jeremias Maerki


Re: base 14 font kerning

Posted by Glenn Adams <gl...@skynav.com>.
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 <vh...@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.
> >
>

Re: base 14 font kerning

Posted by Vincent Hennebert <vh...@gmail.com>.
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.
>