Kerncheck error

[Bahman Eslami]

I used kerncheck script to inspect overlaps on my font and it raised
an error, then I used it on a Adobe font, same thing happened but with
a different error. I used terminal and format of the fonts were .otf,
the fonts have arabic glyphs and kerning is RightToLeft, but I Don't
think that's the issue here because on some Latin fonts it didn't work
either. my platform is Mac OSX 10.6.8 and python version is 2.5. is
there something that I'm doing wrong?
thanks in advance,
Bahman

command:
kernCheck -log /Users/Bahman/Documents/AdobeArabic-Bold.otf /Users/
Bahman/Documents/AdobeArabic-Bold.otf
result:
Loading Adobe Glyph Dict...
Collecting font kern data...
spot [WARNING]: bad file [/Users/Bahman/Documents/AdobeArabic-
Bold.otf] (ignored)
Error: did not find any kern feature text in the output of the command
'spot -t GPOS=7 "/Users/Bahman/Documents/AdobeArabic-Bold.otf"'.
Traceback (most recent call last):
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 2009, in <module>
run()
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 1988, in run
lookupIndexDict, lookupSequenceDict, fontFlatKernTable =
collectKernData(fontPath)
TypeError: 'NoneType' object is not iterable

[Read Roberts]

The problem is that you are directing log output to the same file path
that you supply as the source font file. I would expect that by the time
the script gets around to reading the font file, it has already written
some log text to the file, so it is no longer a font file. Notice the
error report "spot [WARNING]: bad file
[/Users/Bahman/Documents/AdobeArabic-Bold.otf]", which says that the font
file doesn't look like a font to the 'spot' program.

- Read

>--
>You received this message because you are subscribed to the Google Groups
>"UAFDKOML" group.
>To post to this group, send email to uafd...@googlegroups.com.
>To unsubscribe from this group, send email to
>uafdkoml+u...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/uafdkoml?hl=en.
>

[Bahman Eslami]

Hi Read,
thanks for the answer, my mistake. it works on a latin font but on
AdobeArabic-Bold.otf it comes with this error:
"seeing a seond marked glyph run". I assume it meant "seeing a second
marked glyph run", but what does it mean? is there any file that
explains these errors? because error has been written in the python
file, but there is no description in there.
regards,
Bahman
command:
kernCheck -log /Users/Bahman/Documents/AdobeArabic-Bold.log /Users/

Bahman/Documents/AdobeArabic-Bold.otf
result:
Loading Adobe Glyph Dict...
Collecting font kern data...

Traceback (most recent call last):
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 2009, in <module>
run()
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 1988, in run
lookupIndexDict, lookupSequenceDict, fontFlatKernTable =
collectKernData(fontPath)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/

kernCheck.py", line 530, in collectKernData
subtableList, fontFlatKernTable = parseKernLookup(featureText,
fontFlatKernTable, lookup)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 373, in parseKernLookup
backTrack, lookAhead, leftSide, rightSide, valueRecord =
parseContextPos(line)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 267, in parseContextPos
raise ValueError("Error: seeing a seond marked glyph run.")
ValueError: Error: seeing a seond marked glyph run.

On Apr 5, 7:08 pm, Read Roberts <rrobe...@adobe.com> wrote:
> The problem is that you are directing log output to the same file path
> that you supply as the source font file. I would expect that by the time
> the script gets around to reading the font file, it has already written
> some log text to the file, so it is no longer a font file. Notice the
> error report "spot [WARNING]: bad file
> [/Users/Bahman/Documents/AdobeArabic-Bold.otf]", which says that the font
> file doesn't look like a font to the 'spot' program.
>
> - Read
>

[Read Roberts]

Hi Bahman;

The complaint means that it is seeing something that it doesn't support; a
contextual rule with an input sequence ( a marked glyph or class), a look
ahead sequence, followed by a second input sequence. The FDK can't build
this kind of rule,, so maybe there is an error in parsing the line.

AT line 265, please replace:
if lookAhead:

raise ValueError("Error: seeing a seond marked glyph run.")

With

if lookAhead:
print line
raise ValueError("Error: seeing a second marked glyph run.")

And then e-mail me the output line that causes the error.

- Read

[Bahman Eslami]

Read,

result:
Loading Adobe Glyph Dict...
Collecting font kern data...

