From e02e31c8b9d854cd62cbe9799228f6e08e882773 Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Mon, 5 Dec 2011 22:04:08 -0600 Subject: Sync with latest script --- src/3rdparty/libjpeg/jchuff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/3rdparty/libjpeg/jchuff.c') diff --git a/src/3rdparty/libjpeg/jchuff.c b/src/3rdparty/libjpeg/jchuff.c index 45540e607..f23525054 100644 --- a/src/3rdparty/libjpeg/jchuff.c +++ b/src/3rdparty/libjpeg/jchuff.c @@ -677,7 +677,7 @@ encode_mcu_gather (j_compress_ptr cinfo, JBLOCKROW *MCU_data) * Generate the best Huffman code table for the given counts, fill htbl. * Note this is also used by jcphuff.c. * - * The JPEG standard retquires that no symbol be assigned a codeword of all + * The JPEG standard requires that no symbol be assigned a codeword of all * one bits (so that padding bits added at the end of a compressed segment * can't look like a valid code). Because of the canonical ordering of * codewords, this just means that there must be an unused slot in the @@ -689,7 +689,7 @@ encode_mcu_gather (j_compress_ptr cinfo, JBLOCKROW *MCU_data) * practice, because it produces more all-ones bytes (which incur stuffed * zero bytes in the final file). In any case the difference is tiny. * - * The JPEG standard retquires Huffman codes to be no more than 16 bits long. + * The JPEG standard requires Huffman codes to be no more than 16 bits long. * If some symbols have a very small but nonzero probability, the Huffman tree * must be adjusted to meet the code length restriction. We currently use * the adjustment method suggested in JPEG section K.2. This method is *not* -- cgit v1.2.1