[jira] [Resolved] (FOP-2559) [PATCH] Kerning doesn't work for OTF/CFF font

[simon steiner (JIRA)]

 [ 
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

[chunlinyao (JIRA)]

 [ 
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

[simon steiner (JIRA)]

 [ 
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] [Commented] (FOP-2559) Kerning doesn't work for OTF/CFF font

[chunlinyao (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080677#comment-15080677
 ] 

chunlinyao commented on FOP-2559:
-

Yes, The advanced features is enabled when use complex script. But OFFontLoader 
hasn't pass this flag to OTFFile. So useAdvanced  in OTFFile instance  is 
always false.  handleCharacterSpacing method in OpenFont will do nothing.

> 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

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2559) Kerning doesn't work for OTF/CFF font

[chunlinyao (JIRA)]

 [ 
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] [Created] (FOP-2559) Kerning doesn't work for OTF/CFF font

[chunlinyao (JIRA)]

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] [Commented] (FOP-1777) Support for Font Kerning is Broken

[Thanasis Giannimaras (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FOP-1777) Support for Font Kerning is Broken

[Thanasis Giannimaras (JIRA)]

 [ 
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] [Resolved] (FOP-2213) Kerning is no longer applied

[Glenn Adams (JIRA)]

 [ 
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=revision&revision=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

[JIRA]

 [ 
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

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994670#comment-13994670
 ] 

Glenn Adams commented on FOP-2371:
--

Given the additional input from the reporter, I would also speculate this is a 
duplicate of FOP-2213. So let's proceed under that assumption until it is shown 
to be otherwise.

> 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] [Resolved] (FOP-2371) Kerning is applied only to certain combinations

[Luis Bernardo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luis Bernardo resolved FOP-2371.


Resolution: Duplicate

I think this is the same issue as FOP-2213. The example provided works with 1.0 
and with 1.1 if -nocs is used.

> 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] [Created] (FOP-2371) Kerning is applied only to certain combinations

[JIRA]

Jan Tošovský created FOP-2371:
-

 Summary: 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


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

[JIRA]

[ 
https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994631#comment-13994631
 ] 

Jan Tošovský commented on FOP-2371:
---

I use default fop settings (with  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

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Glenn Adams (JIRA)]

 [ 
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] [Commented] (FOP-2213) Kerning is no longer applied

[Vincent Hennebert (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FOP-2213) Kerning is no longer applied

[Luis Bernardo (JIRA)]

 [ 
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

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (FOP-2213) Kerning is no longer applied

[Luis Bernardo (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FOP-2213) Kerning is no longer applied

[Vincent Hennebert (JIRA)]

 [ 
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] [Created] (FOP-2213) Kerning is no longer applied

[Vincent Hennebert (JIRA)]

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] [Closed] (FOP-2178) incomplete kerning when complex script features are enabled

[Luis Bernardo (JIRA)]

 [ 
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] [Resolved] (FOP-2178) incomplete kerning when complex script features are enabled

[Glenn Adams (JIRA)]

 [ 
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=revision&revision=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

[jira] [Commented] (FOP-2178) incomplete kerning when complex script features are enabled

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FOP-2178) incomplete kerning when complex script features are enabled

[Glenn Adams (JIRA)]

 [ 
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] [Created] (FOP-2178) incomplete kerning when complex script features are enabled

[Glenn Adams (JIRA)]

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

DO NOT REPLY [Bug 48766] Support for Font Kerning is Broken

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

Glenn Adams  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 48766] Support for Font Kerning is Broken

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #8 from Glenn Adams  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 48003] [PATCH] Improved variable names around Kerning and KnuthElement

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48003

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Glenn Adams  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.

DO NOT REPLY [Bug 40724] Kerning does not work for user-specified CID fonts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=40724

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Glenn Adams  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.

Re: base 14 font kerning

[Glenn Adams]

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

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

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

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

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

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

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

G.

On Wed, Sep 8, 2010 at 9:52 PM, Vincent Hennebert wrote:

> Hi,
>
> I’m just remembering this bug, that may affect you:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48766
>
> Vincent
>
>
> On 06/09/10 06:58, Glenn Adams wrote:
> > Is there a reason that kerning of the base 14 fonts is disabled by
> default?
> >
> > Furthermore, except by programmatic means, there does not seem to be a
> way
> > to enable it except by using FontManager.setBase14KerningEnabled() or the
> > deprecated method FopFactory.setBase14KerningEnabled(). This technique is
> > used to enable it during testing in one test case:
> > layoutengine/standard-testcases/kerning_1_on.xml, by means of special
> code
> > in org.apache.fop.layoutengine.TestEnvironment.
> >
> > However, there appears no way for a user to enable it via non-programmitc
> > means. To support this (which I need in testing the new generalized
> position
> > adjustments for text drawing), I'm adding a base14-kerning element to be
> > placed in the top-level fop element in the FOP configuration file, e.g.,
> >
> > 
> >   ...
> >   true
> >   ...
> > 
> >
> > 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

[Vincent Hennebert]

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.,
> 
> 
>   ...
>   true
>   ...
> 
> 
> 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

[Vincent Hennebert]

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
>> 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=revision&revision=389086
>> <http://svn.apache.org/viewvc?view=revision&revision=389086>
>>
>> You're right: this setting doesn't seem to be tied into the
>> FontManagerConfigurator. It would be great if you added that.
>>
>> That said, I'm not sure if enabling that would be so bad. I guess I'm
>> not opposed to it.
>>
>> On 06.09.2010 07:58:41 Glenn Adams wrote:
>>  > Is there a reason that kerning of the base 14 fonts is disabled
>> by default?
>>  >
>>  > Furthermore, except by programmatic means, there does not seem to
>> be a way
>>  > to enable it except by using
>> FontManager.setBase14KerningEnabled() or the
>>  > deprecated method FopFactory.setBase14KerningEnabled(). This
>> technique is
>>  > used to enable it during testing in one test case:
>>  > layoutengine/standard-testcases/kerning_1_on.xml, by means of
>> special code
>>  > in org.apache.fop.layoutengine.TestEnvironment.
>>  >
>>  > However, there appears no way for a user to enable it via
>> non-programmitc
>>  > means. To support this (which I need in testing the new
>> generalized position
>>  > adjustments for text drawing), I'm adding a base14-kerning
>> element to be
>>  > placed in the top-level fop element in the FOP configuration
>> file, e.g.,
>>  >
>>  > 
>>  >   ...
>>  >   true
>>  >   ...
>>  > 
>>  >
>>  > 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

[Glenn Adams]

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
wrote:

> Glenn Adams wrote:
>
> Hi Glenn/Jeremias,
>
>
>  I've already implemented in my complex scripts work, so it will make it
>> into trunk in due time. However, I think I'll leave the default setting as
>> it is for the time being. Users can explicitly enable it via their config.
>> We can take up the issue of whether to change the default at a future time.
>>
>
> I do not like the idea of changing the default value of Kerning from off to
> on. The reason being that users who decide to upgrade their FOP version will
> suddenly find the appearance of their documents changing. Better to let
> users who are unsatisfied with the default inter character spacing to go and
> enable kerning than force users to regression test every document to make
> sure the changes to appearance is acceptable.
>
> Thanks,
>
> Chris
>
>
>> G.
>>
>>
>> On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki 
>> > 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=revision&revision=389086
>><http://svn.apache.org/viewvc?view=revision&revision=389086>
>>
>>You're right: this setting doesn't seem to be tied into the
>>FontManagerConfigurator. It would be great if you added that.
>>
>>That said, I'm not sure if enabling that would be so bad. I guess I'm
>>not opposed to it.
>>
>>On 06.09.2010 07:58:41 Glenn Adams wrote:
>> > Is there a reason that kerning of the base 14 fonts is disabled
>>by default?
>> >
>> > Furthermore, except by programmatic means, there does not seem to
>>be a way
>> > to enable it except by using
>>FontManager.setBase14KerningEnabled() or the
>> > deprecated method FopFactory.setBase14KerningEnabled(). This
>>technique is
>> > used to enable it during testing in one test case:
>> > layoutengine/standard-testcases/kerning_1_on.xml, by means of
>>special code
>> > in org.apache.fop.layoutengine.TestEnvironment.
>> >
>> > However, there appears no way for a user to enable it via
>>non-programmitc
>> > means. To support this (which I need in testing the new
>>generalized position
>> > adjustments for text drawing), I'm adding a base14-kerning
>>element to be
>> > placed in the top-level fop element in the FOP configuration
>>file, e.g.,
>> >
>>     > 
>> >   ...
>> >   true
>> >   ...
>> > 
>> >
>> > 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

[Chris Bowditch]

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 <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=revision&revision=389086
<http://svn.apache.org/viewvc?view=revision&revision=389086>

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

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

On 06.09.2010 07:58:41 Glenn Adams wrote:
 > Is there a reason that kerning of the base 14 fonts is disabled
by default?
 >
 > Furthermore, except by programmatic means, there does not seem to
be a way
 > to enable it except by using
FontManager.setBase14KerningEnabled() or the
 > deprecated method FopFactory.setBase14KerningEnabled(). This
technique is
 > used to enable it during testing in one test case:
 > layoutengine/standard-testcases/kerning_1_on.xml, by means of
special code
 > in org.apache.fop.layoutengine.TestEnvironment.
 >
 > However, there appears no way for a user to enable it via
non-programmitc
 > means. To support this (which I need in testing the new
generalized position
 > adjustments for text drawing), I'm adding a base14-kerning
element to be
 > placed in the top-level fop element in the FOP configuration
file, e.g.,
 >
 > 
 >   ...
 >   true
 >   ...
 > 
 >
 > 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

[Glenn Adams]

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 wrote:

> I think that is for historical reasons. When this was implemented (I
> think it was me) I guess we didn't want to change the layout behaviour
> for existing users. For a long time, kerning for base 14 fonts was not
> supported.
>
> http://svn.apache.org/viewvc?view=revision&revision=389086
>
> You're right: this setting doesn't seem to be tied into the
> FontManagerConfigurator. It would be great if you added that.
>
> That said, I'm not sure if enabling that would be so bad. I guess I'm
> not opposed to it.
>
> On 06.09.2010 07:58:41 Glenn Adams wrote:
> > Is there a reason that kerning of the base 14 fonts is disabled by
> default?
> >
> > Furthermore, except by programmatic means, there does not seem to be a
> way
> > to enable it except by using FontManager.setBase14KerningEnabled() or the
> > deprecated method FopFactory.setBase14KerningEnabled(). This technique is
> > used to enable it during testing in one test case:
> > layoutengine/standard-testcases/kerning_1_on.xml, by means of special
> code
> > in org.apache.fop.layoutengine.TestEnvironment.
> >
> > However, there appears no way for a user to enable it via non-programmitc
> > means. To support this (which I need in testing the new generalized
> position
> > adjustments for text drawing), I'm adding a base14-kerning element to be
> > placed in the top-level fop element in the FOP configuration file, e.g.,
> >
> > 
> >   ...
> >   true
> >   ...
> > 
> >
> > 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

[Jeremias Maerki]

I think that is for historical reasons. When this was implemented (I
think it was me) I guess we didn't want to change the layout behaviour
for existing users. For a long time, kerning for base 14 fonts was not
supported.

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

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

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

On 06.09.2010 07:58:41 Glenn Adams wrote:
> Is there a reason that kerning of the base 14 fonts is disabled by default?
> 
> Furthermore, except by programmatic means, there does not seem to be a way
> to enable it except by using FontManager.setBase14KerningEnabled() or the
> deprecated method FopFactory.setBase14KerningEnabled(). This technique is
> used to enable it during testing in one test case:
> layoutengine/standard-testcases/kerning_1_on.xml, by means of special code
> in org.apache.fop.layoutengine.TestEnvironment.
> 
> However, there appears no way for a user to enable it via non-programmitc
> means. To support this (which I need in testing the new generalized position
> adjustments for text drawing), I'm adding a base14-kerning element to be
> placed in the top-level fop element in the FOP configuration file, e.g.,
> 
> 
>   ...
>   true
>   ...
> 
> 
> 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

[Glenn Adams]

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.,


  ...
  true
  ...


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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #7 from Jeremias Maerki  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] Support for Font Kerning is Broken

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #6 from Vincent Hennebert  2010-02-19 
15:23:57 UTC ---
(In reply to comment #5)
> Created an attachment (id=25018)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25018) [details]
> 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ø”.

Then please download the font from the link above.


> 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".

So where is the code that makes the conversion between Unicode code points as
provided by the layout engine and the character codes as stored in the font's
kerning map?

-- 
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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #5 from Jeremias Maerki  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 48766] Support for Font Kerning is Broken

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #4 from Vincent Hennebert  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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #3 from Jeremias Maerki  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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #2 from Vincent Hennebert  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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48766

--- Comment #1 from Vincent Hennebert  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] New: Support for Font Kerning is Broken

[bugzilla]

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 48003] [PATCH] Improved variable names around Kerning and KnuthElement

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48003

--- Comment #2 from Alexander Kiel  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] [PATCH] Improved variable names around Kerning and KnuthElement

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48003

Adrian Cumiskey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Adrian Cumiskey  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.

DO NOT REPLY [Bug 48003] New: [PATCH] Improved variable names around Kerning and KnuthElement

[bugzilla]

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.

Incorrect kerning of Liberation fonts

[grom nospam]

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


  .
  72
  72
  
  

  
flate
   
  

  


  


  


  


  


  


  


  

  



$ cat sample.xml

Test AV fi
Test AV fi


$ cat sample.xsl

http://www.w3.org/1999/XSL/Transform";
xmlns:fo="http://www.w3.org/1999/XSL/Format";
version="1.0">

































$ /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

[bugzilla]

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

[Jeremias Maerki]

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=407774&view=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

[Manuel Mall]

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







  

  This test checks some kerning plus hyphenation rules.

  
  
true
  
  
http://www.w3.org/1999/XSL/Format"; xmlns:svg="http://www.w3.org/2000/svg"; language="en">
  

  

  
  

  
vanda
  
  
vandavanda
  
  
vandavandavanda
  
  
vandavandavandavandavandavandavanda
  

  

  
  
  
  
  
  
  
  
  
  
  
  

Re: Kerning for CID fonts, use unicode indexes in ?

[Jeremias Maerki]

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

Re: Kerning for CID fonts, use unicode indexes in ?

[Bertrand Delacretaz]

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 ?

[Jeremias Maerki]

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
>  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

DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

Re: Kerning for CID fonts, use unicode indexes in ?

[Bertrand Delacretaz]

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
 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] - Kerning does not work for user-specified CID fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

Re: Kerning for CID fonts, use unicode indexes in ?

[Bertrand Delacretaz]

On 10/11/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote:

...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...


Agreed - versioning is easy though, if I need to make the suggested
changes I'll probably implement it just to be safe, before going to
direct reading of the font files.


... I still don't understand why exactly this change is
necessary


The layout code definitely expects unicode indexes for the kerning
values, so something's wrong currently. I'll see how mapping on the
other side (i.e. when reading the metrics xml file) looks, as it would
avoid having to modify the metrics xml files.

-Bertrand

Re: Kerning for CID fonts, use unicode indexes in ?

[Jeremias Maerki]

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

Re: Kerning for CID fonts, use unicode indexes in ?

[Bertrand Delacretaz]

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 ?

[Jeremias Maerki]

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:
> 
>   
> 
>   
> 
> 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

Kerning for CID fonts, use unicode indexes in ?

[Bertrand Delacretaz]

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:

 
   
 

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

DO NOT REPLY [Bug 40724] - Kerning does not work for user-specified CID fonts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.

DO NOT REPLY [Bug 40724] New: - Kerning does not work for user-specified CID fonts

[bugzilla]

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  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 
section.

   
CIDFontType2
0




















-- 
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.

Letter space [was Re: Kerning]

[Finn Bock]

[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

[Vincent Hennebert]

You seem to be right. I've just looked at the AFM specification and
there is a keyword for defining a kerning pair with a kerning vector
i.e., the horizontal and vertical amounts by which to move the second
character relative to the first one. I guess this type of kerning is
very rare (if existent) for western fonts, but may exist for others.

The AFM spec doesn't specify other kerning informations but the new
OpenType format may do, I don't know.

Regarding the LaTeX logo, this is just a series of TeX commands with
manually-adjusted kerning (which works only for the original Knuth
Computer Modern font); one can perfectly mimic that using standard FO
constructs like letter-spacing and alignment-adjust.

As far as I know, the dotless i and j characters also are special
characters that may be obtained with special commands (\i and \j). That
said, you may be refering to the more general font ligatures mechanism
(like the well-known fi, fl, ffi...): two or more characters are laid
out using a single glyph. I know that the OpenType spec defines tables
of ligatures. There is also perhaps a special Unicode property for
ligature characters (fi, fl and others appear at range FB00-FB06 in the
Unicode standard; there is also a bunch of special hebrew and arabic
characters that seem to be equivalent to ligatures).

Anyway, there are things to do in this area. I'm planning to have a look
at this in some (far?) future. I think there will be 2 levels, font and
layout.

Vincent


Shannon Mann a écrit :

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 attachme

RE: Kerning

[Shannon Mann]

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.

Re: Kerning

[Luca Furini]

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

Kerning

[Manuel Mall]

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