pos [ uni0622 uniFE82 uni0671 uniFB51 uni0672 uni0672.fina uniFEF5
uniFEF6 uniFEF7 uniFEF8 uni06440671 uni06440671.fina uni06440672
uni06440672.fina uni06B50622 uni06B50622.fina uni06B50623
uni06B50623.fina uni06B50671 uni06B50671.fina uni06B50672
uni06B50672.fina uni06B60622 uni06B60622.fina uni06B60623
uni06B60623.fina uni06B60671 uni06B60671.fina uni06B60672
uni06B60672.fina uni06B70622 uni06B70622.fina uni06B70623
uni06B70623.fina uni06B70671 uni06B70671.fina uni06B70672
uni06B70672.fina uni06B80622 uni06B80622.fina uni06B80623
uni06B80623.fina uni06B80671 uni06B80671.fina uni06B80672
uni06B80672.fina uni076A0622 uni076A0622.fina uni076A0623
uni076A0623.fina uni076A0671 uni076A0671.fina uni076A0672
uni076A0672.fina uniFB50 uniFE81]' lookup 124 [ uniFE8B uniFE91
uniFE97 uniFE9B uniFEE7 uniFBE8 uniFEF3 uniFB68 uniFB60 uniFB54
uni067C.init uni067D.init uniFB58 uniFB64 uniFB5C uni0750.init
uni0752.init uni0755.init uniFBA2 uni06BC.init uni06BD.init uniFBA8
uniFBFE uniFBE6 uni06D1.init]' [ uni064B uni064C uni064C.jawi uni064E
uni064F uni0651 uni0652 uni0653 uni0654 uni0670 uni0657 uni0658
uni0615 uni0659 uni065A uni065B uni065D uni065E uniFC5E uniFC5E.jawi
uniFC5F uni064D0651 uniFC60 uniFC61 uniFC62 uniFC63 uni06540651
uni0654064E uni0654064C uni0654064F uni06540652 uni0610 uni0611
uni0612 uni0613 uni0614]

Traceback (most recent call last):
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/

kernCheck.py", line 2010, in <module>
run()
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/
kernCheck.py", line 1989, in run

lookupIndexDict, lookupSequenceDict, fontFlatKernTable =
collectKernData(fontPath)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/

kernCheck.py", line 531, in collectKernData

subtableList, fontFlatKernTable = parseKernLookup(featureText,
fontFlatKernTable, lookup)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/

kernCheck.py", line 374, in parseKernLookup

backTrack, lookAhead, leftSide, rightSide, valueRecord =
parseContextPos(line)
File "/Users/Bahman/bin/FDK/Tools/osx/../SharedData/FDKScripts/

kernCheck.py", line 268, in parseContextPos

raise ValueError("Error: seeing a second marked glyph run.")

ValueError: Error: seeing a second marked glyph run.

Bahman

On Apr 5, 10:42 pm, Read Roberts <rrobe...@adobe.com> wrote:
> Hi Bahman;
>
> The complaint means that it is seeing something that it doesn't support; a
> contextual rule with an input sequence ( a marked glyph or class), a look
> ahead sequence, followed by a second input sequence. The FDK can't build
> this kind of rule,, so maybe there is an error in parsing the line.
>
> AT line 265, please replace:
>    if lookAhead:
>         raise ValueError("Error: seeing a seond marked glyph run.")
>
> With
>
>    if lookAhead:
>         print line
>         raise ValueError("Error: seeing a second marked glyph run.")
>
> And then e-mail me the output line that causes the error.
>
> - Read
>

[Read Roberts]

Hi Bahman;

The issue is that this script was written before the AFDKO supported
contextual lookups, and it did not expect to see the lookup references in
the middle of a marked input sequence.

The attached script will survive this, but will still ignore the
contextual positioning rules in the kern feature. I'm not likely to fix
this in the near future - it's just too low priority for the amount of
work, which would be a day or two. If you can find someone who can do
that, what needs to be done is to:
- for contextual rule, save the referenced lookup;
- Parse the referenced lookup when it is seen, which has single pos rules
in the form:
position uni0664 <-1934 0 -722 0>;
- match the target glyphs in the in the referenced lookup with the glyphs
in the context look-ahead, and print the kern pair.

- Read