Fix native TQt3 accidental conversion to tquit

1 files changed, 6 insertions, 6 deletions

diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc
index 01835b2c9..95da39e78 100644
--- a/src/3rdparty/libjpeg/libjpeg.doc
+++ b/src/3rdparty/libjpeg/libjpeg.doc
@@ -443,7 +443,7 @@ stdio stream (if necessary) afterwards.
 If you have requested a multi-pass operating mode, such as Huffman code
 optimization, jpeg_finish_compress() will perform the additional passes using
 data buffered by the first pass.  In this case jpeg_finish_compress() may take
-tquite a while to complete.  With the default compression parameters, this will
+quite a while to complete.  With the default compression parameters, this will
 not happen.
 
 It is an error to call jpeg_finish_compress() before writing the necessary
@@ -620,7 +620,7 @@ Typical code is just
 
 If you have requested a multi-pass operating mode, such as 2-pass color
 quantization, jpeg_start_decompress() will do everything needed before data
-output can begin.  In this case jpeg_start_decompress() may take tquite a while
+output can begin.  In this case jpeg_start_decompress() may take quite a while
 to complete.  With a single-scan (non progressive) JPEG file and default
 decompression parameters, this will not happen; jpeg_start_decompress() will
 return tquickly.
@@ -1003,7 +1003,7 @@ int v_samp_factor
 	Horizontal and vertical sampling factors for the component; must
 	be 1..4 according to the JPEG standard.  Note that larger sampling
 	factors indicate a higher-resolution component; many people find
-	this behavior tquite unintuitive.  The default values are 2,2 for
+	this behavior quite unintuitive.  The default values are 2,2 for
 	luminance components and 1,1 for chrominance components, except
 	for grayscale where 1,1 is used.
 
@@ -1931,7 +1931,7 @@ something like this:
 	    ...
 	    jpeg_finish_output()
 	} while (! final_pass);
-rather than tquitting as soon as jpeg_input_complete() returns TRUE.  This
+rather than quitting as soon as jpeg_input_complete() returns TRUE.  This
 arrangement makes it simple to use higher-quality decoding parameters
 for the final pass.  But if you don't want to use special parameters for
 the final pass, the right loop logic is like this:
@@ -2108,7 +2108,7 @@ result at any time after jpeg_read_header() completes.
 
 It is also worth noting that when you use jpeg_consume_input() to let input
 processing get ahead of output processing, the resulting pattern of access to
-the coefficient buffer is tquite nonsequential.  It's best to use the memory
+the coefficient buffer is quite nonsequential.  It's best to use the memory
 manager jmemnobs.c if you can (ie, if you have enough real or virtual main
 memory).  If not, at least make sure that max_memory_to_use is set as high as
 possible.  If the JPEG memory manager has to use a temporary file, you will
@@ -2890,7 +2890,7 @@ expect that few applications will need more than four or so.
 On machines with unusual data type sizes, you may be able to improve
 performance or reduce memory space by tweaking the various typedefs in
 jmorecfg.h.  In particular, on some RISC CPUs, access to arrays of "short"s
-is tquite slow; consider trading memory for speed by making JCOEF, INT16, and
+is quite slow; consider trading memory for speed by making JCOEF, INT16, and
 UINT16 be "int" or "unsigned int".  UINT8 is also a candidate to become int.
 You probably don't want to make JSAMPLE be int unless you have lots of memory
 to burn.