Simplify PDFium by removing code that's not used in the open source repo.

Simplify PDFium by removing code that's not used in the open source repo.

-remove parameter from FPDF_InitLibrary
-remove a bunch of ifdefs that are unused

R=tsepez@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/217ecf3b39f8d5c01260684848a8886c8ed2bf89

[jam, 2014-12-12 19:36:02]

jam@chromium.org changed reviewers:
+ bo_xu@chromium.org, tsepez@chromium.org

[jam, 2014-12-12 19:36:03]

https://codereview.chromium.org/801913002/diff/1/core/src/fxge/ge/fx_ge_linux...
File core/src/fxge/ge/fx_ge_linux.cpp (left):

https://codereview.chromium.org/801913002/diff/1/core/src/fxge/ge/fx_ge_linux...
core/src/fxge/ge/fx_ge_linux.cpp:11: #if (_FXM_PLATFORM_  ==
_FXM_PLATFORM_APPLE_ && (!defined(_FPDFAPI_MINI_)))
this code is basically platform == linux && platform == mac which will never be
hit

https://codereview.chromium.org/801913002/diff/1/fpdfsdk/src/fpdfoom.cpp
File fpdfsdk/src/fpdfoom.cpp (left):

https://codereview.chromium.org/801913002/diff/1/fpdfsdk/src/fpdfoom.cpp#oldc...
fpdfsdk/src/fpdfoom.cpp:22:
FXMEM_SetOOMHandler(FXMEM_GetDefaultMgr(),OOM_Handler,oomInfo);
this method isn't defined anymore.

Tom: this was added for security reasons (see the caller in chromium code which
exits the process on OOM). I'm guessing we don't need this anymore now that we
don't use a custom memory allocator?

[Tom Sepez, 2014-12-12 22:23:04]

I'm not sure its worth doing this cleanup against the origin/master branch, when
we hope to replace it with the code currently in origin/xfa.  Last time I put
together such a cleanup, the response was "but this is used in XFA" for a number
of them.  Do you know if that's the case here?

[jam, 2014-12-12 22:35:45]

On 2014/12/12 22:23:04, Tom Sepez wrote:
> I'm not sure its worth doing this cleanup against the origin/master branch,
when
> we hope to replace it with the code currently in origin/xfa.  Last time I put
> together such a cleanup, the response was "but this is used in XFA" for a
number
> of them.  Do you know if that's the case here?

I thought that the xfa branch only touched a small number of the existing files,
and it was mostly new files?

do you have a pointer to your old cl so I can see what was changed in it?

all the code i removed is stuff we wouldn't use in chrome (i.e. different memory
manager, "mini" mode, non-pdfium code).

[Tom Sepez, 2014-12-12 22:36:12]

I'd keep the memory stuff as-is.  I'm not sure we want to tie this to a specific
allocator behaviour.

https://codereview.chromium.org/801913002/diff/1/core/src/fxge/agg/agg23/fx_a...
File core/src/fxge/agg/agg23/fx_agg_driver.cpp (right):

https://codereview.chromium.org/801913002/diff/1/core/src/fxge/agg/agg23/fx_a...
core/src/fxge/agg/agg23/fx_agg_driver.cpp:217: #if _FXM_PLATFORM_  !=
_FXM_PLATFORM_APPLE_
nit: extra space before !=

https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc
File samples/pdfium_test.cc (right):

https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc#newco...
samples/pdfium_test.cc:381: FPDF_InitLibrary();
OK for now, but interestingly, we're probably going to have to modify this
function to accept some js-specific arguments now that JS can't find its own
code anymore ( see https://code.google.com/p/chromium/issues/detail?id=439793 ).

[jam, 2014-12-12 22:55:56]

On 2014/12/12 22:36:12, Tom Sepez wrote:
> I'd keep the memory stuff as-is.  I'm not sure we want to tie this to a
specific
> allocator behaviour.

which memory stuff are you talking about? not the
USE_MSDOS_MEMMGR/USE_MAC_MEMMGR i presume which aren't used?

https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc
File samples/pdfium_test.cc (right):

https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc#newco...
samples/pdfium_test.cc:381: FPDF_InitLibrary();
On 2014/12/12 22:36:12, Tom Sepez wrote:
> OK for now, but interestingly, we're probably going to have to modify this
> function to accept some js-specific arguments now that JS can't find its own
> code anymore ( see https://code.google.com/p/chromium/issues/detail?id=439793
).

i'm curious, why do that instead of initializing v8 directly from src/pdf? i.e.
third_party/pdfium already doesn't initialize v8 itself, and depends on the
wrapper code to do so.

[Tom Sepez, 2014-12-12 23:09:14]

On 2014/12/12 22:55:56, jam wrote:
> On 2014/12/12 22:36:12, Tom Sepez wrote:
> > I'd keep the memory stuff as-is.  I'm not sure we want to tie this to a
> specific
> > allocator behaviour.
> 
> which memory stuff are you talking about? not the
> USE_MSDOS_MEMMGR/USE_MAC_MEMMGR i presume which aren't used?
No, just the OOM stuff you asked about.

> 
> https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc
> File samples/pdfium_test.cc (right):
> 
>
https://codereview.chromium.org/801913002/diff/1/samples/pdfium_test.cc#newco...
> samples/pdfium_test.cc:381: FPDF_InitLibrary();
> On 2014/12/12 22:36:12, Tom Sepez wrote:
> > OK for now, but interestingly, we're probably going to have to modify this
> > function to accept some js-specific arguments now that JS can't find its own
> > code anymore ( see
https://code.google.com/p/chromium/issues/detail?id=439793
> ).
> 
> i'm curious, why do that instead of initializing v8 directly from src/pdf?
i.e.
> third_party/pdfium already doesn't initialize v8 itself, and depends on the
> wrapper code to do so.

That sounds like a better approach, however what's going on here? 

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/pdfium...

in XFA we have more of the same (which still needs resolution).

[Tom Sepez, 2014-12-13 00:22:45]

I think its OK to land this as-is and take care of any other issues as a
follow-one. LGTM.

[jam, 2014-12-13 00:42:24]

Committed patchset #1 (id:1) manually as
217ecf3b39f8d5c01260684848a8886c8ed2bf89 (presubmit successful).