| Age | Commit message (Collapse) | Author |
|---|
|
We were converting from a File to a filename then to a Uri
using Uri.parse, but Uri.parse has problems with hash marks.
Instead convert direct from File to Uri.
|
|
"Defined but not used" and "Set but not used" as seen with
ndk-build.
|
|
Add code to convert to and from fz_text_language codes from
ISO 639 language strings. No validation is carried out.
|
|
We move to using bidirectional "levels" throughout. This should
give us better behaviour vis-a-vis nested l2r/l2r text. This
also allows us to carry xps levels throughout with no loss of
information.
This also avoids the need to special case numbers.
We accordingly carry more information into fz_text.
As well as wmode, also hold additional details about the text spans.
We now include the directionality of the bidi level text (either as
derived from bidi code, or from the original document (e.g. xps)),
the directionality of text (as specified in the original document
(e.g. html)), and the language of the text (if specified in the
original document).
|
|
|
|
|
|
|
|
|
|
Add Memento configurations for mupdf-gl and libglfw to solve
build warnings.
|
|
If built with MEMENTO_DETAILS (on by default), we store the
backtrace on every event that affects a block.
Memento_details(address) will display the events that affected
a block (typically malloc, {realloc}*, free), including the
backtrace at each point.
Windows and linux use different mechanisms for this. Windows
loads a DLL and calls windows specific functions - no extra
libraries are required.
Linux also loads a shared object (libbacktrace.so). This is not
present on all platforms, so on platforms where it is not available
we just get addresses. These can be converted using addr2line
(unless ASLR is enabled).
In order for linux to be able to load libbacktrace.so we link in
libdl. If this is not available, define HAVE_LIBDL=no when building
the memento target.
|
|
Add Memento_info(address) that will show the details of a block
(callstacks when it was allocatd, realloced, freed etc).
This works on MSVC and GNUC using two different methods.
|
|
Avoid searching the linked list of blocks in order to remove a
block by moving to a doubly linked list. This can be done
without increasing the amount of memory in use by making better
use of the 'parent' pointer that is only used when displaying
nested blocks.
Also store magic values in the 'child' and 'sibling' pointers
(again only used when displaying nested blocks) so that we
can quickly verify that a block is real before doing too much
with it.
Those changes drastically reduce the time required for
MEMENTO_LEAKONLY runs (now the same order of magnitude as non
memento runs).
Normal memento runs are still very slow when the numbers of
blocks increase due to the paranoid checking taking time.
To ameliorate this a bit, we try 2 other things.
Firstly, we optimise the searching of blocks by making use of
int aligned tests. This still doesn't make much difference.
Secondly, we introduce a new mechanism for the 'paranoia'
levels. If a negative number is given for the paranoia level
(say -n) then we first perform our overwrite checks after n events.
We next test after 2n events, then 4n, then 8n etc.
The new default paranoia level is set to be -1024.
This makes a huge difference, and brings normal memento runs
down to be comparable with debug runs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don't bale on the first 'large enough' match.
|
|
Guess paper sizes from bitmap dimensions unless the paper
size has been specified. If unknown, depending on the
properties of the printer, we'll either send a 'custom'
paper size (followed by the page size in decipoints), or
the next size up.
Depending on the capabilities of the printer, we can
optionally send orientation too.
|
|
|
|
Required to find mujs.h
|
|
We no longer need to take the freetype lock here.
We also never read the value assigned to face earlier in the
routine, so remove that too.
|
|
Arrange to keep only the Outline entries that still refer to
valid pages.
More specifically, leaf outline entries that refer to pages that
are elided are not dropped. Non leaf outline entries that refer
to pages that have been elided are kept (for the sake of the
children) but have NULL destinations.
|
|
|
|
|
|
|
|
|
|
jni: Various cleanups.
Fix gcc and clang warnings.
Android specific functions are guarded by HAVE_ANDROID define.
The java guts of the android stuff is removed for now, to be added back in later.
Set up a makefile and simple tests to build for desktop java.
Rerig device classes to: Device, NativeDevice, JavaDevice and DrawDevice.
Add Pixmap class.
Regularize naming.
General cleanups and abbreviate naming.
Use to_JavaClass and from_JavaClass rather than
fz_mupdf_struct_from_JavaClass and JavaClass_from_fz_mupdf_struct.
Check for exceptions thrown by java devices and path processor.
Tweak constructors and finalizers to remove the JavaDevice subclass.
Use toString when rethrowing java exceptions as fitz exceptions.
|
|
|
|
Move the platform independent java code from platform/android to
platform/java.
The plan is that we can call 'make mupdf.jar' (or 'nmake mupdf.jar')
there, and then use the resultant mupdf.jar/mupdf_native.h files in
whatever platform specific project (such as the android bindings) we
like.
Keep the android specific class (AndroidDrawDevice) in the
usual place in platform/android.
Update the android ant script to include mupdf.jar.
|
|
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 image.getWidth() rather than image.width property access
to match JNI interface.
|
|
Use an API similar to the JNI bindings.
|
|
|
|
Don't mess with Td.
|
|
|
|
Don't try creating the resource for each fill_text call.
|
|
Only allocate one scratch buffer, and no larger than it needs to be.
Detect and warn when we can't create a ToUnicode CMap.
|
|
With an identity encoding, the glyph indices are the character codes.
|
|
|
