RubyGems - laag-libtiff - Versions diffs - 4.0.9.0 - Mend

laag-libtiff 4.0.9.0

Files changed (629) hide show

data/vendor/gitlab.com/libtiff/libtiff/html/v3.9.5.html ADDED Viewed

@@ -0,0 +1,270 @@
+<HTML>
+<HEAD>
+<TITLE>
+	Changes in TIFF v3.9.5
+</TITLE>
+</HEAD>
+<BODY BGCOLOR=white>
+<FONT FACE="Helvetica, Arial, Sans">
+<FONT FACE="Helvetica, Arial, Sans">
+<BASEFONT SIZE=4>
+<B><FONT SIZE=+3>T</FONT>IFF <FONT SIZE=+2>C</FONT>HANGE <FONT SIZE=+2>I</FONT>NFORMATION</B>
+<BASEFONT SIZE=3>
+<UL>
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+<B>Current Version</B>: v3.9.5<BR>
+<B>Previous Version</B>: <A HREF=v3.9.4.html>v3.9.4</a><BR>
+<B>Master FTP Site</B>: <A HREF="ftp://download.osgeo.org/libtiff">
+download.osgeo.org</a>, directory pub/libtiff</A><BR>
+<B>Master HTTP Site</B>: <A HREF="http://www.simplesystems.org/libtiff/">
+http://www.simplesystems.org/libtiff/</a>
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+</UL>
+<P>
+This document describes the changes made to the software between the
+<I>previous</I> and <I>current</I> versions (see above).  If you don't
+find something listed here, then it was not done in this timeframe, or
+it was not considered important enough to be mentioned.  The following
+information is located here:
+<UL>
+<LI><A HREF="#hightlights">Major Changes</A>
+<LI><A HREF="#configure">Changes in the software configuration</A>
+<LI><A HREF="#libtiff">Changes in libtiff</A>
+<LI><A HREF="#tools">Changes in the tools</A>
+<LI><A HREF="#contrib">Changes in the contrib area</A>
+</UL>
+<p>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<A NAME="highlights"><B><FONT SIZE=+3>M</FONT>AJOR CHANGES:</B></A>
+<UL>
+	<li> None
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<A NAME="configure"><B><FONT SIZE=+3>C</FONT>HANGES IN THE SOFTWARE CONFIGURATION:</B></A>
+<UL>
+	<li> configure.ac: Should use AC_CANONICAL_HOST since host specifies
+	the run-time target whereas target is used to specify the final
+	output target if the package is a build tool (like a compiler),
+	which libtiff is not.  Resolves libtiff bug 2307 "Use
+	AC_CANONICAL_HOST macro".
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<A NAME="libtiff"><B><FONT SIZE=+3>C</FONT>HANGES IN LIBTIFF:</B></A>
+<UL>
+	<li> libtiff/tif_getimage.c: Check the number of samples per pixel when
+	working with YCbCr image in PickContigCase(). As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2216
+	<li> libtiff/tif_dir.c: Set the bogus post-decoding hook when processing
+	TIFFTAG_BITSPERSAMPLE in _TIFFVSetField() for the case of 8 bit when
+	we don't need any post-processing. That helps to reset the hook if we
+	previously set this field to some other value and the hook was
+	initialized accordingly. As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2035
+	<li> libtiff/tif_getimage.c: Avoid wrong math du to the signed/unsigned
+	integer type conversions. As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2207
+	<li> libtiff/tif_dirinfo.c: Don't use assertions in _TIFFFieldWithTag()
+	and _TIFFFieldWithName() if the tag is not found in the tag table.
+	This should be normal situation and returned NULL value should be
+	properly handled by the caller.
+	<li> libtiff/{tif_dirwrite.c, tif_print.c}: Properly handle "DotRange"
+	tag as it can be either byte or short size and should be set and read
+	by value, not as an array. As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2116
+	<li> libtiff/tif_dirread.c: Really reset the tag count in CheckDirCount()
+	to expected value as the warning message suggests. As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=1963
+	<li> libtiff/tif_open.c: Fix mode check before opening a file.
+	http://bugzilla.maptools.org/show_bug.cgi?id=1906
+	<li> libtiff/tif_jpeg.c, libtiff/tif_strip.c: apply patch for
+	CVE-2010-3087 per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2140
+	<li> libtiff/tif_dirread.c: fix crash when reading a badly-constructed
+	TIFF per http://bugzilla.maptools.org/show_bug.cgi?id=1994
+	<li> libtiff/tif_ojpeg.c: fix buffer overflow on problem data
+	http://bugzilla.maptools.org/show_bug.cgi?id=1999
+	<li> libtiff/tif_dirread.c: modify warnings
+	http://bugzilla.maptools.org/show_bug.cgi?id=2016
+	<li> libtiff/tif_jpeg.c: fix use of clumplines calculation
+	http://bugzilla.maptools.org/show_bug.cgi?id=2149
+	<li> libtiff/tif_color.c: prevent crash in handling bad TIFFs
+	resolves CVE-2010-2595
+	http://bugzilla.maptools.org/show_bug.cgi?id=2208
+	<li> libtiff/tif_dirread.c: fix needless tag ordering warning
+	http://bugzilla.maptools.org/show_bug.cgi?id=2210
+	<li> libtiff/tif_jpeg.c: reduce usage of JCS_UNKNOWN in order
+	to improve compatibility with various viewers
+	submitted by e-mail from Dwight Kelly <dkelly@apago.com>
+	<li> libtiff/tif_strip.c: use TIFFGetFieldDefaulted instead
+	of TIFFGetField when we assume that it will succeed
+	http://bugzilla.maptools.org/show_bug.cgi?id=2215
+	<li> libtiff/tif_dirread.c: tolerate some cases where
+	FIELD_COLORMAP is missing
+	http://bugzilla.maptools.org/show_bug.cgi?id=2189
+	<li> libtiff/tif_jpeg.c: Fix regressions with 2 and 3 band images
+	caused by commit on 2010-12-14.  Submitted by e-mail from
+	Even Rouault <even.rouault@mines-paris.org>
+	<li> libtiff/tif_dirwrite.c: Avoid undefined behaviour when casting from
+	float to unsigned integer in TIFFWriteRationalArray() as reported by
+	Kareem Shehata.
+	<li> libtiff/tif_fax3.h: Protect against a fax VL(n) codeword commanding
+	a move left.  Without this, a malicious input file can generate an
+	indefinitely large series of runs without a0 ever reaching the right
+	margin, thus overrunning our buffer of run lengths.  Per CVE-2011-0192.
+	This is a modified version of a patch proposed by Drew Yao of Apple
+	Product Security.  It adds an unexpected() report, and disallows the
+	equality case, since emitting a run without increasing a0 still allows
+	buffer overrun.
+	<li> libtiff/tif_fax3.h: Fix to last change allowing zero length
+	runs at the start of a scanline - needed for legal cases.
+	<li> libtiff/tif_thunder.c: Correct potential buffer overflow with
+	thunder encoded files with wrong bitspersample set.  The libtiff
+	development team would like to thank Marin Barbella and TippingPoint's
+	Zero Day Initiative for reporting this vulnerability (ZDI-CAN-1004,
+	CVE-2011-1167).
+	http://bugzilla.maptools.org/show_bug.cgi?id=2300
+	<li> libtiff/tiffiop.h: avoid declaring int64/uint64 on AIX with XLC
+	where they are already available.  (#2301)
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!-------------------------------------------------------------------------->
+<A NAME="tools"><B><FONT SIZE=+3>C</FONT>HANGES IN THE TOOLS:</B></A>
+<UL>
+	<li> tools/tiffcrop.c: Patch from Richard Nolde. Reject YCbCr
+	subsampled data since tiffcrop currently doesn't support it.  Fix
+	JPEG support.
+	<li> tools/tiffcp.c: Initialize buffer arrays with zero to avoid
+	referencing to uninitialized memory in some cases (e.g. when tile size
+	set bigger than the image size).
+	<li> tools/tiff2pdf.c: Better generation of ID field in
+	t2p_write_pdf_trailer(). Get rid of GCC aliasing warnings.
+	<li> tools/tiff2pdf.c: Fixed computation of the tile buffer size when
+	converting JPEG encoded tiles.
+	<li> tools/tiff2pdf.c: Better handling of string fields, use static
+	string buffers instead of dynamically allocated, use strncpy() instead
+	of strcpy(), control the string lengths.
+	<li> tools/{tiff2bw.c, thumbnail.c, pal2rgb.c}: Fix the count for
+	WhitePoint tag as per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2042
+	<li> tools/tiffdump.c: Use PrintData() function instead of
+	PrintByte/Short/Long(). Should fix an issue reported at
+	http://bugzilla.maptools.org/show_bug.cgi?id=2116
+	<li> tools/tiffset.c: Properly handle TIFFTAG_PAGENUMBER,
+	TIFFTAG_HALFTONEHINTS, TIFFTAG_YCBCRSUBSAMPLING, TIFFTAG_DOTRANGE
+	which should be set by value.
+	<li> tools/tiffdump.c: Avoid integer overflows computing the buffer size
+	for large directories. As per bug
+	http://bugzilla.maptools.org/show_bug.cgi?id=2218
+	<li> tools/tiff2pdf.c: Fixed ID buffer filling in
+	t2p_write_pdf_trailer(), thanks to Dmitry V. Levin.
+	<li> tools/tiffcrop.c: Patch from Richard Nolde to avoid a
+	potentially unterminated buffer due to using an exceptionally long
+	file name.
+	<li> tools/tiff2ps.c: improvements and enhancements from Richard Nolde
+	with additional command line options for Document Title,
+	Document Creator, and Page Orientation
+	<li> tools/tiffsplit.c: abort when reading a TIFF without a byte-count
+	per http://bugzilla.maptools.org/show_bug.cgi?id=1996
+	<li> tools/tiff2pdf.c: add fill-page option
+	 http://bugzilla.maptools.org/show_bug.cgi?id=2051
+	<li> tools/fax2ps.c: replace unsafe tmpfile() with mkstemp()
+	http://bugzilla.maptools.org/show_bug.cgi?id=2118
+	<li> tools/tiff2pdf.c: fix colors for images with RGBA
+	interleaved data
+	http://bugzilla.maptools.org/show_bug.cgi?id=2250
+	<li> tools/tiffcrop.c: new release by Richard Nolde
+	http://bugzilla.maptools.org/show_bug.cgi?id=2004
+	<li> tools/fax2ps.c: be consistent with page-numbering
+	http://bugzilla.maptools.org/show_bug.cgi?id=2225
+	<li> tools/gif2tiff.c: fix buffer overrun
+	http://bugzilla.maptools.org/show_bug.cgi?id=2270
+	<li> tools/fax2ps.c (main): Use tmpfile() rather than mkstemp() since
+	it is much more portable.  Tmpfile is included in ISO/IEC
+	9899:1990 and the WIN32 CRT.
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<A NAME="contrib"><B><FONT SIZE=+3>C</FONT>HANGES IN THE CONTRIB AREA:</B></A>
+<UL>
+	<li> None
+</UL>
+Last updated $Date: 2016-09-25 20:05:47 $.
+</BODY>
+</HTML>

data/vendor/gitlab.com/libtiff/libtiff/html/v4.0.0.html ADDED Viewed

@@ -0,0 +1,269 @@
+<HTML>
+<HEAD>
+<TITLE>
+	Changes in TIFF v4.0.0
+</TITLE>
+</HEAD>
+<BODY BGCOLOR=white>
+<FONT FACE="Helvetica, Arial, Sans">
+<FONT FACE="Helvetica, Arial, Sans">
+<BASEFONT SIZE=4>
+<B><FONT SIZE=+3>T</FONT>IFF <FONT SIZE=+2>C</FONT>HANGE <FONT SIZE=+2>I</FONT>NFORMATION</B>
+<BASEFONT SIZE=3>
+<UL>
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+<B>Current Version</B>: v4.0.0<BR>
+<B>Previous Version</B>: <A HREF=v3.9.5.html>v3.9.5</a><BR>
+<B>Master FTP Site</B>: <A HREF="ftp://download.osgeo.org/libtiff">
+download.osgeo.org</a>, directory pub/libtiff</A><BR>
+<B>Master HTTP Site</B>: <A HREF="ftp://download.osgeo.org/libtiff">
+ftp://download.osgeo.org/libtiff</a>
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+</UL>
+<P>
+This document describes the changes made to the software between the
+<I>previous</I> and <I>current</I> versions (see above).  If you don't
+find something listed here, then it was not done in this timeframe, or
+it was not considered important enough to be mentioned. Please consult
+the ChangeLog file in the source package for full change details.  The
+following information is located here:
+<UL>
+<LI><A HREF="#hightlights">Major Changes</A>
+<LI><A HREF="#configure">Changes in the software configuration</A>
+<LI><A HREF="#libtiff">Changes in libtiff</A>
+<LI><A HREF="#tools">Changes in the tools</A>
+<LI><A HREF="#contrib">Changes in the contrib area</A>
+</UL>
+<p>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<P><A NAME="highlights"><B><FONT SIZE=+3>M</FONT>AJOR CHANGES:</B></A></P>
+BigTIFF support changes:
+<UL>
+	<LI>The options parameter in the TIFFOpen and TIFFClientOpen funcs has
+	been extended. When creating new files, you can add option '4' to
+	specify you want to create a ClassicTIFF file, though that is the
+	default and the option is not strictly necessary. (As such, old
+	calling code will continue to function and create ClassicTIFF files.)
+	Or you can add option '8' to specify you want to create a BigTIFF file
+	instead. This new option is also reflected in some of the tools we
+	already upgraded. For instance, you can use the -8 option on tiffcp to
+	have tiffcp produce BigTIFF files instead of the default ClassicTIFF.
+	(Whilst on additional option is provided for version selection when
+	creating new files, no such option is necessary when reading TIFF
+	files. LibTiff reads ClassicTIFF and BigTIFF both, and the application
+	does not need to be aware which TIFF version an opened file is.)
+	<LI>Although the tag count in BigTIFF is 64bit, we restricted the
+	count in the implementation to a much more reasonable size. This is
+	necessary in current implementation, because all tag data gets read
+	automatically in the IFD reading stage, so if there's half a dozen
+	private tags with multiple gigabytes of data that causes considerable
+	overhead even if the application level is never interested in these
+	tags. Our choice to ignore tags with data longer then a certain sanity
+	value is much needed as things stand. We also recommend to step away
+	from writing tiles that are 8 kilobyte in their uncompressed form, or
+	writing single-line strips, in really big files, resulting in mega's
+	of tiles or strips. It's much more efficient to choose bigger tile or
+	strip sizes, up to several megabyte if needed, and have a few kilo of
+	tiles or strips instead.
+	<LI>Although it's rare, some application code does directly access
+	file offsets. Some of these are automatically upgraded because they
+	used the toff_t type, others need to be aware that the datatype
+	changed and need to start using toff_t or uint64. This impacts access
+	to tags like the EXIF IFD tag, for example, or the SubIfds tag, or to
+	StripOffsets or TileOffsets, the return type of functions like
+	TIFFCurrentDirOffset, and a parameter type to functions like
+	TIFFSetSubDirectory.
+	<LI>Although it's rare, some application code does use structures
+	like TIFFHeader or TIFFDirEntry that used to be an exact binary
+	representation of TIFF structures. These need to change. The old
+	TIFFHeader structure is replaced by the new TIFFHeaderClassic,
+	TIFFHeaderBig, and TIFFHeaderCommon structures that are an exact
+	binary representation of the ClassicTIFF and BigTIFF header, and of
+	the part that is common to both. There is no new equivalent for the
+	old TIFFDirEntry structure (or more precisely, there is still a
+	TIFFDirEntry structure, but it is changed, moved to library-private
+	definition, and no longer an exact binary representation of the tag
+	structure of either TIFF version).
+	<LI>Sizer functions, like TIFFTileSize or TIFFScanlineSize and the
+	like, return a tmsize_t value (tmsize_t is defined as int32 on 32bit
+	machines, and int64 on 64bit machines, and as such it is meant to
+	represent signed memory sizes). This is because we figure 98% of the
+	calling code uses the return value as sizes in allocations and the
+	like. So, any overflow that is theoretically possible with BigTIFF
+	when LibTiff is running on a 32bit system, is best detected inside the
+	sizer functions and it is best to return a type that makes sense as a
+	memory size. If your calling code is the exception and is interested
+	in actual file size, you best use the newer TIFFTileSize64 or
+	TIFFScanlineSize64 function that returns an uint64 type.
+	<LI>These TIFF tags require a 64-bit type as an argument in
+	libtiff 4.0.0:
+	<UL>
+	<LI> TIFFTAG_FREEBYTECOUNTS
+	<LI> TIFFTAG_FREEOFFSETS
+	<LI> TIFFTAG_STRIPBYTECOUNTS
+	<LI> TIFFTAG_STRIPOFFSETS
+	<LI> TIFFTAG_TILEBYTECOUNTS
+	<LI> TIFFTAG_TILEOFFSETS
+	</UL>
+</UL>
+Other important backward incompatible changes in the public API:
+<UL>
+	<LI> TIFFRewriteField() renamed into _TIFFRewriteField() and moved out
+	from the public interface (from tiffio.h to tiffiop.h). Type of its
+	'count' parameter changed from uint32 to tmsize_t.
+	<LI> TIFFMergeFieldInfo() returns non-void result now. It returns 0
+	if successful and -1 if failed. Though this is now obsoleted function
+	and should not be used in new programs. Use the new tag extension
+	scheme instead.
+	<LI> TIFFFieldWithTag() and TIFFFieldWithName() functions now return
+	pointer to TIFFField constant object instead of TIFFFieldInfo.
+	<LI> TIFFReassignTagToIgnore() function and TIFFIgnoreSense enumeration
+	have been removed. They was unused and never been used properly.
+	Should be unneeded for high-level applications.
+	<LI> TIFFTagValue structure removed from the public tiffio.h
+	to private tif_dir.h and not accessible anymore. It should be unneeded
+	for high-level applications.
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<P><A NAME="configure"><B><FONT SIZE=+3>C</FONT>HANGES IN THE SOFTWARE CONFIGURATION:</B></A></P>
+<UL>
+	<LI>Updated autotools: Autoconf 2.68, Automake 1.11.1, libtool
+	2.4.
+	<LI>Enabled support for Automake silent build rules
+	(--enable-silent-rules or 'make V=0')
+	<LI>Enabled support for Automake colorized and parallel tests.
+	<LI>Added detection of 64-bit integer types since libtiff 4.0
+	requires use of 64-bit signed and unsigned integer types.
+	<LI>Libtiff now provides a more comprehensive test suite with
+	over 72 tests, which may be executed on Unix-like systems, or
+	under Microsoft Windows using MinGW/MSYS or Cygwin.
+	<LI>--disable-lzma configure option to disable use of liblzma.
+	<LI>--enable-defer-strile-load configure option to enable
+	experimental deferred strip/tile offset/size loading.  May
+	cause some extremely sophisticated uses of libtiff to fail.
+	<LI>--enable-chunky-strip-read configure option to enable
+	experimental enable reading large strips in chunks in
+	TIFFReadScanline().
+	<LI>Now always uses WIN32 native I/O functions for Microsoft
+	Windows except for under Cygwin.
+	<LI>Now provides a pkg-config support file (libtiff-4.pc).
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<P><A NAME="libtiff"><B><FONT SIZE=+3>C</FONT>HANGES IN LIBTIFF:</B></A></P>
+<UL>
+        <LI>Patches/fixes made to stable libtiff (v3.9.X) are also
+        applied to 4.0.0.  There are too many to list here.  See the
+        distribution ChangeLog for a detailed change list.
+	<LI>There is considerable change in some files like
+	tif_dirread and tif_dirwrite. These changes don't impact
+	backwards compatibility, they are mostly a clean rewrite that
+	does allow BigTIFF support as well as somewhat more robust
+	reading of the unexpected already and will also serve future
+	API extension but does not impact current API or functionality
+	in a negative way that you need to know about.
+	<LI>Although there is still a functional definition for types
+	like toff_t (file offset), tstrip_t (strip index number), etc,
+	we recommend against using these in newer code. We have
+	learned that it is next to impossible to use these
+	consistently and make real abstraction of the binary format of
+	these types. Instead, at a certain level we always end up
+	doing casts anyway, and taking the exact binary format into
+	account, so these types are nothing but dangerously misleading
+	and obfuscating. You do not need to update calling code that
+	uses them, as 99.9% of such code will continue to work. But we
+	recommend against using them in newer calling code, and we
+	started replacing them with binary clear types like uint16,
+	uint32 and such in the library.
+	<LI>We do use and will continue to use one functional type
+	that is an exception to the above rule, being tmsize_t. This
+	is a signed memory size type, i.e. it is int32 on 32bit
+	machines, or int64 on 64bit machines.
+	<LI>Optionally support LZMA compression via TIFF tag 34925.
+	Tiffcp supports compression levels similar to "-c lzma:p1" or
+	"-c zip:p9 for setting the LZMA compression parameters.
+	<LI>Optionally defer the load of strip/tile offset and size
+	tags for optimized scanning of directories.  Enabled with the
+	--enable-defer-strile-load configure option (DEFER_STRILE_LOAD
+	#define in tif_config.h).
+	<LI>Optionally enable experimental support for reading big
+	strips in chunks.  Enabled with the --enable-chunky-strip-read
+	configure option.
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!-------------------------------------------------------------------------->
+<P><A NAME="tools"><B><FONT SIZE=+3>C</FONT>HANGES IN THE TOOLS:</B></A></P>
+<UL>
+	<LI>tiffset: add -d and -sd switches to allow operation on
+	a particular directory, not just the first.
+</UL>
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+<P><A NAME="contrib"><B><FONT SIZE=+3>C</FONT>HANGES IN THE CONTRIB AREA:</B></A></P>
+<UL>
+</UL>
+Last updated $Date: 2016-09-25 20:05:47 $.
+</BODY>
+</HTML>