| Age | Commit message (Collapse) | Author |
|---|
|
Previously the trailing null terminator would not be written if the
formatted string ended up longer than the buffer.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Emit characters with callbacks so we don't need to do two passes using
vsnprintf to count, format, and copy the result.
|
|
|
|
|
|
|
|
This is used at several places in mupdf.
|
|
Previously we might and up with prints such as:
error: malloc of array (%zu x %zu bytes) failed
because %zu was never interpreted on 32-bit platforms
where sizeof(size_t) < 8. After this fix we now get:
error: malloc of array (14445 x 118800 bytes) failed
|
|
This silences the many warnings we get when building for x64
in windows.
This does not address any of the warnings we get in thirdparty
libraries - in particular harfbuzz. These look (at a quick
glance) harmless though.
|
|
|
|
Use fz_output in debug printing functions.
Use fz_output in pdfshow.
Use fz_output in fz_trace_device instead of stdout.
Use fz_output in pdf-write.c.
Rename fz_new_output_to_filename to fz_new_output_with_path.
Add seek and tell to fz_output.
Remove unused functions like fz_fprintf.
Fix typo in pdf_print_obj.
|
|
If FZ_LARGEFILE is defined when building, MuPDF uses 64bit offsets
for files; this allows us to open streams larger than 2Gig.
The downsides to this are that:
* The xref entries are larger.
* All PDF ints are held as 64bit things rather than 32bit things
(to cope with /Prev entries, hint stream offsets etc).
* All file positions are stored as 64bits rather than 32.
The implementation works by detecting FZ_LARGEFILE. Some #ifdeffery
in fitz/system.h sets fz_off_t to either int or int64_t as appropriate,
and sets defines for fz_fopen, fz_fseek, fz_ftell etc as required.
These call the fseeko64 etc functions on linux (and so define
_LARGEFILE64_SOURCE) and the explicit 64bit functions on windows.
|
|
My recent changes to support %010Zd were broken in many interesting
ways. Fixed here.
|
|
Ensure that %010d works.
Ensure that we can output 64 bit values (%ll{d,u,x}).
Ensure that we can output size_t and fz_off_t (%z{d,u,x} and %Z{d,u,x}).
fz_off_t isn't defined yet (it will be introduced by a commit that
depends on this one), so for now, we put a stub definition in printf.c
that we will remove later.
|
|
|
|
The dtoa function is for doubles (which is what MuJS uses) but for MuPDF
we only need and want float precision in our output formatting.
|
|
|
|
|
|
Thanks to Triet Lai.
|
|
|
|
This fixes three instances of warning C4706, allows compilation with
VS2013 and prevents an accidental va_end for when va_end is defined
(which is the case for debug builds).
|
|
Stupid MSVC has no strtof.
|
|
%q escapes using C syntax and wraps the string in double quotes.
%( escapes using PS/PDF syntax and wraps the string in parens.
|
|
The primary motivator for this is so that we can print floating point
values and get the full accuracy out, without having to print 1.5 as
1.5000000, and without getting 23e24 etc.
We only support %c, %f, %d, %o, %x and %s currently.
We only support the zero padding qualifier, for integers.
We do support some extensions:
%C turns values >=128 into UTF-8.
%M prints a fz_matrix.
%R prints a fz_rect.
%P prints a fz_point.
We also implement a fprintf variant on top of this to allow for
consistent results when using fz_output.
a
|
