Age | Commit message (Collapse) | Author |
|
BUG=pdfium:559
Review-Url: https://codereview.chromium.org/2286653002
|
|
This patch removes check-implicit-copy-ctors flag to the clang plugins.
This flag is enabled by default and will be removed soon.
R=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2283923002
|
|
The code that was deleted is being used by Android foxit viewer
This reverts commit dbfc3522a6ee24d17f2c50a5dcc465db52a280ee and updates the #includes
Review-Url: https://codereview.chromium.org/2281083002
|
|
Make use of existing ref count work rather than re-inventing it.
Review-Url: https://codereview.chromium.org/2281683002
|
|
- CPDF_TextPageFind and CPDF_LinkExtract moved to new file
- fpdf_text_int.cpp renamed to be CPDF_TextPage definition
Review-Url: https://codereview.chromium.org/2286723003
|
|
TBR=caryclark@google.com
Review-Url: https://codereview.chromium.org/2287443002
|
|
TBR=jshin@chromium.org
Review-Url: https://codereview.chromium.org/2283723002
|
|
TBR=thakis@chromium.org
Review-Url: https://codereview.chromium.org/2282693002
|
|
In [1], the lack of support of pdfium_test to some application
level hooks was felt.
More specifically, the lack of implementation of the hook FFI_GetPage,
called when 'this.getAnnot()' is executed in an Acrobar JS context,
makes it non-trivial to JS texts that manipulate PDF annotations.
[1] https://codereview.chromium.org/2265313002/
Here is the failing call stack in pdfium_test:
0 ::RenderPdf (samples/pdfium_test.cc)
1 ::FORM_DoDocumentOpenAction (fpdfsdk/fpdfformfill.cpp)
2 CPDFSDK_Document::ProcOpenAction (fpdfsdk/fsdk_mgr.cpp)
3 CPDFSDK_ActionHandler::DoAction_DocOpen (fpdfsdk/fsdk_actionhandler.cpp)
<----v8---->
4 Document::getAnnot (fpdfsdk/javascript/Document.cpp)
5 CPDFSDK_Document::GetPageView (fpdfsdk/fsdk_mgr.cpp)
6 CPDFDoc_Environment::FFI_GetPage (fpdfsdk/include/fsdk_mgr.h)
(frame 6 returns nullptr, and getAnnot call in frame 4 bails)
CL extends pdfium_test app with a FFI_GetPage hook implementation.
Basically what FFI_GetPage does is returning a FPDF_PAGE instance.
In case of pdfium_test, FPDF_PAGE instances were only created on demand
when the page was going to get rendered, and then discarded.
Since FFI_GetPage can be called by JS before pages are rendered,
CL moved the page creation code into a helper function, and cached
the FPDF_PAGE instances created in a map, so it does not recreate
them needlessly.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2277063003
|
|
This CL cleans up CPDFSDK_PageView::LoadFXAnnots and nits.
Review-Url: https://codereview.chromium.org/2279563005
|
|
Review-Url: https://codereview.chromium.org/2276343006
|
|
Avoid using reference argument and return CFX_FloatRect instead.
Review-Url: https://codereview.chromium.org/2278153005
|
|
Review-Url: https://codereview.chromium.org/2283503002
|
|
Review-Url: https://codereview.chromium.org/2277323002
|
|
BUG=597440
Review-Url: https://codereview.chromium.org/2273293003
|
|
BUG=444446
Review-Url: https://codereview.chromium.org/2271373003
|
|
fpdf_text_int.cpp should be split up into classes in a later CL
Review-Url: https://codereview.chromium.org/2271973004
|
|
Method is unused and misplaced (it should be in
CPF_Annot if actually needed).
Review-Url: https://codereview.chromium.org/2278613003
|
|
Remove friendship with CFX_Path
Pack members tighter on 64-bits.
Review-Url: https://codereview.chromium.org/2275883004
|
|
Review-Url: https://codereview.chromium.org/2276953003
|
|
Currently the only calls to CloseParser() happend in the destructor or the
start*Parse methods. The Start*Parse methods are currently only called on
freshly constructed parsers in fpdf_dataavail and fpdfview.
This CL removes the CloseParser() method and puts the contents in the
destructor. We then add an ASSERT that we don't re-enter the parser after it
has already completed the parse.
Review-Url: https://codereview.chromium.org/2267173005
|
|
This CL makes some methods private which are only used internally, removes
unused methods and removes an unused class.
Review-Url: https://codereview.chromium.org/2278583002
|
|
Added a vector of pointers to CFX_Fonts in the class CPDF_Font, so that
fallback fonts may be used. In CPDF_CharPosList::Load, the glyphs for each
character are calculated. When m_Font does not support a character, a fallback
font is selected and the character is rendered using that font. This meant
adding an attribute to FXTEXT_CHARPOS so it knows which font renders it.
Also, methods in fpdf_render_text.cpp now may need to call device drawing
methods multiple times because these only support one font at a time. In
CPDF_TextRenderer::DrawNormalText and in CPDF_TextRenderer::DrawTextPath, the
device drawing method is called as few times as possible by grouping contiguous
characters rendered by the same font. In
CPDF_RenderStatus::DrawTextPathWithPattern, drawing was already done one
character at a time, but precalculating CFX_FaceCache. Now, the face cache is
precalculated for all of the fallback fonts.
The list of fallback fonts does not include tha main font. Otherwise the list
would be of raw pointers to avoid double free problems. For now, the font
Arial is used as fallback. This should fix the issue of not seeing Latin
characters displayed when bad fonts are used. However, this should be improved.
Tested manually using the file in the bug, plus a font directory containing a
font that supports Hangul but not Latin. This font is chosen as the substitute
font, but Latin characters are now being rendered.
Design proposal: go/pdfium_fallbackfonts
BUG=pdfium:358
Review-Url: https://codereview.chromium.org/2276653002
|
|
This Cl switches the ownership between the parser and the document. Previously
the parser owned the document and we'd jump through hoops during cleanup to
delete the right object. This Cl flips the ownership so the document owns
the parser and simplifies the cleanup logic where needed.
BUG=pdfium:565
Review-Url: https://codereview.chromium.org/2275773003
|
|
Now that Document::getAnnot works and annotation instances
can have its properties changed, consider the following
scenario:
- A PDF content has an annotation without AP and
CPVT_GenerateAP is called to generate one.
- However the annotation also has its hidden flag set (/F 2),
and CPVT_GenerateAP bails out earlier, not generating an AP.
- When the PDF's Javascript runs, it acquires an instance of
this annotation object, bounded to JS using Document::getAnnot(),
and set its "hidden" flag to false.
- At this point, the annotation should get drawn, but it does
not because its "AP" was never generated.
CL fixes this scenario by making PDFium able to lazy
generate APs, if needed.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2265313002
|
|
This Cl moves the parser out of the indirect object holder and into the
CPDF_Document where it is used.
Review-Url: https://codereview.chromium.org/2277433003
|
|
Review-Url: https://codereview.chromium.org/2269203002
|
|
For some complex objects such as CPDF_Dictionary, CPDF_Array,
CPDF_Stream, and CPDF_Reference, Clone() could be executed with
infinite recursion to cause the stack overflow. Fix this by
checking already cloned objects to avoid recursion.
BUG=pdfium:513
Review-Url: https://codereview.chromium.org/2250533002
|
|
Embedder test's delegate function GetPage() calls FPDF_LoadPage() to
load a page which may be already loaded by embedder test itself.
Thus the page's ref count is increased unnecessarily.
This causes the page to be leaked. Fix this by putting the page map in
embedder test class and guarantee the page is loaded only once.
Also, fix leaks in this embedder tests by unloading the loaded pages to
properly release the resource.
BUG=pdfium:242
Review-Url: https://codereview.chromium.org/2258333002
|
|
This CL moves the m_IndirectObjs map to be private to the IndirectObjectHolder.
Various bits of code have been updated to use the accessors to the map.
This CL fixes the issue with the last time this landed by removing the objnum
check from GetIndirectObject() which appears to have caused the crashes.
Review-Url: https://codereview.chromium.org/2275703002
|
|
This Cl updates the names of the methods in the indirect object holder to better
reflect their usage. The m_LastObjNum is made private and a setter added.
Review-Url: https://codereview.chromium.org/2275593002
|
|
BUG=637119
Review-Url: https://codereview.chromium.org/2274723002
|
|
The GEFont points to the font manager which creates it and tries to unregister
itself. Currently the GEFont can be created by the default mapper and then
stored in a different mapper. If the default mapper is destroyed first, when
the second mapper cleans up the font there will be a call to unregister on
the default mapper causing a use-after-free.
The long term fix is to fixup the GEFont so it points to the correct mapper
to unregister from. This CL forces the destruction order in CXFA_FFApp to
cleanup the non-default mapper first.
BUG=chromium:637546
Review-Url: https://codereview.chromium.org/2259823004
|
|
This patch generates a default AP stream for text annotation. The AP stream
only draws a symbol, which represents the presence of text annotation at the
point.
Also, roll DEPS for testing/corpus to afbac94 to test text annotations.
BUG=62625
Review-Url: https://codereview.chromium.org/2270493002
|
|
BUG=637119
Review-Url: https://codereview.chromium.org/2268693003
|
|
Following up on [1], where the duplicated logic in
Field::SetDisplay was factored out into a helper function,
CL further cleans up a related method: ::SetHidden.
Field::SetHidden(true), for instance, is equivalent
to calling Field::SetDisplay(1), whereas Field::SetHidden(false)
is equivalent to Field::SetDisplay(0);
No behavior change is expected.
[1] https://codereview.chromium.org/2255843002
Review-Url: https://codereview.chromium.org/2266193002
|
|
Change the places which require implicit construction, and make the
construction from ARGB_Color explicit.
Review-Url: https://codereview.chromium.org/2263923003
|
|
Currently, when we destroy a CFFL_ComboBox we'll cleanup the fontmap and then
call the destructor for the parent type. This will case the PWL_Wnd to be
destroyed. In this case, the window is a PWL_Edit. On destruction it will reset
the focus which causes the text selection to change, which asks the font map
for data but we've already destroyed the font map.
This CL forces the destruction of the window earlier in order to have the
fontmap available. A followup bug is filed to correct the location of the
fontmap so we don't have this dependency.
BUG=chromium:637546
Review-Url: https://codereview.chromium.org/2266943002
|
|
Review-Url: https://codereview.chromium.org/2262703003
|
|
https://codereview.chromium.org/2253723002/ )
Reason for revert:
Causing asan issues. See crbug.com/639451.
Original issue's description:
> Move parser pointer to CPDF_Document
>
> The CPDF_IndirectObjectHolder has two subclasses, CPDF_Document and
> CFDF_Document. The CPDF document requires the parser and the CFDF document
> does not. This cl moves the parser pointer up to CPDF_Document.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/260f5fbf3553a96fa49b029cc050220039c30e2a
TBR=tsepez@chromium.org,thestig@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2266033002
|
|
BUG=pdfium:559
NOTRY=true
Review-Url: https://codereview.chromium.org/2265973002
|
|
The public API FPDFPage_New() incorrectly said to use FPDFPage_Delete()
instead of FPDF_ClosePage() to free the new page. This led to a page object
leak in an embedder test. Correct the public API description
as well as its usage in the embedder test.
BUG=pdfium:242
Review-Url: https://codereview.chromium.org/2260683003
|
|
Moved ScopedFontTransform from fx_ge_text namespace to fx_font
Moved some arrays used by both CFX_Font and CFX_FaceCache from fx_ge_text to
inside CFX_Font class
Review-Url: https://codereview.chromium.org/2263623002
|
|
It was intended to be unsigned in the first place, and we're
perfectly happy with the overflow as long as it is no longer
undefined behaviour.
BUG=638489
Review-Url: https://codereview.chromium.org/2258053003
|
|
Review-Url: https://codereview.chromium.org/2262473002
|
|
The array buffer allocators are allocated and owned by pdfium code,
they should be deleted properly after the corresponding isolates are
disposed.
BUG=pdfium:242
Review-Url: https://codereview.chromium.org/2254123004
|
|
BUG=636559
Review-Url: https://codereview.chromium.org/2255083004
|
|
The PDF specification [1] says:
"
syncAnnotScan guarantees that all annotations will be scanned
by the time this method returns.
(..)
Normally a background task runs that examine every page and
looks for annotations during idle times.
"
The statement details specifically how Acrobat implements
this method.
Although, neither the method itself nor the background scanner
task are implemented in PDFium (as of today, Ago/2016),
not having ::syncAnnotScan at least stubbed out can be considered
harmfull since its absence makes JS acrobat scripts silently
fail when it has a call to it.
Given that, and following a stub-out pattern present in other
methods including ::addAnnot and ::addField, CL provides
a stubbed out implementation of Document::syncAnnotScan.
[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2265553002
|
|
BUG=pdfium:562
Review-Url: https://codereview.chromium.org/2257313002
|
|
CL implements the first step in order to support
Annotations manipulation in PDFium: Document::getAnnot.
The method takes two arguments, an integer (page number)
and a string (annotation name).
When called, it iterates over the annotations on
the given page number, searching for the one whose name
matches the string in the second parameter.
If found, then an Annot instance (see Annot.cpp/g added by this
CL), is bound to a Javascript object and returned.
With the use cases described in bug [1] as an initial test case,
CL adds support to the following Annotation object properties:
- hidden
- name
- type
Idea is to keep evolving the implementation with more methods
and properties in follow up CLs.
[1] https://bugs.chromium.org/p/pdfium/issues/detail?id=492
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2260663002
|