Age | Commit message (Collapse) | Author |
|
Slightly revised blending, making use of the fact that we can
no longer overflow due to ma + masa <= 0x100.
|
|
As part of the blending calculations, we do:
dst = src * mask_alpha + dst * (1-mask_alpha.src_alpha)
We calculate mask_alpha as ma, and 1-mask_alpha.src_alpha as masa.
In full accuracy, we should never have ma + masa >= 1.
Unfortunately, with the formulation used in the painters at the
moment, we can. We therefore rejig the calculations slightly.
|
|
Better name as not all shadings are meshes.
|
|
|
|
|
|
|
|
The stream loading is used only by the JS code loading.
|
|
|
|
|
|
Use a flag in the pdf_annot struct instead.
Don't pass pdf_document to annotation edit functions.
|
|
The implementation does not need to be in the public API.
|
|
|
|
The fz_font structure now doesn't know anything about
harfbuzz at all, it merely offers an abstract
'fz_shaper_data_t' entry.
|
|
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.
|
|
|
|
|
|
Put them in the PDF name space and separate words with underscores.
Remove redundant namespace prefixes in java constants.
Device.FLAG_MASK rather than Device.FZ_DEVFLAG_MASK.
Use namespace for PDF annotation flag enum.
|
|
A PDF repair can be triggered 'just in time', when we encounter
a problem in the file. The idea is that this can happen without
the enclosing code being aware of it.
Thus the enclosing code may be holding 'borrowed' references
(such as those returned by pdf_dict_get()) at the time when the
repair is triggered. We are therefore at pains to ensure that
the repair does not replace any objects that exist already, so
that the calling code will not have these references unexpectedly
invalidated.
The sole exception to this is when we replace the 'Length' fields
in stream dictionaries with the actual lengths. Bug 697015 shows
exactly this situation causing a reference to become invalid.
The solution implemented here is to add an 'orphan list' to the
document, where we put these (hopefully few, small) objects. These
orphans are kept around until the document is closed.
|
|
Including: Bug 697134: Tweak MEMENTO_GS_HACKS inclusion.
Rather than rolling our own memset prototype in this case, use
the one that gs provides.
And, bug 697133: Fix typo in Memento.
Causing a significant slowdown. Thanks to George Burgess IV
for spotting this.
|
|
A few commits back, we introduced the fz_key_storable concept
to allow us to cope with objects that were used both as values
within the store and as parts of keys within the store.
This commit worked, but showed up performance problems; when the
store has several million PDF objects in it, bulk changes (such
as dropping a display list or document) could trigger many passes
across the store.
We therefore introduce a mechanism to ameliorate this. These
passes, now known as "reap passes", can be batched together using
fz_defer_reap_start and fz_defer_reap_end.
We trigger this start/end around display list dropping, and around
PDF content stream processing. This should be fine, as deferral
will be interrupted if we ever run our of memory during mallocing.
|
|
|
|
|
|
When we destroy a PDF document, currently we bin everything
from the store. Instead, drop just the objects that are
specifically tied to that document.
Any object tied to the document has a pdf_obj with the
required document pointer in it as the key.
|
|
The store is effectively a list of items, where each item is a
(key, value) pair. The design is such that we can easily get
into the state where the only reference to a value is that held
by the store. Subsequent references can then be generated by
things being 'found' from within the store.
While the only reference to an object is that held by it being
a value in the store, the store is free to evict it to save
memory.
Images present a complication to this design; images are stored
both as values within the store (by the pdf agent, so that we
do not regenerate images each time we meet them in the file),
and as parts of the keys within the store.
For example, once an image is decoded to give a pixmap, the
pixmap is cached in the store. The key to look that pixmap up
again includes a reference to the image from which the pixmap
was generated.
This means, that for document handlers such as gproof that do
not place images in the store, we can end up with images that
are kept around purely by dint of being used as references in
store keys. There is no chance of the value (the decoded pixmap)
ever being 'found' from the store as no one other than the
key is holding a reference to the image required. Thus the
images/pixmaps are never freed until the store is emptied.
This commit offers a fix for this situation.
Standard store items are based on an fz_storable type. Here we
introduce a new fz_key_storable type derived from that. As well
as keeping track of the number of references a given item has
to it, it keeps a separate count of the number of references a
given item has to it from keys in the store.
On dropping a reference, we check to see if the number of
references has become the same as the number of references from
keys in the store. If it has, then we know that these keys can
never be 'found' again. So we filter them out of the store,
which drops the items.
|
|
This makes debugging much simpler.
|
|
|
|
Add backtrace abilities, and fix missing return value from
android logging.
|
|
The upshot of debugging this is that:
1) We can't trust the FontBBox. Certainly it appears that no
one else trusts it.
2) We can't trust the d1 values in all cases, as it can lead to
use rendering glyphs far larger than we'd want to.
So we have the compromise used here.
1) We never clip to the FontBBox.
2) If the FontBBox is invalid, then we calculate the bbox
from the contents of the data streams.
3) If the FontBBox is valid, and the d1 rectangle given
does not fit inside it, then we calculate the bbox from
the contents of the data streams.
This could theoretically produce problems with glyphs that have
much more content than they actually need, and rely on the d1
rect to clip it down to sanity. If the FontBBox is invalid in
such fonts, we will go wrong.
It's not clear to me that this will actually work in Acrobat/
Foxit/gs etc either, so we defer handling this better until we
actually have an example.
Tested with bug 694952, and bug 695843 which were the last 2 in
this area.
|
|
Windows requires sys/stat.h to be included.
|
|
|
|
|
|
|
|
Previously it was inherently tied to zip archives and directories.
Now these are separated out into distinct subclasses. This prepares
for support for further archive formats.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The type3 font(s) in the file have an invalid (0 sized) bbox, hence
the clipping of the chars goes wrong.
We now spot the invalid bbox, and suppress the clipping.
|
|
|
|
Since the removal of the begin_page device function, structured
text extraction has been unable to correctly establish the
mediabox for extracted pages.
Update the fz_new_stext_page call to take this mediabox
information. This is an API change, but hopefully most people
are calling fz_new_stext_page_from_page or
fz_new_stext_page_from_display_list which are updated here to
cope.
Update all the apps/tools to behave properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|