| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
When putting store objects into the store, ensure that they do cannot
collide across documents.
|
|
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).
|
|
If the appropriate device hint is set, the null device will keep
a scissor stack. This saves duplicating code in every device.
|
|
This accompanies the function formerly known as fz_image_as_png (now
renamed to fz_new_png_from_image).
|
|
|
|
Set the hint in mudraw when AA bits is set to 0.
|
|
The bug fix added in the previous commit fails to work in this
case (hang-9527.pdf) because the matrix is not invertible and
hence the clipping rectangle ends up infinite. Spot this case
here and return early.
|
|
SumatraPDF's testsuite uses Targa images as output because they're
compressed while still far easier to compare than PNG and have better
tool support than PCL/PWG.
|
|
* Destination names are a name and not a string
* Expose whether a /Launch action points to a path or a URI
|
|
For Separation and DeviceN colorspaces, the initial color value is 1.0
for all components instead of 0.0 as for most other colorspaces. The
current initialization in pdf_set_colorspace initializes for CMYK which
happens to work for all non-tint colorspaces.
|
|
Thanks to Zaister for reporting this.
|
|
The pdf_ versions were already correct. Probably just an
oversight that this was missed.
|
|
This is required e.g. for 2314 - jpeg tables in tiff.xps.
This folds fz_open_resized_dct back into fz_open_dct instead of adding
further variations for calls with and without the jpegtables argument.
|
|
|
|
|
|
Pull subpixel glyph adjustment calculations into fz_subpixel_adjust.
This reduces the repetition of code, and will be helpful for the
OpenGL device.
|
|
These do no caching, and are intended to be useful for the opengl device.
|
|
For large glyphs, sub pixel positioning is supremely unimportant.
Even for smaller glyphs, we don't need 5*5 possible sub pixel
positions. Base the degree of sub pixel quantisation on the size
of the glyphs.
This should result in better cache use.
We push all the glyph sub positioning logic into fz_render_glyph
(and fz_render_stroked_glyph). This simplifies the calling code.
We also tweak fz_render_glyph so that it updates the transform it
is called with to reflect the sub pixel positioning. This solves
various problems: Firstly, we can round positions both up and down
to achieve a smaller net displacement (e.g. (0.99, 0.99) can go
to (1,1) rather than (0.75, 0.75) if we have a subpixel position
resolution of 1/4 pixels).
Secondly, glyphs that are drawn from outlines will have exactly the
same subpixel changes applied. This is unlikely to be noticable, but
it does mean that baselines should avoid having any shifts in them.
Finally, it enables us to avoid lots of unnecessary copying of
matrices, hopefully reducing overhead.
|
|
Rather than generating fz_pixmaps for glyphs, we generate fz_glyphs.
fz_glyphs can either contain a pixmap, or an RLEd representation
(if it's a mask, and it's smaller).
Should take less memory in the cache, and should be faster to plot.
|
|
The most complex part here is to ensure that we can output various
bitmaps in bands.
|
|
fz_putc; this fills a hole in our fz_output functions.
fz_new_output_to_filename: This saves people having to create
a FILE * just to pass to fz_new_output_with_file and then having
to remember to close the FILE *.
|
|
|
|
This fixes among others 693274 - cmyk jpeg image.xps from bug 693274.
|
|
|
|
|
|
|
|
Previously there was a bug when parsing GoToR link annotations that had
a named destination. mupdf incorrectly attempted to resolve the
destination in the current document. Now the destination name is
present in the link objects returned to the application so it can
resolve any names for GoToR links in the remote document instead.
|
|
|
|
Use of the feature is currently enabled only in the case that a file
that already contains xref streams is being updated incrementally. To
do so in that case is necessary because an old-style xref is then not
permitted.
This fixes bug #694527
|
|
|
|
|
|
|
|
|
|
This initial commit doesn't entirely complete the task:
1) There are a couple of ucs<->winansi conversions left out,
2) The text displayed by the appearance string can slightly
overflow the annotation rectangle.
|
|
|
|
We are testing this using a new -p flag to mupdf that sets a bitrate at
which data will appear to arrive progressively as time goes on. For
example:
mupdf -p 102400 pdf_reference17.pdf
Details of the scheme used here are presented in docs/progressive.txt
|
|
No more caching a flattened page tree in doc->page_objs/refs.
No more flattening of page resources, rotation and boxes.
Smart page number lookup by following Parent links.
Naive implementation of insert and delet page that doesn't rebalance the trees.
Requires existing page tree to hook into, cannot be used to create a page tree
from scratch.
|
|
|
|
Annotations can sometimes not have appearance streams (such as
Links). Avoid spewing messages to the console about this. Also
avoids overhead of throw/catch each time.
|
|
|
|
|
|
Thanks to zeniko for spotting the problem here.
Type 3 fonts contain a reference to the resources objects required
to render the glyphs. Traditionally these have been freed when the
font is freed. Unfortunately, after recent changes, freeing a PDF
object requires the pdf_document concerned to still exist.
While in most cases the type 3 resources are not used after we have
converted the type3 glyphs to display lists, this is not always the
case. For uncachable Type 3 glyphs (such as those that do not
completely define elements in the graphics state that they use, such
as color or line width), we end up running the glyphs at interpretation
time.
[ Interpretation time = when doing a direct render on the main thread,
or when creating a display list - so also on the main thread. No
multi-threading issues with file access here. ]
The fix implemented here is for each pdf document to keep a list of
the type3 fonts it has created, and to 'decouple' them from the
document when the document is destroyed. The sole effect of this
decoupling is to remove the resources (and the PDF operator buffers)
from the font. These are only ever used during interpretation, and
no further interpretations are possible without the document being
alive anyway, so this should have no net effect on operation, other
than allowing cleanup to proceed cleanly later on.
|
|
Also add index argument to array_insert.
|
|
|
|
We need to have it as a prefix, not a postfix now, but it should
work on both gcc and MSVC now.
|
|
Correct the naming scheme for pdf_obj_xxx functions.
|
|
|
|
Before we render a page we need to evaluate whether we need
transparency or not. To establish this, we recursively walk the
resources looking for certain markers (blend modes, alpha levels,
smasks etc). To avoid doing this repeatedly we'd like to stash
the results somewhere.
Currently we write a '.useBM' entry into the top level dictionary
object, but with the recent changes to support incremental update
this is not ideal - it has the effect of forcing all resources
into the new section of the xref.
So we avoid that horrible hack and use a different one; we make use
of the new flags word in the pdf_obj structure. 1 bit is used to
indicate whether we have stashed a (boolean) value here, and another
bit is used to indicate what that value was.
|
