Age | Commit message (Collapse) | Author |
|
This patch fixes a possibility that an owned CPDF_Stream is handed to the
indirect object holder inside RealizeResource(). Its arguments are
changed to take an object number, as is done elsewhere in the code, to
suggest that only indirect objects are acceptable.
BUG=660756
Review-Url: https://codereview.chromium.org/2489423002
|
|
Currently, only RemoveRef() is being called when releasing. The problem
is that when the object is no longer being used, the map is not updated
accordingly. In the pdf in the bug below, the pointer of a font used in
the second page coincides with the pointer of a font in the first page
(that was released). So the cached values for the font in the first
page are used, resulting in incorrect rendering.
BUG=pdfium:629
Review-Url: https://codereview.chromium.org/2501053002
|
|
Previously the log just made sure the colorspace and the image have
exact matches for the number of colorspace components. Now, for some
colorspace types, check the type and make sure the number of
components meets or exceeds what is required by the spec.
Also do some refactoring.
BUG=chromium:650230
Review-Url: https://codereview.chromium.org/2486123002
|
|
Adds a test to process an image for which a stream hasn't been
set.
BUG=660756
Review-Url: https://codereview.chromium.org/2494683007
|
|
For the first page in linearized PDFs, it is not necessary to load the
main xref table, because it have separate special xref table in the file
header.
This decreasing the time to show first page in PDF plugin.
Review-Url: https://codereview.chromium.org/2483633002
|
|
In some PDF's the page may not have the obj num.
For example: testing\corpus\fx\other\jetman_std.pdf in pdfium repository.
And CPDF_Document::GetPage failed on second call for this page.
Restart the traversing of pages, to fix this
Also added test.
Review-Url: https://codereview.chromium.org/2491583002
|
|
Because that's what clone does. There are numerous
release() calls that will go away as more code is
converted.
Review-Url: https://codereview.chromium.org/2484033002
|
|
Review-Url: https://codereview.chromium.org/2482273002
|
|
Otherwise, we might be silently doing an unsafe cast before
applying the check if the actual argument doesn't match the
exact src type.
Review-Url: https://codereview.chromium.org/2484953003
|
|
Follow-up from ParseIndirectObject() CL. This will get
cleaner once CPDF_Object::Clone itself returns unique_ptrs.
Pack some bools together while we're at it.
Review-Url: https://codereview.chromium.org/2479353002
|
|
In turn, propgate to callers. This introduces a few
release() calls that will go away as more code is converted.
It also removes a couple of WrapUnique calls that are no
longer needed as ownership of the object flows along.
Review-Url: https://codereview.chromium.org/2479303002
|
|
My OCD insists that classes be named after nouns, and "linearized"
feels like an adjective.
Remove a redundant "if" while at it.
Review-Url: https://codereview.chromium.org/2482973002
|
|
- The code in fpdf_page_parser is only called by CPDF_StreamContentParser, so moved there.
- Split fpdf_page_parser_old into its two classes
- Renamed the corresponding unittests accordingly.
- Moved PDF_ReplaceAbbr to namespace
- Fixed few nits
- Added TODO because CPDF_StreamParser has a lot of code similar to CPDF_SyntaxParser
Review-Url: https://codereview.chromium.org/2474303003
|
|
Unify some code
Move parsing of linearized header into separate CPDF_Linearized class.
Original review:
https://codereview.chromium.org/2466023002/
Revert review:
https://codereview.chromium.org/2474283005/
Revert reason was:
Breaking the chrome roll.
See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856
___
Added Fix for fuzzers.
Review-Url: https://codereview.chromium.org/2477213003
|
|
https://codereview.chromium.org/2466023002/ )
Reason for revert:
Breaking the chrome roll. See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856
Original issue's description:
> Unify some code
>
> Move parsing of linearized header into separate CPDF_Linearized class.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/71333dc57ac7e4cf7963c83333730b3882ab371f
TBR=thestig@chromium.org,brucedawson@chromium.org,art-snake@yandex-team.ru
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2474283005
|
|
Move parsing of linearized header into separate CPDF_Linearized class.
Review-Url: https://codereview.chromium.org/2466023002
|
|
Review-Url: https://codereview.chromium.org/2477003002
|
|
Review-Url: https://codereview.chromium.org/2471263005
|
|
Now, we do not start traversal from where we were at, but from the top.
This makes the code less prone to bugs, as now there is no need to call
methods to recursively fix things. This will save a lot of time when
the trees are rather flat, as in the PDF file in the bug. It can still
be slow, for instance if we have a chain of page nodes, and the last
in the chain contains all of the pages (this is artificial).
Try 2 at https://codereview.chromium.org/2442403002/
Also added test where Try 2 would have failed.
Tested the pdf from the bug on my Mac:
With this CL: load in 21 seconds
Without this CL: did not load in 4 minutes, got tired of waiting
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2470803003
|
|
This reverts commit f0d5b6c35fa343108a3ab7a25bc2cc2b3cf105b3.
Review-Url: https://codereview.chromium.org/2478303002
|
|
Removes a path where it might not have taken ownership of an object,
at the expense of making callers check first. This eases making
the second argument an unique_ptr someday.
Review-Url: https://codereview.chromium.org/2475823002
|
|
#11 id:200001 of https://codereview.chromium.org/2384883003/ )
Reason for revert:
Looks like it's blocking the roll.
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/186619
Original issue's description:
> Remove CPDF_Object::Release() in favor of direct delete
>
> Follow-on once we prove Release always deletes in previous CL.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/4de3d095c9d9e961f93750cf1ebd489fd515be12
TBR=thestig@chromium.org,tsepez@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2478253002
|
|
Follow-on once we prove Release always deletes in previous CL.
Review-Url: https://codereview.chromium.org/2384883003
|
|
- Added a private method to read a character.
- Added enum for parsing status.
- Deleted unused method.
Review-Url: https://codereview.chromium.org/2469833002
|
|
Making the insert methods private allows us to use private members, as I
will need on https://codereview.chromium.org/2470803003/
Review-Url: https://codereview.chromium.org/2472473005
|
|
Review-Url: https://codereview.chromium.org/2477443002
|
|
AES256_CheckPassword() leaks memory on failure.
Clean up some nits.
BUG=chromium:659468
Review-Url: https://codereview.chromium.org/2463183002
|
|
When linearized document have hint table,
The FPDFAvail_IsPageAvail return true,
but FPDF_LoadPage return nullptr, for non first pages.
This happens, bacause document not use hint tables, to load page.
To fix this, I force save the page's ObjNum in document.
This is restoring of original fix:
https://codereview.chromium.org/2437773003/
Review-Url: https://codereview.chromium.org/2444903002
|
|
#3 id:40001 of https://codereview.chromium.org/2442403002/ )
Reason for revert:
Not quite right yet.
Original issue's description:
> Traverse PDF page tree only once in CPDF_Document
>
> Try 2: main fix was recursively popping elements from the stack. Since
> the Traverse method can be called on non-root nodes from GetPage(), we
> have to make sure to properly update the parents.
>
> Try 1 at https://codereview.chromium.org/2414423002/
>
> In our current implementation of CPDF_Document::GetPage, we traverse
> the PDF page tree until we find the index we are looking for. This is
> slow when we do calls GetPage(0), GetPage(1), ... since in this case
> the page tree will be traversed n times if there are n pages. This CL
> makes sure the page tree is only traversed once.
>
> Time to load the PDF from the bug below in chrome official build:
> Before this CL: around 1 minute 25 seconds
> After this CL: around 4 seconds
>
> BUG=chromium:638513
>
> Committed: https://pdfium.googlesource.com/pdfium/+/d3a2009d75eac3cda442f545ef0865afae7b35cf
TBR=tsepez@chromium.org,weili@chromium.org,thestig@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2461063003
|
|
TransferBitmap seems to work improperly when the glyph boxes overlap.
In particular, after drawing a glyph, the next glyph's blanks will
override what the previous glyph drew, and this is not the correct
behavior. While on it, use CheckedNumeric to do operations safely.
For reference of somewhere where something similar is done, see:
https://cs.chromium.org/chromium/src/third_party/pdfium/core/fxge/ge/cfx_renderdevice.cpp?sq=package:chromium&rcl=1477581616&l=988
BUG=513954
Review-Url: https://codereview.chromium.org/2461743002
|
|
Review-Url: https://codereview.chromium.org/2450183003
|
|
Review-Url: https://codereview.chromium.org/2453163002
|
|
Try 2: main fix was recursively popping elements from the stack. Since
the Traverse method can be called on non-root nodes from GetPage(), we
have to make sure to properly update the parents.
Try 1 at https://codereview.chromium.org/2414423002/
In our current implementation of CPDF_Document::GetPage, we traverse
the PDF page tree until we find the index we are looking for. This is
slow when we do calls GetPage(0), GetPage(1), ... since in this case
the page tree will be traversed n times if there are n pages. This CL
makes sure the page tree is only traversed once.
Time to load the PDF from the bug below in chrome official build:
Before this CL: around 1 minute 25 seconds
After this CL: around 4 seconds
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2442403002
|
|
Found by winxfa bot when fx_bool defined to bool.
Review-Url: https://codereview.chromium.org/2449293002
|
|
It's been troubling for some time that an IFX_FileStream might
actually be an in-memory buffer with no backing file.
Review-Url: https://codereview.chromium.org/2443723002
|
|
The CPDF_Document does not own its root dictionary, so add ownership in
CPDF_TestDocumentForPages, using ReleaseDeleter because the dictionary
cannot be deleted.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/2445753002 .
|
|
Added a nontrivial page tree and a test that pages are being fetched
properly, both when requested in order and in reverse order. This will
help prevent introducing bugs while changing the way the page tree is
processed.
BUG=chromium:638513
Review-Url: https://chromiumcodereview.appspot.com/2435783006
|
|
Review-Url: https://chromiumcodereview.appspot.com/2424933002
|
|
https://codereview.chromium.org/2437773003/ )
Reason for revert:
CPDF_DataAvail::IsPageAvail is causing crashes.
BUG=chromium:658168, chromium:658170
Original issue's description:
> Fix loading page using hint tables.
>
> When linearized document have hint table,
> The FPDFAvail_IsPageAvail return true, but
> FPDF_LoadPage return nullptr, for non first pages.
>
> This happens, bacause document not use hint tables, to load page.
>
> To fix this, I force save the page's ObjNum in document.
>
> R=npm, dsinclair
>
> Committed: https://pdfium.googlesource.com/pdfium/+/ef38283688c1ee7c08bcf4204cfb78e09c039782
TBR=dsinclair@chromium.org,tsepez@chromium.org,thestig@chromium.org,art-snake@yandex-team.ru
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://chromiumcodereview.appspot.com/2442663005
|
|
When linearized document have hint table,
The FPDFAvail_IsPageAvail return true, but
FPDF_LoadPage return nullptr, for non first pages.
This happens, bacause document not use hint tables, to load page.
To fix this, I force save the page's ObjNum in document.
R=npm, dsinclair
Review-Url: https://chromiumcodereview.appspot.com/2437773003
|
|
id:60001 of https://codereview.chromium.org/2414423002/ )
Reason for revert:
Possible cause of crbug.com/657897 reverting to find out.
BUG=657897
Original issue's description:
> Traverse PDF page tree only once in CPDF_Document
>
> In our current implementation of CPDF_Document::GetPage, we traverse
> the PDF page tree until we find the index we are looking for. This is
> slow when we do calls GetPage(0), GetPage(1), ... since in this case
> the page tree will be traversed n times if there are n pages. This CL
> makes sure the page tree is only traversed once.
>
> Time to load the PDF from the bug below in chrome official build:
> Before this CL: 1 minute 40 seconds
> After this CL: 5 seconds
>
> BUG=chromium:638513
>
> Committed: https://pdfium.googlesource.com/pdfium/+/7c29e27dae139a205755c1a29b7f3ac8b36ec0da
TBR=thestig@chromium.org,tsepez@chromium.org,npm@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:638513
Review-Url: https://chromiumcodereview.appspot.com/2430313006
|
|
This Cl merges the implementation classes up into the IFWL classes as the
intermediate classes were just acting as proxies.
Review-Url: https://chromiumcodereview.appspot.com/2432423002
|
|
In our current implementation of CPDF_Document::GetPage, we traverse
the PDF page tree until we find the index we are looking for. This is
slow when we do calls GetPage(0), GetPage(1), ... since in this case
the page tree will be traversed n times if there are n pages. This CL
makes sure the page tree is only traversed once.
Time to load the PDF from the bug below in chrome official build:
Before this CL: 1 minute 40 seconds
After this CL: 5 seconds
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2414423002
|
|
The assumption that only indirect objects would be passed is wrong.
Restore old behaviour despite muddying ownership constraints.
R=thestig@chromium.org
BUG=656145
Review-Url: https://codereview.chromium.org/2425843002
|
|
Avoid confusing this class with other ref-counted objects.
Review-Url: https://codereview.chromium.org/2426673002
|
|
This reverts commit 1d023881cd53485303c0fcc0b5878e700dc470fd.
Reason for revert -- fuzzers hit issues.
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2425783002
|
|
This reverts commit 3ba098595ae56b64eacc0c25ab76b89a4d78d920.
TBR=thestig@chromium.org,weili@chromium.org
Review URL: https://codereview.chromium.org/2424533003 .
|
|
Doing so highlights a few places where ownership is dubious.
Add convenience functions to return an unowned reference to
a newly-created indirect object.
Review-Url: https://codereview.chromium.org/2419173002
|
|
This tweaks the implementation while leaving the API the
same. The API change is more disruptive, so break this
part off first.
Review-Url: https://codereview.chromium.org/2385293002
|
|
Also move code that belongs in an anonymous namespace into one.
Review-Url: https://codereview.chromium.org/2416703002
|