| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In particular ensure that curl builds properly for 32 and 64bit
modes.
|
|
No point in building libfonts in anything other than release
mode. It's just data. This avoids needless rebuilds in batch
builds.
|
|
No point in building the 'generated' tools in anything other
than debug mode. This avoids repeatedly building the same thing
in batch builds.
|
|
This will only be built in "DebugCommercial" "ReleaseCommercial" and
"MementoCommercial" configuration builds.
A note on the way MSVS solutions work; libluratech is listed as
a dependency of the executables - this applies to ALL configurations.
In order to stop normal builds failing when we have no source, we
set each non "Commercial" configuration to not build libluratech.
The linker still looks for the output from the libluratech stage
to link in though, so for all non "Commercial" configurations, we
have the libluratech stage set to produce output named " ". This
is copied into the linker command line, and all is happy.
The sole downside to this is that if we try to build libluratech
in "Debug" (say) rather than "DebugCommercial", the build will
fail at the library making step. This will never happen unless
we manually try to build that project in that configuration though.
|
|
These build the mupdf desktop java viewer.
|
|
Allows testing of SUPPORT_GPROOF builds on windows.
|
|
A cutdown mudraw that only copes with simple raster output.
|
|
Update libfonts build directory; this was causing many warnings
because the debugging information was being put in the wrong place.
Also ensure that libfonts is build for the different 64bit configs.
|
|
libfonts wasn't being generated in 64bit configs.
murun had the wrong include path in 64bit configs.
generated was being invoked wrongly in 64bit configs.
|
|
Avoid library warnings when including libfonts.
|
|
Update generate.bat to generate generate/fontname.c files rather
than generate/fontname.{ttc,ttf,cff} etc.
Add a new libfonts target that builds those, and make libmupdf
depend on it.
Fix build problem in load-bmp.c - don't declare in the middle of
blocks.
|
|
Add Memento configurations for mupdf-gl and libglfw to solve
build warnings.
|
|
The purpose of JNI bindings is to allow MuPDF to be driven from
Java. There are several possible use cases here.
Firstly, and most simply a java application can ask the core of MuPDF
to open a document and render it using the existing devices to
produce output on a standard Java bitmap.
Secondly, a java application might want to drive the device interface
itself, making use of the standard MuPDF devices (such as using the
rendering engine to render high quality graphics).
Thirdly, a java application might want to implement its own device
and then call MuPDF to run the document to that device (perhaps to do
custom text or image extraction).
The first of these cases requires a simple reflection of the main
document and standard device classes in JNI.
The second of these cases requires the actual device interface itself
to be made available as a java interface, together with the ability
to construct and manipulate data types like paths, text and fonts so
the Java code can build the required objects to pass to implementers
of the device interface.
The final case requires a reflection layer whereby calls through the
device interface in C can be turned into method calls to a Java
interface.
All of this is attempted in this commit. Some highlights:
For each type in the C (such as fz_colorspace) we have a corresponding
java class (such as ColorSpace).
Where the 'fz_' types are reference counted (such as an fz_colorspace),
the java objects (such as ColorSpace) simply take a reference to a
pointer to the underlying fz type. Java accessor methods are then
provided to manipulate these types.
Where the 'fz_' types are not reference counted (such as an fz_rect),
the data is actually contained within the Java object itself (such as
Rect, RectI and Transform).
We add a VS jni project. This doesn't do anything except make the
files accessible for editing in the IDE.
As much as possible, the Java layers do nothing (other than some
programmer friendly type overloading), construction (unavoidable,
as can't be done in JNI) and boiler-plate destruction. All the
smartness is done in the C.
Due to Java and C's differing approach to constness, we need to be
careful that a java device does not destructively alter objects
passed to it. For example, consider running a display list through
a device implemented in java. If the java device were to change a
Font object passed to it, this might affect other objects in the
display list that shared the same underlying fz_font.
Possibly we can achieve this by having an 'isConst' flag on java
objects that are created from device calls and passed to the Java
device (see the Text class, for an attempt at this currently).
This could alternatively be achieved by cloning every such
piece of data (see the path code for an example of this approach),
but this is probably slow. Better to clone 'just in time' as the
first write operation is done to the object.
|
|
Otherwise we can't run file generation tools with a 64-bit target
on a 32-bit host.
|
|
|
|
Add OpenGL text rendering using textured quads, instead of using glut bitmap fonts.
|
|
A few casts are required within the code, along with a few #ifdef
changes.
Some tweaks to curl are required too.
|
|
|
|
all plus more.
Includes xml, html, text save as, fix issues in window range that determines what
pages are visible at a particular scaling. Fix very tricky to find problem in
interface with gs. Managed code was freeing delegates that were allocated dynamically.
It is not possible to pin these so they are now member variables.
|
|
|
|
Lost as part of the accidental VS2012 change.
|
|
|
|
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.
|
|
Windows and X11. Allows files to be fetched and displayed
as they are downloaded both with and without linearization, using
hints if available.
|
|
|
|
|
