Age | Commit message (Collapse) | Author |
|
Pass stream argument to constructor; it feels like a
stream accessor should always be made from a stream rather
than passing one in after the fact.
Change-Id: Iaa46cb37677b81f0170f5d39bab76ad38ea4af44
Reviewed-on: https://pdfium-review.googlesource.com/3620
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Make the IccProfile track its stream so that it has a
proper key with which to purge the docpagedata map.
Change-Id: Ib05ebc1afb828f1f5e5df62a1a33a1bfdecf507d
Reviewed-on: https://pdfium-review.googlesource.com/3619
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
This Cl drops the FXSYS_ from mem methods which are the same on all
platforms.
Bug: pdfium:694
Change-Id: I9d5ae905997dbaaec5aa0b2ae4c07358ed9c6236
Reviewed-on: https://pdfium-review.googlesource.com/3613
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This Cl drops the FXSYS_ from string methods which are the same on
all platforms.
Bug: pdfium:694
Change-Id: I1698aafd84f40474997549ae91ce35603377e303
Reviewed-on: https://pdfium-review.googlesource.com/3597
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Remove the old externally-counted CPDF_CountedImage type.
Change-Id: Ia0b288586272da3f2daf7dfc153f08e62794321a
Reviewed-on: https://pdfium-review.googlesource.com/3553
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
|
|
If the Kids array for the Pages dictionary does not exist, just treat this
dictionary as the unique page in the document.
BUG=chromium:702883
Change-Id: I9cb9645a53d60306ffe563f9b27cbbd37442f4ec
Reviewed-on: https://pdfium-review.googlesource.com/3135
Commit-Queue: Nicolás Peña <npm@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
If the PDF declares it has a gazillion pages when it does not, we just start
traversing again from the start. This CL fixes that.
BUG=chromium:680222
Change-Id: Ie9b55abc0aaa372429b3d995a7e1e7ab58fb7965
Reviewed-on: https://pdfium-review.googlesource.com/3060
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Avoid writing |Type| in CollectionSize<Type>() so that index
type can change without rewriting conditions.
Change-Id: I40c94ca39148b379908760ba9b861114b88af7bb
Reviewed-on: https://pdfium-review.googlesource.com/3056
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
Change-Id: I96e0a20d66b9184d22f64d8e4ce0dadd5a78c1e8
Reviewed-on: https://pdfium-review.googlesource.com/2967
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Moved all the flags to CFX_Font. Explicitly stated which ones are valued
according to the PDF spec to avoid their values being changed.
Change-Id: Ib57593234a4b9b83ef1ad593d0396c64159f303f
Reviewed-on: https://pdfium-review.googlesource.com/2837
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Moving to std::vector from the more forgiving CFX_ArrayTemplate
revealed the dubious page tree traversal, which depends on the
correctness of the /Count entries to properly summarize the total
descendants under a given node.
The only "correct" thing to do is to throw away these counts as parsed,
and re-compute them, perhaps in CountPages(). But I'm not willing to do
that since it may break unknown documents in the wild.
Pass out-params as pointers while we're at it.
BUG=680376
Review-Url: https://codereview.chromium.org/2636403003
|
|
Review-Url: https://codereview.chromium.org/2611413002
|
|
CPDF_DIBSource was already in its own file, but files needed renaming.
Change-Id: Ib3ac787a0bb33d3f78ecdcdfcdbc938867857a14
Reviewed-on: https://pdfium-review.googlesource.com/2152
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
The previous implementation, FindPDFPage, was already doing this since
the recursive call was always with return. Currently, we were trying to
keep going even after reaching max level. The problem is that if the
page tree is not a tree, we might loop forever. This could also be
solved by keeping track of the dictionaries that have been visited, but
this solution takes much less space.
BUG=672172
Change-Id: Ia37aea58e92b6068de69f26736c612aa6a0ff4b3
Reviewed-on: https://pdfium-review.googlesource.com/2138
Commit-Queue: Nicolás Peña <npm@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Split classes in FWL to be single class per file. In the case of data providers
which added no new methods, removed and used the IFWL_Widget::DataProvider
directly.
Review-Url: https://codereview.chromium.org/2520063002
|
|
Return these from underlying methods as appropriate.
Review-Url: https://codereview.chromium.org/2520133002
|
|
Some changes were required to match underlying ctors
as invoked by the templated methods.
Many release() calls go away, a few WrapUniques() are
introduced to avoid going deeper into other code.
Review-Url: https://codereview.chromium.org/2510223002
|
|
First CL in an attempt to reduce the class cluttering in
fpdf_render_text, fpdf_render_image, and fpdf_render.
Review-Url: https://codereview.chromium.org/2507023006
|
|
Make CDPF_Arrays intern the object they create.
Allow passing nullptr as a CFX_WeakPtr shortcut as well.
Review-Url: https://codereview.chromium.org/2509123002
|
|
Since the indirect object holder is now in the object creation
business, this will allow it to intern strings in a subsequent
CL.
Review-Url: https://codereview.chromium.org/2509773003
|
|
BUG=
Review-Url: https://codereview.chromium.org/2498223005
|
|
Add convenience routines to create and add object in
one step.
Review-Url: https://codereview.chromium.org/2489283003
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
#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
|
|
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
|
|
#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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Review-Url: https://codereview.chromium.org/2409283002
|
|
Ditto with the other ToXXX functions to CPDF_xxx.h.
Shortly, we will want to introduce another variant:
inline std::unique_ptr<CPDF_String> ToString(
std::unique_ptr<CPDF_Object>);
This will require that CPDF_String be complete which is
not the case in the CPDF_Object.h header. Rather than
dragging all the other .h's into it, move these to the
subclass headers. That way, these will be together
when the new form is added.
Review-Url: https://codereview.chromium.org/2406033002
|
|
- Remove some unused stuff from pageint.h.
- Replace some FX_BOOL with bool in pageint.h, and related.
- Replace some "protected" with "private" in pageint.h.
- Move 2 methods into namespace in fpdf_page_parser_old.cpp.
Review-Url: https://codereview.chromium.org/2399573002
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2393593002
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2392603004
|