Re: Found problem with Subrs parsing...

[Just van Rossum]

At 2:59 PM -0400 24-07-2000, Tom Kacvinsky wrote:
>And it is:
>
>Some fonts (including an older version of ITC Garamond Light I had
>laying around) do not define the subrs in increasing order; but the
>t1z driver expects them to be in increasing order.

Ah, good catch! I had noticed that in the version I have the subrs are
sorted by "alphabetical" order:

/Subrs 117 array
dup 0 RD {
        3 0 callothersubr
        pop
        pop
        setcurrentpoint
        return
        } noaccess put
dup 1 RD {
        0 1 callothersubr
        return
        } noaccess put
dup 10 RD {
        2 callsubr
        -66 2 rmoveto
        2 callsubr
        30 1 rmoveto
        83 callsubr
        29 -1 rmoveto
        2 callsubr
        return
        } noaccess put
dup 100 RD {
        35 23 27 30 vhcurveto
        31 22 -27 -35 hvcurveto
        -36 -22 -26 -31 vhcurveto
        -30 -23 26 36 hvcurveto
        closepath
        return
        } noaccess put
dup 101 RD {
        2 callsubr
        -32 1 rmoveto
        2 callsubr
        return
        } noaccess put
[ etc... ]

;-)

>The "offending" code is in z1load.c (function parse_subrs).  I have
>not yet thought of an elegant patch for this.  David?

I'll have a look, too.

Just