summaryrefslogtreecommitdiff
path: root/xfont.pc.in
diff options
context:
space:
mode:
authorTomas Hoger <thoger@redhat.com>2011-10-10 14:38:06 -0700
committerJeremy Huddleston <jeremyhu@apple.com>2011-10-10 14:38:06 -0700
commit8d130ac0fcf19e0e0dd0a404d9317fd8860baad4 (patch)
treeb62fdbb5eeebff4231823f8fec23bd6902df145c /xfont.pc.in
parentbb97dbf56dff50bef936c0631587ed08dd6c8fa9 (diff)
Support compress files with maxbits < 12
The compress decompression code used by libXfont rejects valid archives with maxbits less than 12 (compress allows values 9 - 16, 16 is the default). This is because maxbits-12 is used as index to hsize_table[]. That looks like an incorrect port of the original compress code, where: - hsize depended on BITS, the maximum maxbits value supported by particular build, rather than on maxbits value from the particular input file - the same hsize was used for all BITS <= 12 The quick way to verify the problem is: compress -b 11 fontfile.bdf bdftopcf -o /dev/null fontfile.bdf.Z which fails, while 12-16 works correctly. This fix removes hsize_table and uses 1 << maxbits (aka maxmaxcode) as tab_prefix size. As decompression code does not use hashing as compression code, there does not seem to be a reason to allocate any extra space. Note: In this fix, maxbits == 9 is still rejected early. AFAICS compress is able to generate such files (unknown how correct such output is), but is unable to uncompress them correctly. Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Diffstat (limited to 'xfont.pc.in')
0 files changed, 0 insertions, 0 deletions