| Age | Commit message (Collapse) | Author |
|---|
|
Add API to:
* allow enumeration of layer configs (OCCDs) within PDF files.
* allow selection of layer configs.
* allow enumeration of the "UI" (or "Human readable") form of layer
configs.
* allow selection/toggling of entries in the UI.
|
|
|
|
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.
|
|
|
|
|
|
|
|
New Devanagari serif font, several other updated fonts.
|
|
The implementation does not need to be in the public API.
|
|
Move the definition of fz_font to be in a private header file
rather than in the public API. Add accessors for specific
parts of the structure and use them as appropriate.
The font flags, and the harfbuzz records remain public.
This means that only 3 files now need access to the font
implementation (font.c, pdf-font.c and pdf-type3.c). This
may be able to be improved further in future.
|
|
Part of the change in this code is to require opj_malloc
and co. Sadly, opj_malloc and co do not take a context field,
so a we need to wrap calls to openjpeg with a lock.
I am reusing the freetype lock here for simplicity.
|
|
|
|
Its output directory was set differently.
|
|
Not used, other than for the convenience of editing/searching.
|
|
|
|
|
|
These build the mupdf desktop java viewer.
|
|
generated.sh was broken (wrong font path).
load_pnm.c had been omitted from VS projects.
|
|
Import fonts from v1.004.
|
|
Allows testing of SUPPORT_GPROOF builds on windows.
|
|
Font names changed with the update of the base 14 fonts
to the latest release from URW. The project file
had to be updated with the new names. Also the Droid
font names had changed so generate.bat was updated.
|
|
A cutdown mudraw that only copes with simple raster output.
|
|
The fonts are now under the SIL Open Font License!
Converted with AFDKO tool 'tx': tx -cff +F +S +T -b -n -gx $EXCL -a *.t1
$EXCL is the list of PUA glyphs used by PCL that we don't need in mupdf.
The Dingbats and Symbol fonts have only been regenerated from the old version,
since there are no new glyphs (but several problems) in the newest version.
|
|
|
|
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.
|
|
Presumably because the files were hand edited before, and
MSVC likes to alphasort.
|
|
|
|
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.
|
|
|
|
Just a few places in the MSVC projects didn't have this enabled.
|
|
|
|
Use this for plotters so we can see which ones are being used
in any given build.
Build with -DTRACK_USAGE to enable.
|
|
Add some paranoid checks to pdf_graft_object to prevent user
errors from crashing mupdf.
|
|
Some new files hadn't been added to the solution, and we were
calling strcasecmp instead of fz_strcasecmp.
|
|
svg: Implement graphics state stack.
svg: Use idmap for symbol and use elements.
svg: Put viewport and viewBox in state stack.
svg: Rebase to version 1.9 master.
|
|
|
|
This commit adds a page merging tool. The tool demonstrates the
use of object grafting. The object grafting function recursively
goes through the object to add all referenced objects. A map is
maintained to ensure that objects that have already been copied are
not copied again.
|
|
|
|
Avoid library warnings when including libfonts.
|
|
I missed a font while reworking the generate.bat font generation.
|
|
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.
|
|
Also change unsigned char into const char for embedded data.
|
|
Simple PS wrapped images with flate compression.
|
|
To avoid having to duplicate a fairly large block of code several
times, use repeated inclusion of a header with some macros to
generate optimised glyph plotters.
|
|
Add Memento configurations for mupdf-gl and libglfw to solve
build warnings.
|
|
Required to find mujs.h
|
|
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.
|
|
Use an API similar to the JNI bindings.
|
