verify that openjpeg actually allocates data

This can be seen e.g. in:

5db811ac25ef543fd0cfa0873e155329_signal_sigsegv_c9b60f_9636_76.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
Bug 694851: enhance fz_load_system_font

For SumatraPDF, the following changes are required:
* fz_load_system_font is called from pdf_load_builtin_font as well so
  that Arial, Courier New, etc. can be loaded from the system instead
  of their Nimbus replacements. In order to distinguish between calls
  from pdf_load_builtin_font and pdf_load_substitute_font, an
  is_substitute argument is added.
* fz_load_system_cjk_font is added and called from
  pdf_load_substitute_cjk_font so that a better replacement font can
  be loaded instead of DroidSansFallback.
* Both fz_load_system_font and fz_load_system_cjk_font return fz_font*
  instead of fz_buffer* so that implementers aren't required to load
  fonts into memory (SumatraPDF uses fz_new_font_from_file for system
  fonts).

In addition to that, fz_load_system_font_func is renamed to
fz_load_system_font_funcs since it now accepts two functions, and the
PDF_ROS_* constants are renamed to FZ_ADOBE_* (collection names aren't
passed as const char* so that implementers know which collections to
expect). For convenience, fz_load_*_font also never throws since
currently all callers have further fallbacks available.
Bug 694890: Solve valgrind issues/SEGV due to use of invalid pixmap

fz_draw_clip_text changes the value of 'state' during a loop. The
'if (glyph)' part of the loop assumes that it points to gstate[top-1]
where the 'path' part of the loop changes it to point to gstate[top].

If we render a "non glyph" glyph, then a "glyph" glyph, we will access
an invalid state. This can cause a draw_glyph call on an invalid
destination bitmap.

The fix is simply not to reset state.

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the fuzzing files.
tolerate overlong colorspace lookup strings

At http://code.google.com/p/sumatrapdf/issues/detail?id=2477 , there's
a document which has an indexed colorspace whose lookup string contains
a trailing character. That character can be safely ignored without
rejecting everything depending on such a colorspace.
Avoid rendering errors caused by linejoins on tiny distances.

If we perform a linejoin that ends up being over an impossibly small
distance, we can get a rendering error. This is caused by trying to
calculate scale = linewidth/sqrtf(len), where len < FLT_EPSILON.

Avoid this by rearranging the code slightly - no extra calculations
required.

Also given that sn == bn at all times within the stroking code, just
remove bn.

Credit for spotting this problem goes to Simon for tracking the
problem with rounding_artifact_due_to_closepath.pdf. My fix just
fixes the problem at a lower level than his does.
Fixes for Windows 8.1 store validation

We have to clean up the DirectX memory during suspension.

Also define NDEBUG for the release cases so that we avoid the use of OutputDebugStringA
in error.c which is not allowed in Windows store apps.
Minor changes for windows 8 store validation
Clearer division in WinRT vs std C++ code

To share as much code as possible between the Windows 8 app, windows phone app
and Windows desktop app, remove dependencies of Platform and Windows::Foundation
in files that interface to mupdf and replace with C/C++ std methods.
Remove repeated NDEBUG in release preprocessor list in WinRT projects
Bug 694894: Avoid throwing away an object while in use.

When we call to execute a pattern, we clear out the pdf_csi (the
interpreter state). This involves clearing the stack and throwing
away the record of the object we have just parsed.

Unfortunately, when filling glyphs with a pattern, that object is
still in use. We therefore amend the pdf_run_contents_stream to
safely stash the object away and restore it afterwards.

This solves this problem, and protects us against any other similar
problems that might also arise.

This solves:

  b8e2b57991896bf8120215cfbf7b54bb_asan_heap-uaf_86064f_2362_2587.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
disable JPEG decoding speed-ups to prevent artifacts

Using JDCT_FASTEST as rendering method can produce visible artifacts
(e.g. in 1960_-_DCT_image_wrongly_decoded_regression_from_1.2_.pdf).
fix memory leaks in pdf_load_jpx and fz_new_image_from_pixmap

fz_new_image_from_pixmap expects that the pixmap's colorspace has two
references which is contrary to expectations. If it instead addrefs the
pixmap's colorspace, the only caller pdf_load_jpx can consistently
drop the colorspace after passing it to fz_load_jpx.

Also, if the contract is that whatever is passed into
fz_new_image_from_pixmap belongs to the new image, then the pixmap also
has to be dropped on error so that it isn't leaked.
Revert change of mupdf.sln from VS2005 format to VS2012.
Bug 694957: fix stack buffer overflow in xps_parse_color

xps_parse_color happily reads more than FZ_MAX_COLORS values out of a
ContextColor array which overflows the passed in samples array.
Limiting the number of allowed samples to FZ_MAX_COLORS and make sure
to use that constant for all callers fixes the problem.

Thanks to Jean-Jamil Khalifé for reporting and investigating the issue
and providing a sample exploit file.
Add missing dependencies back into VS2005 project.

Lost as part of the accidental VS2012 change.
Bug 694897: Fix valgrind issues with versions

If the /Version is a single character string (say "s") then the
current code for converting this in pdf_init_document reads off
the end of the string.

Simple fix is to use fz_atof instead.

Same fix for reading the PDF version normally.

This solves:

  53b830f849d028fb2d528520716e157a_asan_heap-oob_478692_5259_4534.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
Bug 694896: Ensure that repairs don't lose trailer dict.

When we find certain classes of flaw in the file while attempting to
read an object, we trigger an automatic repair of the file. This
leaves almost all objects unchanged; the sole exception is that of
the trailer object (and its sub objects) which can get dropped and
recreated.

To avoid leaving people holding handles to objects within the trailer
dict high and dry, we introduce a 'pre_repair_trailer' object to
each xref entry. On a repair, we copy the existing trailer object to
this. As we only ever repair once, this is safe.

The only known place where this is a problem is when setting up the
pdf_crypt for a document; we adapt the code here to allow for
potential problems.

The example file that shows this up is:

  048d14d2f5f0ae31e9a2cde0be66f16a_asan_heap-uaf_86d4ed_3961_3661.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the fuzzing files.
Fix more Memento/Valgrind interactions.

Seen when valgrinding a memento build of mudraw on:

  e0e44ed8692671b820de72c6c0a32608_asan_heap-uaf_8c2b76_1530_2026.pdf
Avoid overflows in floating point causing illegal accesses

If the scale is too large, the calculation to determine the
required size of a pixmap can overflow. This can lead to negative
width/heights being passed in, which confuses the subsampling
code, leading to SEGVs.
Bug 694899: Avoid using invalid gstate pointer.

When we call pdf_begin_group, this can go away and do lots of
drawing. This can result in the gstate stack growing, which can
involve a realloc. Any gstate pointer we are holding must therefore
be recalculated after such a call.

The neatest way to do this is to get pdf_begin_group to return
the gstate pointer, thus making it hard to forget to do.

This solves:

  e2a1dda5393f4cb8a446fd8edd9d94f9_asan_heap-uaf_b938cf_2075_2393.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.