| Age | Commit message (Collapse) | Author |
|---|
|
This has been broken since fz_text was changed to be multiple
fz_text_spans.
|
|
Closing a device or writer may throw exceptions, but much of the
foreign language bindings (JNI and JS) depend on drop to never throw
an exception (exceptions in finalizers are bad).
|
|
Silly typo.
|
|
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.
|
|
fz_pixmaps now have an explicit stride value. By default no change
from before, but code all copes with extra gaps at the end of the
line.
The alpha data in fz_pixmaps is no longer compulsory.
mudraw: use rgb not rgba (ppmraw), cmyk not cmyka (pkmraw).
Update halftone code to not expect alpha plane.
Update PNG writing to cope with alpha less input.
Also hide repeated params within the png output context.
ARM code needs updating.
|
|
Split compressed images (images based on a compressed buffer)
and pixmap images (images based on a pixmap) out into separate
subclasses.
|
|
Update the core fz_get_pixmap_from_image code to allow fetching
a subarea of a pixmap. We pass in the required subarea, together
with the transformation matrix for the whole image.
On return, we have a pixmap at least as big as was requested,
and the transformation matrix is updated to map the supplied
area to the correct place on the screen.
The draw device is updated to use this as required. Everywhere
else passes NULLs in, and so gets unchanged behaviour.
The standard 'get_pixmap' function has been updated to decode
just the required areas of the bitmaps.
This means that banded rendering of pages will decode just the
image subareas that are required for each band, limiting the
memory use. The downside to this is that each band will redecode
the image again to extract just the section we want.
The image subareas are put into the fz_store in the same way
as full images. Currently image areas in the store are only
matched when they match exactly; subareas are not identified
as being able to use existing images.
|
|
Garbage collected languages need a way to signal that they are done
with a device other than freeing it.
Call it implicitly on fz_drop_device; so take care not to call it again
in case it has been explicitly called already.
|
|
|
|
The scissor argument is an optional (potentially NULL) rectangle
that can give hints to devices about the area that can be scissored.
This is used by the draw device and display list device to minimize
the size of temporary clip mask buffers.
The scissor rectangle, if used, must have been transformed by the
current transform matrix.
|
|
|
|
Image objects are immutable and opaque once constructed.
Therefore there is no need for the const keyword.
|
|
Shading objects are immutable and opaque once constructed.
Therefore there is no need for the const keyword.
|
|
It's an opaque immutable structure, that we don't expect to ever want
to change after creation. Therefore the const keyword is not useful,
and is only line noise.
|
|
In general, we should use 'const fz_blah' in device calls whenever
the callee should not alter the fz_blah.
Push this through. This shows up various places where we fz_keep
and fz_drop these const things.
I've updated the fz_keep and fz_drops with appropriate casts
to remove the consts. We may need to do the union dance to avoid
the consts for some compilers, but will only do that if required.
I think this is nicer overall, even allowing for the const<->no const
problems.
|
|
|
|
We can now group all clipped text into one fz_text object and simplify
the device interface.
|
|
|
|
Firstly, we make the definition of the path structures local to
path.c. This is achieved by using an fz_path_processor function to
step through paths enumerating each section using callback functions.
Next, we extend the internal path representation to include other
section types, including quads, beziers with common control points
rectangles, horizontal, vertical and degenerate lines. We also roll
close path sections up into the previous sections commands.
The hairiest part of this is that fz_transform_path has to cope with
changing the path commands depending on the matrix. This is a
relatively rare operation though.
|
|
|
|
|
|
Purge several embedded contexts:
Remove embedded context in fz_output.
Remove embedded context in fz_stream.
Remove embedded context in fz_device.
Remove fz_rebind_stream (since it is no longer necessary).
Remove embedded context in svg_device.
Remove embedded context in XML parser.
Add ctx argument to fz_document functions.
Remove embedded context in fz_document.
Remove embedded context in pdf_document.
Remove embedded context in pdf_obj.
Make fz_page independent of fz_document in the interface.
We shouldn't need to pass the document to all functions handling a page.
If a page is tied to the source document, it's redundant; otherwise it's
just pointless.
Fix reference counting oddity in fz_new_image_from_pixmap.
|
|
Rename fz_close to fz_drop_stream.
Rename fz_close_archive to fz_drop_archive.
Rename fz_close_output to fz_drop_output.
Rename fz_free_* to fz_drop_*.
Rename pdf_free_* to pdf_drop_*.
Rename xps_free_* to xps_drop_*.
|
|
|
|
Luiz Henrique de Figueiredo reports that glyphs output from the
SVG device contain 'lumpy' outlines. Investigation reveals that
this is because the current code extracts the outlines from
freetype at unit scale, and then relies on SVG to scale them up.
Unfortunately, freetype insists on working in integer maths, so
any sort of scaling runs the risk of distorting the outlines.
The fix is to change the way we call freetype; we now request an
'UNSCALED' char, and set the required size to be the design size.
We then transform the results in the floating point domain
ourself.
This cures the lumpy outlines, but reveals a second problem,
namely that the bbox given for characters is inaccurate (and
sometimes too small). Investigation shows that this is again
caused by freetypes scaling, so we apply the same trick; ask
for the glyph without scaling (as far as possible), and then
scale the results down.
We also take care to spot the 'ft_hint' flag in the font. If set
this indicates that hinting must be performed to ensure that
the returned outlines are sane. We therefore take note of this
when calculating both bbox and outlines. This means that 'tricky'
fonts such as dynalab ones now render correctly.
This produces many changes in the bitmaps, the vast majority of which
are neutral. The ones that aren't are all progressions.
|
|
Some warnings we'd like to enable for MuPDF and still be able to
compile it with warnings as errors using MSVC (2008 to 2013):
* C4115: 'timeval' : named type definition in parentheses
* C4204: nonstandard extension used : non-constant aggregate initializer
* C4295: 'hex' : array is too small to include a terminating null character
* C4389: '==' : signed/unsigned mismatch
* C4702: unreachable code
* C4706: assignment within conditional expression
Also, globally disable C4701 which is frequently caused by MSVC not
being able to correctly figure out fz_try/fz_catch code flow.
And don't define isnan for VS2013 and later where that's no longer needed.
|
|
The SVG device needs rebinding as it holds a file. The PDF device needs
to rebind the underlying pdf document.
All documents need to rebind their underlying streams.
|
|
|
|
While looking at fts_09_0921, I spotted that the alpha values on images
and fills aren't being sent. Fix that here, together with broken colors
being sent for masks.
fts_09_0921 still renders badly due to the lack of support for blend
modes.
|
|
The luminosity flag and background color are currently ignored.
The clip stack optionally held in the null device is updated here to
be a container stack, together with a flags word (currently just used
to indicate the type of the container at the current place in the
stack), and a user value (used by the SVG device to stash the id for
the mask it's generating).
|
|
Really just a structure indicator as SVG 1.1 doesn't support
blending etc.
|
|
fts_09_0919.pdf shows up some silly mistakes in the clip stack handling
and in the handling of 0 sized pixmaps. Simple fixes.
|
|
A gradient fill that doesn't fill the bbox should be see through
(unless background color is set, but we'll worry about that case
when I find an example file that uses it). Arrange for the pixmap
we draw the gradient fill into to be transparent initially.
Also ensure that when we convert to png we preserve transparency.
|
|
|
|
|
|
This accompanies the function formerly known as fz_image_as_png (now
renamed to fz_new_png_from_image).
|
|
|
|
|
|
|
|
|
|
In particular, cope with the cases where xstep/ystep are not the same
as the tile width/heights.
|
|
Thanks to Tor for finding the correct definitions for me.
|
|
Images were missing a space, hence giving errors.
SVG text gets confused by leading (and repeated) whitespace, so elide it.
|
|
|
