From 8425aaee8f1c6c4a4f46aa8770349921e7257cba Mon Sep 17 00:00:00 2001 From: Urvang Joshi Date: Thu, 20 Dec 2012 11:25:59 -0800 Subject: [PATCH] Formatting fixes in lossless bitstream spec - Escape brackets for which kramdown was generating a warning. Note: This only changes this source file; output HTML would look exactly the same. - Also write '5' in words ('five'). Change-Id: I472a03c090a12eb7520719ea463469b36a2736b9 --- doc/webp-lossless-bitstream-spec.txt | 33 ++++++++++++++-------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/doc/webp-lossless-bitstream-spec.txt b/doc/webp-lossless-bitstream-spec.txt index a2d95ca2..7af58f1e 100644 --- a/doc/webp-lossless-bitstream-spec.txt +++ b/doc/webp-lossless-bitstream-spec.txt @@ -361,14 +361,14 @@ int ClampAddSubtractHalf(int a, int b) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are special handling rules for some border pixels. If there is a -prediction transform, regardless of the mode [0..13] for these pixels, +prediction transform, regardless of the mode \[0..13\] for these pixels, the predicted value for the left-topmost pixel of the image is 0xff000000, L-pixel for all pixels on the top row, and T-pixel for all pixels on the leftmost column. Addressing the TR-pixel for pixels on the rightmost column is exceptional. The pixels on the rightmost column are predicted by using -the modes [0..13] just like pixels not on border, but by using the +the modes \[0..13\] just like pixels not on border, but by using the leftmost pixel on the same row as the current TR-pixel. The TR-pixel offset in memory is the same for border and non-border pixels. @@ -420,7 +420,7 @@ void ColorTransform(uint8 red, uint8 blue, uint8 green, `ColorTransformDelta` is computed using a signed 8-bit integer representing a 3.5-fixed-point number, and a signed 8-bit RGB color -channel (c) [-128..127] and is defined as follows: +channel (c) \[-128..127\] and is defined as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ int8 ColorTransformDelta(int8 t, int8 c) { @@ -567,10 +567,10 @@ if (color_table_size <= 2) { `width_bits` has a value of 0, 1, 2 or 3. A value of 0 indicates no pixel bundling to be done for the image. A value of 1 indicates that two -pixels are combined together, and each pixel has a range of [0..15]. A +pixels are combined together, and each pixel has a range of \[0..15\]. A value of 2 indicates that four pixels are combined together, and each -pixel has a range of [0..3]. A value of 3 indicates that eight pixels -are combined together and each pixel has a range of [0..1], i.e., a +pixel has a range of \[0..3\]. A value of 3 indicates that eight pixels +are combined together and each pixel has a range of \[0..1\], i.e., a binary value. The values are packed into the green component as follows: @@ -714,7 +714,7 @@ pixel. The distance codes larger than 120 denote the pixel-distance in scan-line order, offset by 120. -The smallest distance codes [1..120] are special, and are reserved for a close +The smallest distance codes \[1..120\] are special, and are reserved for a close neighborhood of the current pixel. This neighborhood consists of 120 pixels: * Pixels that are 1 to 7 rows above the current pixel, and are up to 8 columns @@ -785,7 +785,7 @@ int color_cache_size = 1 << color_cache_code_bits; `color_cache_code_bits` defines the size of the color_cache by (1 << `color_cache_code_bits`). The range of allowed values for -`color_cache_code_bits` is [1..11]. Compliant decoders must indicate a +`color_cache_code_bits` is \[1..11\]. Compliant decoders must indicate a corrupted bitstream for other values. A color cache is an array of size `color_cache_size`. Each entry @@ -953,7 +953,7 @@ by a 1-bit value. **(i) Simple Code Length Code:** This variant is used in the special case when only 1 or 2 Huffman code lengths -are non-zero, and are in the range of [0, 255]. All other Huffman code lengths +are non-zero, and are in the range of \[0, 255\]. All other Huffman code lengths are implicitly zeros. The first bit indicates the number of non-zero code lengths: @@ -963,7 +963,7 @@ int num_code_lengths = ReadBits(1) + 1; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The first code length is stored either using a 1-bit code for values of 0 and 1, -or using an 8-bit code for values in range [0, 255]. The second code length, +or using an 8-bit code for values in range \[0, 255\]. The second code length, when present, is coded as an 8-bit code. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1000,15 +1000,15 @@ for (i = 0; i < num_code_lengths; ++i) { } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * Code length code [0..15] indicates literal code lengths. + * Code length code \[0..15\] indicates literal code lengths. * Value 0 means no symbols have been coded. - * Values [1..15] indicate the bit length of the respective code. - * Code 16 repeats the previous non-zero value [3..6] times, i.e., + * Values \[1..15\] indicate the bit length of the respective code. + * Code 16 repeats the previous non-zero value \[3..6\] times, i.e., 3 + `ReadBits(2)` times. If code 16 is used before a non-zero value has been emitted, a value of 8 is repeated. - * Code 17 emits a streak of zeros [3..10], i.e., 3 + `ReadBits(3)` + * Code 17 emits a streak of zeros \[3..10\], i.e., 3 + `ReadBits(3)` times. - * Code 18 emits a streak of zeros of length [11..138], i.e., + * Code 18 emits a streak of zeros of length \[11..138\], i.e., 11 + `ReadBits(7)` times. @@ -1059,7 +1059,8 @@ of pixels (xsize * ysize). ::= See "Interpretation of Meta Huffman codes" to - understand what each of these 5 Huffman codes are for. + understand what each of these five Huffman codes are + for. ::= | ::= see "Simple code length code" for details ::= ; encoded code lengths