Age | Commit message (Collapse) | Author |
|
#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
|
|
Review-Url: https://codereview.chromium.org/2477443002
|
|
Review-Url: https://codereview.chromium.org/2453163002
|
|
This reverts commit 1d023881cd53485303c0fcc0b5878e700dc470fd.
Reason for revert -- fuzzers hit issues.
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2425783002
|
|
Review-Url: https://codereview.chromium.org/2395693002
|
|
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
|
|
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
|
|
This avoids a re-assignment that can otherwise cause a later fault.
BUG=pdfium:607
Review-Url: https://codereview.chromium.org/2393953002
|
|
There's no way to take ownership back from the CPDF_Array
without deleting the object, so add a new primitive to make
elements become indirect rather than manipulating them
outside the class.
This should solve the ASSERT(objnum == 0) issue that
blocked the previous roll.
Review-Url: https://codereview.chromium.org/2391883003
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2393593002
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2392603004
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2386423004
|
|
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2392773003
|
|
Review-Url: https://codereview.chromium.org/2386273004
|
|
Restore CPDF_Dictionary default constructor.
Use it in places where reasonable in the code.
TBR=dsinclair@chromium.org
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2383843002
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2377393002
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2382723003
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2374383003
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2382763002
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2383543002
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2379033002
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2375283003
|
|
Correctly account for non-leaf Nodes that have CPDF_FormField pointers.
Review-Url: https://codereview.chromium.org/2376193002
|
|
BUG=pdfium:597
Review-Url: https://codereview.chromium.org/2345063002
|
|
Remove default arguments.
Review-Url: https://codereview.chromium.org/2380753003
|
|
Review-Url: https://codereview.chromium.org/2372423002
|
|
Also, it's idempotent, so simplify some logic in callers to
not care if objnum is zero.
The alternate forms are rarely used, using the objnum form
makes it clear that SetReferenceFor() can't possibly register
the object as a side-effect.
Review-Url: https://codereview.chromium.org/2361713002
|
|
Review-Url: https://codereview.chromium.org/2358243002
|
|
Upon indirect object holder destruction, all indirect
objects are destroyed -- currently by order of increasing
object number -- but ideally without ordering constraints.
So currently, we can get away with a dictionary pointing
directly at an indirect object with a higher number. It
gets destroyed first, invoking Release() on its subordinates,
which skips destroying them if they are indirect objects. But
we don't want to rely on this artifact of destruction
order. Should it happen to be reversed, the dictionary
would invoke Release() on freed memory.
Interestingly, CPDF_Array skirts the issue by replacing
any indirect objects it is given with references. Not
clear whether we should do the same thing for dictionaries,
or remove it from arrays. The technique certainly
complicates understanding ownership.
The one violation found is in the unittest that broke the
previous CL which tried to use unique_ptrs in indirect
object holder.
Review-Url: https://codereview.chromium.org/2353093002
|
|
BUG=645954
Review-Url: https://codereview.chromium.org/2355733002
|
|
Replace the CPDF_Stream(nullptr, 0, nullptr) pattern with
a default ctor.
Remove unused parameters from CPDF_Stream::SetData(). Both
are always passed as FALSE.
CPDF_Stream declared its own m_GenNum, which shadowed the one
in CPDF_Object. It was used only to distinguish file/memory
streams, so add a bool explicitly for this purpose.
Remove the union, it would be sad if we confused user data
with a C++ object with virtual function calls.
Use unique_ptrs with appropriate deleters to manage memory.
Review-Url: https://codereview.chromium.org/2347993002
|
|
PWL_FontMap does not need its own charset definitions. fx_edit.h does
not need to define DEFAULT_CHARSET. XFA have their own definitions.
They look different in that most are MAC or MSWin charset definitions.
So they are left untouched. public/fpdf_sysfontinfo.h duplicate ones
were left untouched due to being in public folder.
Review-Url: https://codereview.chromium.org/2347313002
|
|
On Acrobat, if "/AP" is present on a text markup definition,
the coordinates used to draw the annotation come from "/Rect
values, whereas if "/AP" is not defined, the array defined
in /QuadPoints is used to grab the annotation coordinates from.
PDFium, on the other hand, uses "/Rect" regardless of
presence or absence of "/AP".
CL fixes PDFium to work similarly to Acrobat, in this case.
TEST=testing/resources/pixel/bug_585_*.in
BUG=pdfium:585
Review-Url: https://codereview.chromium.org/2289293005
|
|
This Cl makes the Get and Set methods consistenly use {G|S}et<Type>For.
BUG=pdfium:596
Review-Url: https://codereview.chromium.org/2334323005
|
|
Deleted parameter from callers, who also do not use it.
Review-Url: https://codereview.chromium.org/2337973004
|
|
This CL updates all of the includes to be correctly sorted. A PRESUBMIT warning
is added (from chromium) that will warn if the includes are in the wrong order on upload.
Review-Url: https://codereview.chromium.org/2337293002
|
|
Review-Url: https://codereview.chromium.org/2341453002
|
|
Avoids a needless alloc and copy.
Review-Url: https://codereview.chromium.org/2338553002
|
|
Wide strings compare just fine on their own.
Review-Url: https://codereview.chromium.org/2331233002
|
|
Removes some unused code for the default implementation,
Review-Url: https://codereview.chromium.org/2332983002
|
|
We should not use DR field from annotation/field dictionaries, since
these are not supposed to have one. In PDF spec 1.7, DR is defined only
for the form dictionary, in 8.6.1. In addition, note 118 in Appendix H
says "In PDF 1.2, an additional entry in the field dictionary, DR, was
defined but was never implemented. Beginning with PDF 1.5, this entry
is obsolete and should be ignored."
The changes in CBA_FontMap fix the bug below. The changes in
cpvt_generateap do not affect the bug but follow the reasoning from
the above paragraph.
BUG=pdfium:538
Review-Url: https://codereview.chromium.org/2337673002
|
|
Previously, PDFium only supported widget annotations to draw forms. As
we've implemented other annotations, the behavior of
FPDF_RenderPageBitmap_Retail and FPDF_FFLDraw changed. So, this CL
clearly defines what needs to be done in FPDF_RenderPageBitmap_Retail
and FPDF_FFLDraw.
This CL first assumes that PDFium users will always call
FPDF_RenderPageBitmap_Retail and FPDF_FFLDraw to render PDF pages,
because otherwise they are not able to support PDF forms.
FPDF_RenderPageBitmap_Retail should only deal with non-widget
annotations, such as highlight, underline, text, etc. If
FPDF_ANNOT flag is passed, non-widget annotations are drawn. Otherwise,
they are hidden.
FPDF_FFLDraw should only deal with annotations that requires
user-interaction, such as widget annotations and popup annotation. Since
popup annotation is associated with non-widget annotation, they should
not be drawn if the associated annotation is hidden. Thus, if FPDF_ANNOT
flag is passed, popup annotations are drawn. Otherwise, they are hidden.
Widget annotations should be always drawn regardless of FPDF_ANNOT flag
since they need to be always displayed for PDF forms.
Also, roll DEPS for testing/corpus to 8485b30.
BUG=pdfium:594
Review-Url: https://codereview.chromium.org/2323203002
|
|
CFX_ByteString cannot properly check whether the contents string is empty
because the first two bytes of text strings encoded in Unicode are always ASCII
254 followed by 255. So if we get contents in CFX_ByteString, the length will
always be 2.
Also, roll DEPS for testing/corpus to 608bf04.
Review-Url: https://codereview.chromium.org/2293403003
|
|
Review-Url: https://codereview.chromium.org/2312743005
|
|
By doing this, we simplify the code in cpvt_generateap.cpp,
and avoid calling CPVT_GenerateAP methods altogether,
when it is known that they are bailing out.
This is a preparation to fix pdfium bug 585.
BUG=pdfium:585
Review-Url: https://codereview.chromium.org/2310873002
|
|
When we create popup annotations, we also create the dictionary
associated with it. For regular annotations, the dictionary
associated with an annotation is not owned by annotation,
and will be released separately. But our created dictionary is not
associated with any other data structure, it would be leaked if not
released by the associated annotation.
Add a boolean to indicate the ownership to the dictionary, and release
the owned dictionary during the destruction of an annotation.
BUG=pdfium:242
Review-Url: https://codereview.chromium.org/2301613002
|
|
This one doesn't require an explict Emplace(), as the object
seems to get constructed only as a side-effect of making a
private copy.
Review-Url: https://codereview.chromium.org/2298953002
|