[jira] [Resolved] (FOP-2559) [PATCH] Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-2559. Resolution: Duplicate Dup of FOP-2557 > [PATCH] Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Labels: patch > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2559) [PATCH] Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunlinyao updated FOP-2559: Labels: patch (was: ) > [PATCH] Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Labels: patch > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2559) [PATCH] Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2559: --- Summary: [PATCH] Kerning doesn't work for OTF/CFF font (was: Kerning doesn't work for OTF/CFF font) > [PATCH] Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2559) Kerning doesn't work for OTF/CFF font
chunlinyao created FOP-2559: --- Summary: Kerning doesn't work for OTF/CFF font Key: FOP-2559 URL: https://issues.apache.org/jira/browse/FOP-2559 Project: FOP Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: chunlinyao Priority: Minor According to the spec. "OpenType™ fonts containing CFF outlines are not supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2559) Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunlinyao updated FOP-2559: Attachment: patch.txt I Enabled advanced features for OTF/CFF by the attached patch. The kerning using GPOS table just works fine. Is there a special reason to disable advanced features for OTF/CFF font. > Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2559) Kerning doesn't work for OTF/CFF font
[ https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080671#comment-15080671 ] Glenn Adams commented on FOP-2559: -- Only if complex script functions are disabled (as a group); otherwise, advanced features should be enabled. > Kerning doesn't work for OTF/CFF font > - > > Key: FOP-2559 > URL: https://issues.apache.org/jira/browse/FOP-2559 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: trunk >Reporter: chunlinyao >Priority: Minor > Attachments: patch.txt > > > According to the spec. "OpenType™ fonts containing CFF outlines are not > supported by the 'kern' table and must use the 'GPOS' OpenType Layout table." > But OFFontLoader hasn't pass the useAdvanced flag to OTFFile, so GPOS table > not read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-1777) Support for Font Kerning is Broken
[ https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thanasis Giannimaras updated FOP-1777: -- Attachment: kerningTrunk.pdf kerningTrunk.patch fop.xconf bchr.README bchr.pfb bchr.afm Support for Font Kerning is Broken -- Key: FOP-1777 URL: https://issues.apache.org/jira/browse/FOP-1777 Project: FOP Issue Type: Bug Components: font/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Vincent Hennebert Attachments: bchr.README, bchr.afm, bchr.pfb, fop.xconf, kerning.fo, kerning.pdf, kerningTrunk.patch, kerningTrunk.pdf, screenshot-openoffice-writer.png The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and returns the amount of kerning between the two corresponding glyphs. However, the implementation for Type 1 fonts interprets the two integers as character codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java). Those usually have nothing to do with Unicode code points. Moreover, trying to get kerning between two characters is inherently wrong: kerning applies to glyphs and not characters. A font may have several glyph variants for a same character, and kerning is likely to be different for each variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-1777) Support for Font Kerning is Broken
[ https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640553#comment-14640553 ] Thanasis Giannimaras commented on FOP-1777: --- Fix for handling kerning for unencoded characters. Patch based on work provided by Luis Bernado with few changes. For mitigating potential performance issues, kerning has been disabled by deault (default option was true). As i could not include Nimbus Sans L font in fop, due to its license, for junit testing i used Bitstream Charter Regular (http://www.math.utah.edu/~beebe/fonts/charter-1.0.zip) which come with a more open, less restrictive license. Support for Font Kerning is Broken -- Key: FOP-1777 URL: https://issues.apache.org/jira/browse/FOP-1777 Project: FOP Issue Type: Bug Components: font/unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Vincent Hennebert Attachments: bchr.README, bchr.afm, bchr.pfb, fop.xconf, kerning.fo, kerning.pdf, kerningTrunk.patch, kerningTrunk.pdf, screenshot-openoffice-writer.png The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and returns the amount of kerning between the two corresponding glyphs. However, the implementation for Type 1 fonts interprets the two integers as character codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java). Those usually have nothing to do with Unicode code points. Moreover, trying to get kerning between two characters is inherently wrong: kerning applies to glyphs and not characters. A font may have several glyph variants for a same character, and kerning is likely to be different for each variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams resolved FOP-2213. -- Resolution: Fixed Fix Version/s: trunk Fixed in http://svn.apache.org/viewvc?view=revisionrevision=r1623885. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: font/unqualified Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Assignee: Glenn Adams Fix For: trunk Attachments: fop.xconf, kerning-v2.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning.fo, kerning_1.0.pdf, kerning_1.1.pdf See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2371) Kerning is applied only to certain combinations
[ https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tošovský updated FOP-2371: -- Attachment: kern.pdf kern.fo Sample file. Kerning is applied only to certain combinations --- Key: FOP-2371 URL: https://issues.apache.org/jira/browse/FOP-2371 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1 Environment: Win 64-bit, JRE 1.7.0_40 Reporter: Jan Tošovský Priority: Minor Labels: kerning Attachments: kern.fo, kern.pdf When VLTAVA is typed with Palatino Linotype font, the kerning is applied to AV combination only. The rest, i.e. LT, TA and VA, is typeset without kerning. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2371) Kerning is applied only to certain combinations
[ https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994631#comment-13994631 ] Jan Tošovský commented on FOP-2371: --- I use default fop settings (with auto-detect/ tag) so complex script features should be enabled. Kern pairs are present in the font and it works fine in e.g. XEP or ConTeXt (luaTeX). This led me to the conclusion it is just FOP issue. The peculiarity of this font is the lack of glyph names. Various font libraries builds these missing names using a different logic which can be demonstrated on dotlessi glyph used for small caped variant of 'i' character. While some engines renders it corectly as dotless i, others incorrectly as dotted i. If missing glyph names is the issue, I am curious why the kerning is not disabled completely. Now it works at least for the AV pair. Kerning is applied only to certain combinations --- Key: FOP-2371 URL: https://issues.apache.org/jira/browse/FOP-2371 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1 Environment: Win 64-bit, JRE 1.7.0_40 Reporter: Jan Tošovský Priority: Minor Labels: kerning Attachments: kern.fo, kern.pdf When VLTAVA is typed with Palatino Linotype font, the kerning is applied to AV combination only. The rest, i.e. LT, TA and VA, is typeset without kerning. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2371) Kerning is applied only to certain combinations
[ https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994425#comment-13994425 ] Glenn Adams commented on FOP-2371: -- Firstly, you need to determine if complex script features are enabled in your testing. If they are, then you need to look at the font's GPOS tables associated with the 'kern' feature to determine if the font defines contextual kerning. If the are not enabled, then you need to look at the font's 'kern' table to determine if kerning entries for the pairs you are asking about are present. Basically, FOP uses what data is in the font to determine kerning. If no data is there, there is no kerning. You need to ascertain it is there and enabled before we can determine if there is a bug or not. If it is there and is enabled, but is not being used, then there may be a bug. Kerning is applied only to certain combinations --- Key: FOP-2371 URL: https://issues.apache.org/jira/browse/FOP-2371 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1 Environment: Win 64-bit, JRE 1.7.0_40 Reporter: Jan Tošovský Priority: Minor Labels: kerning Attachments: kern.fo, kern.pdf When VLTAVA is typed with Palatino Linotype font, the kerning is applied to AV combination only. The rest, i.e. LT, TA and VA, is typeset without kerning. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581630#comment-13581630
]
Vincent Hennebert commented on FOP-2213:
If a font provides a kern table but no 'kern' feature in the GPOS table, then
the kern table should be used as a fallback, as indicated at
http://www.microsoft.com/typography/otspec/recom.htm:
When a kern table and GPOS table are both present in a font, and an OFF layout
engine is requested to apply kerning to a run of text of a particular script
and language system: (a) If the number of kern feature lookups in the resolved
language system in the GPOS table is zero, then the kern table should be
applied, followed by any remaining GPOS features requested.
Also, the original font I used was DejaVu Sans [1], that does have a 'kern'
feature in its GPOS table. But because FOP finds no match for the script
('latn') and language ('dflt') that it computes from the FO file, it doesn't
apply it. Actually, it will apply it only if I specify one of the languages
listed under the 'latn' table, for example, 'ROM' for Romanian. Except that the
'language' XSL-FO property does not accept an OpenType language system tag, but
a language tag that conforms to ISO 639-1 (2-letter tag) or ISO 639-2 (3-letter
tag). And the ISO 639-2 tag for Romanian is 'ron' or 'rum', not 'ROM'. So it
seems that the code is lacking the lookup tables that will match an ISO 639
country tag to an OpenType language system tag. Also, IIUC a script table may
reference a default language system that should be used if no language is
specified, or if the particular language is not listed.
[1] http://dejavu-fonts.org/wiki/Main_Page
Kerning is no longer applied
Key: FOP-2213
URL: https://issues.apache.org/jira/browse/FOP-2213
Project: Fop
Issue Type: Bug
Components: fonts
Affects Versions: 1.1, trunk
Reporter: Vincent Hennebert
Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo,
kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo
See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph
as expected, while it's not the case with FOP 1.1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581665#comment-13581665 ] Glenn Adams commented on FOP-2213: -- Excellent sleuthing. I had missed that recommendation, the implementation of which should address this problem (in part). For the second part, regarding mapping of XSL-FO language and script value space into OT language and script tag space, I have been aware of this for a while, and had already opened FOP-2093 and FOP-2094 to address this problem. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams reassigned FOP-2213: Assignee: Glenn Adams Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Assignee: Glenn Adams Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FOP-2213) Kerning is no longer applied
Vincent Hennebert created FOP-2213: -- Summary: Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2213: --- Attachment: kerning_1.1.pdf kerning_1.0.pdf fop.xconf kerning.fo Sample FO file, fop.xconf (referring to the DejaVu LGC Serif font available in test/resources/fonts/ttf). Correct output produced by FOP 1.0. Incorrect output produced by FOP 1.1. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579610#comment-13579610 ] Luis Bernardo edited comment on FOP-2213 at 2/15/13 11:59 PM: -- In FOP 1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. was (Author: lmpmbernardo): In FOP-1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579610#comment-13579610 ] Luis Bernardo commented on FOP-2213: In FOP-1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2213: --- Attachment: kerning-v2_1.1-cs.pdf kerning-v2_1.1-nocs.pdf kerning-v2.fo The attached example (kerning-v2.fo) uses the Arial font (font not provided) side to side with DejaVu. Since with Arial the kerning seems to be the same with or without CS the issue may be with the lack of a GPOS table in the DejaVu font. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579685#comment-13579685
]
Glenn Adams commented on FOP-2213:
--
As Luis says, see also TextLayoutManager#processWordMapping, especially:
// 4. compute glyph position adjustments on (substituted) characters
int[][] gpa;
if ( font.performsPositioning() ) {
// handle GPOS adjustments
gpa = font.performPositioning ( mcs, script, language );
} else if ( font.hasKerning() ) {
// handle standard (non-GPOS) kerning adjustments
gpa = getKerningAdjustments ( mcs, font );
} else {
gpa = null;
}
font.performsPositioning() when CS is enabled and the font contains at least
one GPOS subtable in the GPOS table; if some GPOS subtable applies, then the CS
path assumes that the font designer will include a subtable mapped to the
'kern' feature [1]
[1] http://www.microsoft.com/typography/otspec/features_ko.htm#kern
it is up the font designer to program the GPOS feature table to contain the
desired subtables
i also notice the following warning under then non-GPOS (older) 'kern' table
(do not confuse this with the 'kern' feature of the GPOS table) [2]:
OpenType™ fonts containing CFF outlines are not supported by the 'kern' table
and must use the 'GPOS' OpenType Layout table.
[2] http://www.microsoft.com/typography/otspec/kern.htm
what I suspect is happening in the current case is that the font author
includes some GPOS table (but not one containing a subtable mapped to the
'kern' feature) and also includes a 'kern' table;
i wonder if there is a newer version of the font that fixes this
Kerning is no longer applied
Key: FOP-2213
URL: https://issues.apache.org/jira/browse/FOP-2213
Project: Fop
Issue Type: Bug
Components: fonts
Affects Versions: 1.1, trunk
Reporter: Vincent Hennebert
Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo,
kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo
See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph
as expected, while it's not the case with FOP 1.1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2178) incomplete kerning when complex script features are enabled
[ https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2178. -- the issue has been fixed. thanks. incomplete kerning when complex script features are enabled --- Key: FOP-2178 URL: https://issues.apache.org/jira/browse/FOP-2178 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Reporter: Glenn Adams Assignee: Glenn Adams Fix For: trunk Attachments: kerningissue.fo.xml, kerningissue.pdf alternate kerning pairs are missed when kerning with complex script features enabled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FOP-2178) incomplete kerning when complex script features are enabled
Glenn Adams created FOP-2178: Summary: incomplete kerning when complex script features are enabled Key: FOP-2178 URL: https://issues.apache.org/jira/browse/FOP-2178 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Reporter: Glenn Adams Assignee: Glenn Adams alternate kerning pairs are missed when kerning with complex script features enabled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2178) incomplete kerning when complex script features are enabled
[ https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams updated FOP-2178: - Attachment: kerningissue.pdf kerningissue.fo.xml incomplete kerning when complex script features are enabled --- Key: FOP-2178 URL: https://issues.apache.org/jira/browse/FOP-2178 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Reporter: Glenn Adams Assignee: Glenn Adams Attachments: kerningissue.fo.xml, kerningissue.pdf alternate kerning pairs are missed when kerning with complex script features enabled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2178) incomplete kerning when complex script features are enabled
[ https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540964#comment-13540964 ] Glenn Adams commented on FOP-2178: -- originally reported by Luis Bernardo in private message incomplete kerning when complex script features are enabled --- Key: FOP-2178 URL: https://issues.apache.org/jira/browse/FOP-2178 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Reporter: Glenn Adams Assignee: Glenn Adams Attachments: kerningissue.fo.xml, kerningissue.pdf alternate kerning pairs are missed when kerning with complex script features enabled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2178) incomplete kerning when complex script features are enabled
[ https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams resolved FOP-2178. -- Resolution: Fixed Fix Version/s: trunk http://svn.apache.org/viewvc?view=revisionrevision=1426805 incomplete kerning when complex script features are enabled --- Key: FOP-2178 URL: https://issues.apache.org/jira/browse/FOP-2178 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Reporter: Glenn Adams Assignee: Glenn Adams Fix For: trunk Attachments: kerningissue.fo.xml, kerningissue.pdf alternate kerning pairs are missed when kerning with complex script features enabled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #8 from Glenn Adams gl...@skynav.com 2012-04-07 01:44:44 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 40724] Kerning does not work for user-specified CID fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=40724 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Glenn Adams gl...@skynav.com 2012-04-01 06:56:09 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48003] [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Glenn Adams gl...@skynav.com 2012-04-01 07:10:08 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #7 from Jeremias Maerki jerem...@apache.org 2010-02-19 15:48:02 UTC --- Ah, I see, they added many more kerning pairs from version 1.05 to 1.06 of Nimbus Sans L. The code that builds the kerning map from the AFM file is AFMFile.createXKerningMapEncoded(). So, as mentioned before, the problem is that this method is only aware of the primary single-byte encoding. I can't deal with the supplemental encodings in which characters like Æ will be found. You can see how the character codes are derived from the multiple encodings in SingleByteFont.mapChar()/mapUnencodedChar(). Maybe it makes sense to just keep the kerning pairs with their glyph names (rather than building the map based on character codes) and store the whole map in SingleByteFont. But that may also be a bit slower. HTH -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] New: Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 Summary: Support for Font Kerning is Broken Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vhenneb...@gmail.com The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and returns the amount of kerning between the two corresponding glyphs. However, the implementation for Type 1 fonts interprets the two integers as character codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java). Those usually have nothing to do with Unicode code points. Moreover, trying to get kerning between two characters is inherently wrong: kerning applies to glyphs and not characters. A font may have several glyph variants for a same character, and kerning is likely to be different for each variant. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com 2010-02-18 14:34:29 UTC --- Created an attachment (id=25016) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25016) Sample FO file showing the issue This sample file uses the Nimbus Sans L font available on most Unix systems and downloadable here: http://sourceforge.net/projects/gs-fonts/ The AFM file gives the same kerning between 'Y' and all the accented variants of the 'A' letter. Yet kerning is applied only between 'Y' and non-accented 'A'. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #2 from Vincent Hennebert vhenneb...@gmail.com 2010-02-18 14:35:42 UTC --- Created an attachment (id=25017) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25017) PDF result; the right borders should be aligned -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #3 from Jeremias Maerki jerem...@apache.org 2010-02-18 15:15:25 UTC --- Currently, kerning only works for characters within the main single-byte encoding. The implementation uses character codes, not Unicode values, for kerning pairs. That feature didn't make the transition from a single single-byte encoding to multiple single-byte encodings. Type1Loader and especially AFMFile will probably need to be improved to support kerning for all available glyphs. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #4 from Vincent Hennebert vhenneb...@gmail.com 2010-02-18 15:41:09 UTC --- (In reply to comment #3) Currently, kerning only works for characters within the main single-byte encoding. No, kerning doesn't work at all. Like I said the layout engine expects Unicode code points while the font uses character codes. It's only a chance if they are the same. Basically, for Adobe Standard Encoding, only the characters (and not even all) from the Basic Latin range (U+–U+007F). Try “YA” vs “YÆ”, or “Fo” vs “Fø” (kerning should be the same). All in Nimbus Sans L's base encoding. The implementation uses character codes, not Unicode values, for kerning pairs. That feature didn't make the transition from a single single-byte encoding to multiple single-byte encodings. Type1Loader and especially AFMFile will probably need to be improved to support kerning for all available glyphs. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 --- Comment #5 from Jeremias Maerki jerem...@apache.org 2010-02-18 16:10:06 UTC --- Created an attachment (id=25018) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25018) Screenshot from OpenOffice Writer I've just tested with Nimbus Sans L (V 1.05) and kerning works just fine for those combinations for which there is data in the AFM, with PDF and PS. The AFM I have doesn't have kerning info for “YÆ” or “Fø”. Maybe you just expect characters like A and Æ to be equivalent, but I don't remember any mention in any of the Type1-related specs where it is listed which glyphs are interchangeable concerning kerning. Take AY and ÆY: this combination can definitely not be the same as the font shapes are quite different. Not even OpenOffice does this kind of kerning, not even with Arial or any other font I've checked. So IMO, it's a bit much to say it doesn't work at all. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48003] [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 --- Comment #2 from Alexander Kiel alexanderk...@gmx.net 2009-10-16 05:07:53 UTC --- Thanks for applying my patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48003] New: [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 Summary: [PATCH] Improved variable names around Kerning and KnuthElement Product: Fop Version: all Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: alexanderk...@gmx.net Created an attachment (id=24381) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24381) patch file Just some small things from me to start with something that can applied separately. - improved variable names around Kerning and KnuthElement - changed Font#getKerningValue(char, char) to return the value in pt instead of milliem The most critical change is that of Font#getKerningValue(char, char). Can someone check, that nobody else except TextLayoutManager uses it? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48003] [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 Adrian Cumiskey d...@cumiskey.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Adrian Cumiskey d...@cumiskey.com 2009-10-15 13:47:57 UTC --- Patch applied to trunk. Thanks for the improving the readability of what is a complex area of FOP. It should not be underestimated how valuable these kind of patches are to the health of the project. Its unselfish work, much appreciated and very good to see :). Adrian. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Incorrect kerning of Liberation fonts
Firstly install Microsoft Corefonts from http://corefonts.sf.net $ cd /opt/fop-0.95 $ java -cp build/fop.jar:lib/avalon-framework-4.2.0.jar:lib/commons-logging-1.0.4.jar:lib/commons-io-1.3.1.jar:lib/xmlgraphics-commons-1.3.1.jar org.apache.fop.fonts.apps.TTFReader /usr/share/fonts/msttcorefonts/arial.ttf conf/arial.xml $ java -cp build/fop.jar:lib/avalon-framework-4.2.0.jar:lib/commons-logging-1.0.4.jar:lib/commons-io-1.3.1.jar:lib/xmlgraphics-commons-1.3.1.jar org.apache.fop.fonts.apps.TTFReader /usr/share/fonts/liberation/LiberationSans-Regular.ttf conf/LiberationSans-Regular.xml $ cat /opt/fop-0.95/conf/fop.conf ?xml version=1.0? fop version=1.0 base./base source-resolution72/source-resolution target-resolution72/target-resolution default-page-settings height=297mm width=210mm/ renderers renderer mime=application/pdf filterList valueflate/value /filterList fonts font embed-url=file:///usr/share/fonts/liberation/LiberationSans-Regular.ttf font-triplet name=Liberation Sans style=normal weight=normal/ /font font embed-url=file:///usr/share/fonts/liberation/LiberationSans-Bold.ttf font-triplet name=Liberation Sans style=normal weight=bold/ /font font embed-url=file:///usr/share/fonts/liberation/LiberationSans-Italic.ttf font-triplet name=Liberation Sans style=italic weight=normal/ /font font embed-url=file:///usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf font-triplet name=Liberation Sans style=italic weight=bold/ /font font embed-url=file:///usr/share/fonts/msttcorefonts/arial.ttf font-triplet name=Arial style=normal weight=normal/ /font font embed-url=file:///usr/share/fonts/msttcorefonts/arialbd.ttf font-triplet name=Arial style=normal weight=bold/ /font font embed-url=file:///usr/share/fonts/msttcorefonts/ariali.ttf font-triplet name=Arial style=italic weight=normal/ /font font embed-url=file:///usr/share/fonts/msttcorefonts/arialbi.ttf font-triplet name=Arial style=italic weight=bold/ /font /fonts /renderer /fop $ cat sample.xml fonts arialTest AV fi/arial liberationTest AV fi/liberation /fonts $ cat sample.xsl ?xml version=1.0 encoding=utf-8? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; version=1.0 xsl:template match=/ fo:root font-weight=normal font-style=normal fo:layout-master-set fo:simple-page-master master-name=simple page-height=297mm page-width=210mm margin-top=0.1in margin-bottom=0.1in margin-left=0.75in margin-right=0.75in fo:region-body margin-bottom=0.5in margin-top=0.8in / fo:region-before extent=1.25in/ fo:region-after extent=0.5in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple format=1 fo:flow flow-name=xsl-region-body xsl:apply-templates/ fo:block id=last-page/ /fo:flow /fo:page-sequence /fo:root /xsl:template xsl:template match=arial fo:block font-family=Arial xsl:value-of select=./ /fo:block /xsl:template xsl:template match=liberation fo:block font-family=Liberation Sans xsl:value-of select=./ /fo:block /xsl:template /xsl:stylesheet $ /opt/fop-0.95/fop -c /opt/fop-0.95/conf/fop.conf -xml sample.xml -xsl sample.xsl -pdf sample.pdf evince sample.pdf I have submitted this with Redhat as well, https://bugzilla.redhat.com/show_bug.cgi?id=503430 as it could be the font. Though it works correctly in Abiword so decided to post the bug details here as well. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-04-09 02:20 --- Fixed, kerning works in the current trunk -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Kerning and hyphenation
On 13.01.2007 06:32:15 Manuel Mall wrote: While looking into the support for the Soft Hyphen the area of hyphenation combined with kerning is causing me trouble. Aside 1: our fonts page claims we don't support kerning but I believe we do. Yes, we do. Aside 2: Our tests are based on setting the base14kerning flag. I don't think this flag is documented anywhere on the fop site. Can it be set in the config file? Not yet, no, only through the FopFactory. I wrote a simple test under fop 0.93 and noticed that the ipd of text areas with the combination of kerning and hyphenation are not correctly calculated (at least I think so). With the Base 14 sans-serif font at 20pt we get: Word vanda alone on a line: ipd=53980 Word vandavanda alone on a line: ipd=107560 (53980+53980-400) Word vandavandavanda alone on a line: ipd=161140 (53980+53980+53980-400-400) If we now take the word vandavandavandavanda and get it hyphenated after the 3rd vanda the line containing vandavandavanda- reports an ipd of 168800 which is incorrect. I think it should be 161140 + 6660 (width of hyphen) = 167800. I think you mean it is 168600 (that's what I get) and it should be 167800, which is a difference of 800mpt. 800mpt looks much like two times 400mpt kerning which are not removed from the area objects's IPD for the break at a hyphenation point. However, I'd expect a difference of only 400mpt, not 800mpt. I did fix [1] the behaviour for that condition so the layout looks correct, but apparently I didn't adjust the IPD for the area object. [1] http://svn.apache.org/viewvc?rev=407774view=rev Before I investigate this more can someone else check this and see if they get similar results. I have attached the test case I have constructed. Manuel Jeremias Maerki
Kerning and hyphenation
While looking into the support for the Soft Hyphen the area of hyphenation combined with kerning is causing me trouble. Aside 1: our fonts page claims we don't support kerning but I believe we do. Aside 2: Our tests are based on setting the base14kerning flag. I don't think this flag is documented anywhere on the fop site. Can it be set in the config file? I wrote a simple test under fop 0.93 and noticed that the ipd of text areas with the combination of kerning and hyphenation are not correctly calculated (at least I think so). With the Base 14 sans-serif font at 20pt we get: Word vanda alone on a line: ipd=53980 Word vandavanda alone on a line: ipd=107560 (53980+53980-400) Word vandavandavanda alone on a line: ipd=161140 (53980+53980+53980-400-400) If we now take the word vandavandavandavanda and get it hyphenated after the 3rd vanda the line containing vandavandavanda- reports an ipd of 168800 which is incorrect. I think it should be 161140 + 6660 (width of hyphen) = 167800. Before I investigate this more can someone else check this and see if they get similar results. I have attached the test case I have constructed. Manuel ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id:$ -- testcase info p This test checks some kerning plus hyphenation rules. /p /info cfg base14kerningtrue/base14kerning /cfg fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; language=en fo:layout-master-set fo:simple-page-master master-name=normal page-width=2.5in page-height=10in margin=5pt fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body font-size=10pt fo:block background-color=yellow margin=0pt 0pt 3pt 0pt font-size=20pt vanda /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt font-size=20pt vandavanda /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt font-size=20pt vandavandavanda /fo:block fo:block background-color=yellow margin=0pt 0pt 3pt 0pt font-size=20pt hyphenate=true vandavandavandavandavandavandavanda /fo:block /fo:flow /fo:page-sequence /fo:root /fo checks eval expected=53980 xpath=//flow/block[1]/lineArea[1]/text/@ipd/ eval expected=107560 xpath=//flow/block[2]/lineArea[1]/text/@ipd/ eval expected=161140 xpath=//flow/block[3]/lineArea[1]/text/@ipd/ eval expected=3 xpath=count(//flow/block[4]/lineArea)/ eval expected=167600 xpath=//flow/block[4]/lineArea[1]/text/@ipd/ eval expected=167600 xpath=//flow/block[4]/lineArea[2]/text/@ipd/ eval expected=53980 xpath=//flow/block[4]/lineArea[3]/text/@ipd/ /checks /testcase
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 --- Additional Comments From [EMAIL PROTECTED] 2006-10-13 00:57 --- I now have an IOException saying: Unicode index not found for glyph 1778 for DejaVuSerif.ttf when running TTFReader. DejaVu fonts, see: http://dejavu.sourceforge.net/wiki/index.php/Main_Page -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 --- Additional Comments From [EMAIL PROTECTED] 2006-10-13 01:02 --- Forget it. I just saw you fixed it already. :-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Kerning for CID fonts, use unicode indexes in kerning?
Thanks for the changes. I understand the necessity now. I've done some tests and after your latest fix, everything seems to be working fine. Let's hope our users won't be too mad at us for changing the format. I have some time in trains this and next week. Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Actually, finishing my DataMatrix implementation is more important but if this were only a small step we should take it. *g* Otherwise, we'll defer that to the FOray stuff. On 12.10.2006 12:17:36 Bertrand Delacretaz wrote: On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...I wonder how much should be invested in versioning of those files Ok, so I have added a simplistic versioning system for these metrics XML files, an exception is thrown when attempting to read incompatible metrics files (http://issues.apache.org/bugzilla/show_bug.cgi?id=40739). Mapping the glyph indexes to unicode indexes when reading the XML metrics file seemed more complicated than when creating the file, so I have implemented the change in the TTFFile class, which now writes the kerning info based on unicode code points. A note in the FOray release notes (http://foray.sourceforge.net/app/using/release.html) says Kerning has been fixed for subsetted fonts, makes me wonder if kerning did work before for custom CID fonts. Anyway it should work now. -Bertrand Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/13/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Shouldn't be hard at all, but right now I have to create a test document to demonstrate the new font features for my own project, so I won't be able to do it ATM. I hear you work well on trains ;-) -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
Right, it isn't hard. Almost works after a train ride to Zurich and back. :-) On 13.10.2006 11:33:09 Bertrand Delacretaz wrote: On 10/13/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Shouldn't be hard at all, but right now I have to create a test document to demonstrate the new font features for my own project, so I won't be able to do it ATM. I hear you work well on trains ;-) -Bertrand Jeremias Maerki
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 --- Additional Comments From [EMAIL PROTECTED] 2006-10-12 01:20 --- As discussed on the mailing list, this change makes old metrics files incompatible. If implemented, it would be good to add a version number to the metrics file, to detect the incompatibility in case metrics files generated with older FOP versions are used. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 --- Additional Comments From [EMAIL PROTECTED] 2006-10-12 02:50 --- See bug #40739 for the metrics-version attribute used to detect older versions of the metrics file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...I wonder how much should be invested in versioning of those files Ok, so I have added a simplistic versioning system for these metrics XML files, an exception is thrown when attempting to read incompatible metrics files (http://issues.apache.org/bugzilla/show_bug.cgi?id=40739). Mapping the glyph indexes to unicode indexes when reading the XML metrics file seemed more complicated than when creating the file, so I have implemented the change in the TTFFile class, which now writes the kerning info based on unicode code points. A note in the FOray release notes (http://foray.sourceforge.net/app/using/release.html) says Kerning has been fixed for subsetted fonts, makes me wonder if kerning did work before for custom CID fonts. Anyway it should work now. -Bertrand
DO NOT REPLY [Bug 40724] New: - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 Summary: Kerning does not work for user-specified CID fonts Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Testing this in revision 462741, I have created a font file with only two glyphs A and V, and set kerning between them. The XML metrics file (excerpt below) shows that the indexes in kerning are glyph indexes, but AFAICS the layout code expects unicode indexes. I'll change that in the TTFFile font decoder class, to have unicode indexes in the kerning section. multibyte-extras cid-typeCIDFontType2/cid-type default-width0/default-width bfranges !-- mapping of glyph indexes to unicode -- bf gi=0 ue=0 us=0/ bf gi=3 ue=65 us=65/ bf gi=4 ue=86 us=86/ bf gi=0 ue=65535 us=65535/ /bfranges cid-widths start-index=0 wx w=684/ wx w=1000/ wx w=1000/ wx w=684/ wx w=684/ /cid-widths /multibyte-extras !-- glyph index 3 is A in my font, 4 is V -- kerning kpx1=3 pair kern=-279 kpx2=4/ /kerning -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||40464 nThis|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Kerning for CID fonts, use unicode indexes in kerning?
Hi FOPpers, See http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 , kerning doesn't work for me with user-specified CID fonts at the moment. IIUC the code, org.apache.fop.layoutmgr.inline.TextLayoutManager expects unicode indexes for kerning pairs, but currently the TTFReader writes glyph indexes in the XML file, like: kerning kpx1=3 pair kern=-279 kpx2=4/ /kerning Where 3 and 4 are glyph indexes (I'm playing with a test font with very few glyphs, it's easier). I've tried changing the TTFFile code to use unicode indexes for kpx1 and kpx2 and it seems to work - anything against making this change? -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
I wonder where this got broken. I believe this used to work. If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems. On 11.10.2006 13:15:54 Bertrand Delacretaz wrote: Hi FOPpers, See http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 , kerning doesn't work for me with user-specified CID fonts at the moment. IIUC the code, org.apache.fop.layoutmgr.inline.TextLayoutManager expects unicode indexes for kerning pairs, but currently the TTFReader writes glyph indexes in the XML file, like: kerning kpx1=3 pair kern=-279 kpx2=4/ /kerning Where 3 and 4 are glyph indexes (I'm playing with a test font with very few glyphs, it's easier). I've tried changing the TTFFile code to use unicode indexes for kpx1 and kpx2 and it seems to work - anything against making this change? -Bertrand Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems... How about adding a version number to the XML metrics files? This would make them more future-proof, and in this case we could detect old files and bark. -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
Sure. However, as we discussed in Amsterdam, the goal should be that we don't rely on those XML files much longer, so I wonder how much should be invested in versioning of those files. But if you don't see a way around it... I still don't understand why exactly this change is necessary. On 11.10.2006 18:59:07 Bertrand Delacretaz wrote: On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems... How about adding a version number to the XML metrics files? This would make them more future-proof, and in this case we could detect old files and bark. -Bertrand Jeremias Maerki
Letter space [was Re: Kerning]
[Luca] ... A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! In [7.16.2 letter-spacing], I read it as if each alphabetic letter has 1/2 a letter space preceding and 1/2 a letter space following the character. These space-before and space-after trait values are then resolved with whatever other spaces that they are up against according to space resolution rules. The same goes for wordspaces which is split into 2 half word spaces. A Word then becomes: hls 'A' hls hws hws hls 'W' hls hls 'o' hls hls 'r' hls hls 'd' hls where 'hls' is half a letter-space and 'hws' is half a word-space. How the hls hls and 'hls hws' sequences are resolved depends the .precedence and .conditionality values. OTOH, it is user agent dependant how letter space is resolved with word spaces, so I think your implementation is complient, it is just not what I think the spec suggest. regards, finn
Re: Kerning
Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca
RE: Kerning
Hi Luca. Its been over 15 years since I did any kerning, but, from what I remember, kerning isn't just left or right, its also up and down (and possibly other transforms/alterations for all I know). Consider the kerned symbols in the LATeX logo. The A is raised and snuggled between the L and the T. I know that this is a special case, however, its worth verifying that the only spacing differences for all kerns are left/right. I seem to remember that some characters (small i or j come to mind) lose their dots in certain circumstances as well - that may not be kerning, though - I don't remember, its been 15 years :-) All of this would be from the LATeX manual and related documentation (MetaFont?), of which I don't have handy. Thanks. Shannon Mann -Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 8:42 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Kerning Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Kerning
Started a new thread on the Kerning topic here as the old subject line was inappropriate. On Tue, 6 Dec 2005 12:15 am, Luca Furini wrote: Manuel Mall wrote: I wonder if the same argument does apply to kerning as well? The moment you change font-size, text-decoration, background-color, alignment and the like, which is what fo:inline is mainly for, you create a barrier with respect kerning. Or to put it differently, I believe kerning applies only to like characters, same as glyph merging. Not sure here: if we want to use kerning between, for example, VA I think it would be even more desirable to use it if the V has a bigger font size, or the A a smaller one; it could maybe need some heuristic to handle a kerning between character with different sizes, but I think it would be a desirable feature. There seem to be different kerning algorithms around. The simplistic approach seems to be to use the kerning information stored in the font. That information can only be applied to characters with the same font size. And yes it does suffer from the problem you mentioned above. Typesetting programs may provide additional kerning algorithms (apart from allow the user to manually adjusting kerning). For example Adobe InDesign has something like optical kerning where the kerning information is calculated based on the shape of adjacent characters. I would think something like that would be outside the scope of FOP. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. Nonetheless, I agree that the think may become strange with different backgrounds or vertical alignments ... maybe we should define which properties break a kerning pair ... IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo b) Limit itself to the kerning information in the font c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Regards Luca Cheers Manuel
