Re: base 14 font kerning
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 d...@jeremias-maerki.ch mailto:d...@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=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=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-kerningtrue/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
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-kerningtrue/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
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 renderinghttp://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.comwrote: 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-kerningtrue/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
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 d...@jeremias-maerki.ch mailto:d...@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=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=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-kerningtrue/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
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 bowditch_ch...@hotmail.comwrote: 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 d...@jeremias-maerki.chmailto: d...@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=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=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-kerningtrue/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
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 d...@jeremias-maerki.chwrote: 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=revisionrevision=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-kerningtrue/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
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-kerningtrue/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.
