zling2001 / pdfium Goto Github PK

Our goal is to use Skia inside Pdfium for Chromium. The motivations are 
security (so we can drop GDI, see 
https://code.google.com/p/chromium/issues/detail?id=365160), performance (it's 
faster to use DirectWrite), and UI (fonts drawn with DW are better looking, 
especially with HiDPI).

Previously we had a Skia port but we lost that in the open sourcing. We need to 
bring that back.

As seen in https://codereview.chromium.org/441763002/, lines 274 – 285 of 
fpdfsdk/src/fsdk_actionhandler.cpp either can be simplified, or we need to 
reinstate (?) / create an |IsValidDocument| function.

http://www.commonwealthfund.org/~/media/Files/Publications/Fund%20Report/2013/No
v/1717_Thomson_intl_profiles_hlt_care_sys_2013_v2.pdf

Copying only works line by line. If selecting a few lines or a paragraph, it 
fails.

What steps will reproduce the problem?
1.Launch chrome and go to http://www.cse.msu.edu/~chooseun/Test2.pdf
2.Bookmark the page to Bookmarks bar and click on bookmarked page for 5-7 times

What is the expected output? What do you see instead?
PDF file should be loaded but "Failed to load PDF document" message is seen.

What version of the product are you using? On what operating system?
Version 37.0.2062.76 beta,Ubuntu 12.04

Please provide any additional information below.

This is a regression issue broken in M35...

good:35.0.1888.0 (Official Build 256779) dev aura
bad:35.0.1892.0 (Official Build 257070) dev aura

Cr: 
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk
/src&range=257070:256779&mode=html

What steps will reproduce the problem?
1. git clone pdfium
2.
3.

What is the expected output? What do you see instead?
That I have at least a README telling me how to compile this, since it doesn't 
use a standard build system

What version of the product are you using? On what operating system?
Fedora 20 + f05b6115f6b5b7a47f2c8834779987cdd3e8d52e from the git repo

Please provide any additional information below.

This issue is from Jeff:

"
Bo, I am responsible for the PDF representation of millions books 
digitized by Google. I also wrote the PDF code for Tesseract, 
which is a leading open source OCR engine. I have 100% control 
over every aspect of these PDF files. We would be very happy to 
become more compatible with Foxit.

Experimentally, I have found that forcing a character bounding
box in the font works well for Latin scripts, but produced erratic 
results with other languages. As always, any thoughts or suggestions 
appreciated.
"

What steps will reproduce the problem?
1. Edit pdfium.gyp to contain `'chromium_code': 1,` in the variables block at 
the very top
2. re-gyp
3. Build pdfium_test in a chromium checkout.

What is the expected output? What do you see instead?

It should build successfully. Instead, I get a mountain of build warnings. See 
attachment for the current list.

I'll poke at this every now and then, but I'll need help for some of this (e.g. 
the Woverloaded-virtual warnings, which are the most scary).

Chrome Version : 38.0.2120.0 (Official Build 288631) 32/64 bit
OS : All (Win 7: Aero enabled)
URL: http://www.education.gov.yk.ca/pdf/pdf-test.pdf

What steps will reproduce the problem?
1. Launch Chrome & go to above test pdf URL
2. Right click on the link/URL on that page & observe  

Page gets crashed after right clicking.

Page should not get crashed.

Generated Crash IDs are: 90a564aca32f0cf1 (Chrome); 13f52300db34160c (Chrome)

This is a regression issue broken in M-38 and will soon update bisect info. 

Render the pages of the attached document. It has 4 identical pages except for 
the Rotate entry. Each page has two annotations, a blue one which does not have 
the NoRotate bit set and is therefore rotated with the page and a red one which 
has
the NoRotate bit set and should therefore not be rotated with the page.

However, both annotations are rotated by PDFium.

I'm seeing the wrong behavior with a PDFium git checkout of 2014-06-13 as well 
as with google chrome 35.0.1916.153, both on an x86_64 Linux.

Invoking methods through a NULL pointer is UB in C/C++. Compiler can use this 
UB to optimize out comparisons between this and NULL.

See also http://www.viva64.com/en/b/0226/ for additional problems.

What steps will reproduce the problem?
1. Open Any PDF with a true type font which has been encoded similar to the 
following 
<</Type/FontDescriptor/FontName/IOVEMJ+Junicode-Italic/FontBBox[-67 -272 437 
727]/Flags 131076
/Ascent 727
/CapHeight 727
/Descent -272
/ItalicAngle 0
/StemV 65
/MissingWidth 500
/XHeight 527
/FontFile2 295 0 R>>

2. Attempt to read information about the font from 
FPDF_CHAR_INFO.m_pTextObj->GetFont()

What is the expected output? What do you see instead?
Expect to see a font with all the relevant information filled out but instead 
the metadata such as font name and style are blank. When Opening a file encoded 
like this:

<</Type/FontDescriptor/FontName/BAAAAA+Calibri-Italic
/Flags 68
/FontBBox[-724 -275 1258 1013]/ItalicAngle -30
/Ascent 952
/Descent -268
/CapHeight 1013
/StemV 80
/FontFile2 7 0 R
>>

It works correctly. This leads me to believe it is a problem in the parsing. 

What version of the product are you using? On what operating system?
PDFium is at commit 9108ad211bf00d6e512af0919b743c1bf8b0eeb8
Running on Ubuntu 14.04

The line
ParamList.Add(pParams->GetDict()); 
may crash if pParams is NULL. This could happen, if pDict parameter has Filter 
property of type PDFOBJ_NAME but doesn't have DecodeParms property.

Tinkering with Mr. Zalewski's American Fuzzy Lop fuzzer and found a few cases 
where the following segfault occurs (read on null ptr):

==26134== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core
==26134==  Access not within mapped region at address 0x1C
==26134==    at 0x835D719: CFX_BaseSegmentedArray::Iterate(int (*)(void*, 
void*), void*) const (fx_basic_array.cpp:312)
==26134==    by 0x8372242: CFX_CMapByteStringToPtr::Lookup(CFX_ByteStringC 
const&, void*&) const (fx_basic_maps.cpp:507)
==26134==    by 0x813D959: CPDF_Dictionary::GetElement(CFX_ByteStringC const&) 
const (fpdf_parser_objects.cpp:595)
==26134==    by 0x81591A1: CPDF_DataAvail::CheckRoot(IFX_DownloadHints*) 
(fpdf_parser_parser.cpp:3173)
==26134==    by 0x81581CF: CPDF_DataAvail::CheckDocStatus(IFX_DownloadHints*) 
(fpdf_parser_parser.cpp:3000)
==26134==    by 0x8157A77: CPDF_DataAvail::IsDocAvail(IFX_DownloadHints*) 
(fpdf_parser_parser.cpp:2922)
==26134==    by 0x805808F: FPDFAvail_IsDocAvail (fpdf_dataavail.cpp:117)
==26134==    by 0x804CF35: RenderPdf(char const*, char const*, unsigned int, 
OutputFormat) (pdfium_test.cc:279)
==26134==    by 0x804DB71: main (pdfium_test.cc:397)

Collection of test files including the original (good.pdf) is attached

Please review the attached patch. It fixes two potential resource leaks in 
fpdfsdk/src/javascript/Document.cpp.

Best regards and many thanks

Martin Ettl

I'm trying to roll pdfium here: https://codereview.chromium.org/432173002/

PDFExtensionTest.BasicPlugin is failing consistently on mac_chromium_rel

Render to a bitmap a page containing an annotation that does not have the Print 
flag set. FPDF_PRINTING should control whether that annotation is rendered or 
not, but doesn't.

I'm using PDFium from git of 2014-06-13 on an x86_64 Linux.

The attached patch solves the problem for me, but I don't know whether it's 
correct for the rest of the world.

foxit@ubuntu:~/chrome/src/out/Debug$ ./pdfium_test --ppm 
/home/foxit/chrome/testfiles/387979/signal_sigsegv_54ad95_9186_cov_1954837690_71
75.pdf 2>&1 | /home/foxit/chrome/src/tools/valgrind/asan/asan_symbolize.py | 
c++filt 
==4105== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7ff08f007a01 in CPDF_Object::Release() /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_objects.cpp:10:9
    #1 0x7ff08f0e9928 in CPDF_DataAvail::CheckPage(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:3290:17
    #2 0x7ff08f0ea3a6 in CPDF_DataAvail::CheckPageStatus(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:3033:20
    #3 0x7ff08f103612 in CPDF_DataAvail::LoadPages(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:4097:14
    #4 0x7ff08f108e38 in CPDF_DataAvail::IsPageAvail(int, IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:4223:22
    #5 0x7ff08e97b2a7 in FPDFAvail_IsPageAvail /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/fpdfsdk/src/fpdf_dataavail.cpp:150:9
    #6 0x7ff08e9034e4 in RenderPdf(char const*, char const*, unsigned long, OutputFormat) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/samples/pdfium_test.cc:297:12
    #7 0x7ff08e909de0 in main /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/samples/pdfium_test.cc:393:7
    #8 0x7ff08b5fd76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226:0
    #9 0x7ff08e8fbaec in _start ??:0:0

  Uninitialized value was created by a heap allocation
    #0 0x7ff08e8a7713 in __interceptor_free ??:0:0
    #1 0x7ff08e93ad9c in CFX_Object::operator delete(void*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/fpdfsdk/src/../include/../../core/include/fpdfapi/../fxcrt/fx_memory.h:44:9
    #2 0x7ff08f007f8c in CPDF_Object::Destroy() /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_objects.cpp:28:13
    #3 0x7ff08f007a3b in CPDF_Object::Release() /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_objects.cpp:13:5
    #4 0x7ff08f0e9728 in CPDF_DataAvail::CheckPage(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:3287:13
    #5 0x7ff08f0ea3a6 in CPDF_DataAvail::CheckPageStatus(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:3033:20
    #6 0x7ff08f103612 in CPDF_DataAvail::LoadPages(IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:4097:14
    #7 0x7ff08f108e38 in CPDF_DataAvail::IsPageAvail(int, IFX_DownloadHints*) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:4223:22
    #8 0x7ff08e97b2a7 in FPDFAvail_IsPageAvail /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/fpdfsdk/src/fpdf_dataavail.cpp:150:9
    #9 0x7ff08e9034e4 in RenderPdf(char const*, char const*, unsigned long, OutputFormat) /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/samples/pdfium_test.cc:297:12
    #10 0x7ff08e909de0 in main /home/foxit/chrome/src/out/Debug/../../third_party/pdfium/samples/pdfium_test.cc:393:7
    #11 0x7ff08b5fd76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226:0

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 ??
Exiting

What steps will reproduce the problem?
1. Compile pdfium from git under Windows

2. Run pdfium_test.exe on the attached Test.pdf [1] with the --write_images 
option:

pdfium_test.exe --write_images Test.pdf

Expected Output:
Generated PPM image looks like test-pdf-correct.png

Actual Output:
Generate PPM image looks like test-pdf-corrupt.png

What version of the product are you using? On what operating system?

Current pdfium version on Windows (commit 
9a52eb09edf2f5001f33f2227cc3888ef2e8c338)

Please provide any additional information below.

The problem stems from using just "w" in the fopen call used in the WritePpm() 
function in samples/pdfium_test.cc . 

Under Windows this implicitly uses text mode, which replaces every occurrence 
of the byte 0xa with 0x0d 0x0a while writing the ppm file.

By applying one of the two attached patches, the problem does not occur 
anymore. 

pdfium_test-fopen-file-corruption-generic.patch changes the fopen calls to 
explicitly use "wb" and "rb" on all platforms.

Alternatively pdfium_test-fopen-file-corruption-winspecific.patch uses "wb" and 
"rb" only on Windows platforms.

I would prefer the first generic version of the patch, because it is more 
explicit to use binary mode to open the files.

Test PDF obtained from:
http://stlab.adobe.com/wiki/images/d/d3/Test.pdf

What steps will reproduce the problem?
1.Compile the latest code on windows.

What is the expected output? What do you see instead?
build success; 
build failed.

What version of the product are you using? On what operating system?
pdfium / pdfium / master
commit  9108ad211bf00d6e512af0919b743c1bf8b0eeb8[log][tgz]  
author Chris Palmer <[email protected]> Thu Jun 26 16:01:46 2014 -0700
committer Chris Palmer <[email protected]> Thu Jun 26 16:01:46 2014 -0700

On 64bit windows 7, MS VC++ 10.0, Project configuration is Win32.

Please provide any additional information below.

I modify the code:

  static RangeConstraint Check(Src value) {
    return GetRangeConstraint(value <= std::numeric_limits<Dst>::max(), true);
  }

to:

  static RangeConstraint Check(Src value) {
 // reture GetRangeConstraint(value <= std::numeric_limits<Dst>::max(), true);
    return RANGE_VALID; 
  }

the build succeeded.

use FPDFText_PDFToText function in source code 

I was expecting to get the text form of pdf but it throws the error, function 
not declared. I also looked in the header file "fpdftext.h" which was suggested 
to be included in order to use this function but this method is missing in the 
header file.

I have dowloaded your latest source code and using it on ubuntu 12.04

Code is littered with things like

#ifndef FOXIT_CHROME_BUILD
    CFX_WideString swTitle = L"Foxit";
#else
    CFX_WideString swTitle = L"PDF";
#endif

which make it less readable and shouldn't be needed in a pdfium world.

What steps will reproduce the problem?
1. cros chrome-sdk --board link
2. gclient sync
3. ninja -C out_link/Release chrome nacl_helper chrome_sandbox

I consistently get a compiler warning about an offset outside the bounds of a 
constant string.

CXX 
obj/third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdfapi.fpdf_parser_parser.o
../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp: 
In member function 'CPDF_Object* 
CPDF_SyntaxParser::GetObject(CPDF_IndirectObjects*, FX_DWORD, FX_DWO
RD, FX_INT32, PARSE_CONTEXT*, FX_BOOL)':
../../third_party/pdfium/core/src/fpdfapi/fpdf_parser/fpdf_parser_parser.cpp:219
3:101: warning: offset outside bounds of constant string [enabled by default]
                     pDict->AddValue(CFX_ByteStringC(((FX_LPCSTR)key) + 1, key.GetLength() - 1), pObj);

Looks like the standalone build system is not yet present. 
When you work on it please make sure that the code can be built with 
AddressSanitizer (asan) and MemorySanitizer (msan).

Once the standalone build is in place and you start setting up 
build bots, please make sure there are asan/msan bots too. 

What steps will reproduce the problem?
1. Open the attached PDF in Chrome/Chromium.
2. Click the text "Click to view Manual"

What is the expected output? What do you see instead?
The link should be followed (to 
http://support.feralinteractive.com/docs/en/hitmanabsolution/latest/steam/manual
/). This works with Adobe Reader and in Apple Preview / Safari.

What version of the product are you using? On what operating system?
This behaviour has been observed on Mac OS 10.7 and 10.9 using both:
Google Chrome 35.0.1916.114
Chromium 37.0.2018.0 (273185)

Please provide any additional information below.

Version:37.0.2062.0 (Official Build 278856) 
OS:All (win 7-Aero enabled)

What steps will reproduce the problem?
1.Launch chrome and go to 
http://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf
2.It opens a pdf then hover mouse on bottom right
3.Click on landscape or portrait view and observe

After switching to landscape or portrait view a zoom bubble is seen in omnibox

Zoom bubble should not be seen

This is regression, issue broken in 'M37' will update bisect soon


Note:Issue is applicable to any pdf files

What steps will reproduce the problem?
1. Load the attached PDF file in chrome

What is the expected output? What do you see instead?

The figure on the right on the first page shows a yellowish background, but 
shouldn't.


What version of the product are you using? On what operating system?

Still occurs with latest build as of 06/26/2014.


Please provide any additional information below.

What steps will reproduce the problem?

1. Set GYP to generate ninja build files:

set GYP_GENERATORS=ninja

2. Try to generate the ninja build files for x64:

python build/gyp_pdfium -Dtarget_arch=x64

What is the expected output? What do you see instead?

ninja build files should be generated for Windows x64 but gyp bails out with 
"KeyError: 'Debug_x64'" instead.

This is a similiar issue as skia issue 2348:
https://code.google.com/p/skia/issues/detail?id=2348

What version of the product are you using? On what operating system?

gyp r1939, pdfium 9d319f0cb5e0850447dbd95b07fed28245fb0b31, ninja 1.4.0 on 
windows.

Please provide any additional information below.

This problem can be fixed similarly to the skia issue using the attached patch. 
I will submit a cl with this patch as well.

the pdfium sources contains a call to V8::InitializeICU() however, that is 
commented out for chrome builds.

Since ICU is linked statically into pdfium, the copy used by pdfium is not 
configured and trying to access it will result in a crash (see attached PoC)

Original issue reported at 
https://code.google.com/p/chromium/issues/detail?id=321681

Chrome Version       : 37.0.2062.0 (Official Build 278856) dev
OS : Mac
https://enregistrement.grandlyon.fr/Enregistrement/CG/CG.pdf

What steps will reproduce the problem?
1. Launch chrome & open above test pdf file.
2. Select url in omnibox & click on wrench,then select copy/cut/paste options , 
observe  

For PDF file Edit options : Copy/Cut/Paste options in wrench are not working,so 
this options should be disabled.

Copy/Cut/Paste options in wrench menu are not working still they are enabled. 

Note : This is working fine in OS Mac & Linux.

This is a Mac specific non regression issue. 

Since IsSafeMode(cc) appears to be always true for pdfium, i.e.

FX_BOOL CJS_EmbedObj::IsSafeMode(IFXJS_Context* cc)
{
    ASSERT(cc != NULL);

    return TRUE;
}

There is a lot of unreachable code that can be removed.  Some of this does some 
pretty scary stuff, so removing it outright will prevent a botch down the road 
(like a blown merge that deletes the safe mode check) from opening a hole.

V8 embedders are required to provide an implementation of the v8::Platform 
interface before using v8.

PDFium currently does not. This only works, because the code path that calls to 
the v8::Platform interface is still disabled by default, but chromium would 
like to enable it soon.

v8 itself provides a default implementation of v8::Platform which pdfium could 
just use.

All of chromium builds with exceptions disabled, except for the pdfium targets. 
The try/catch blocks don't seem to do much, and there are no throw statements 
anywhere. The only thing I could think of they're good for is to protect 
against operator new throwing on OOM, but new is called in a few places without 
try/catch too, and the chromium allocator kills the process on OOM instead of 
throwing anyways.

pdfium shouldn't use try/catch. There aren't many of these blocks anyways.

Hello

Final keyword in [5eb9f7b] makes build crash.
To fix this, you can change line in fx_system.h:

#if defined(__clang__) || defined(_MSC_VER)

to

#if defined(__clang__) || _MSC_VER1 >= 1700

What steps will reproduce the problem?

Run pdfium_test on attached file, either under valgrind or msan 
(http://www.chromium.org/developers/testing/memorysanitizer)

==14288== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f4b558d2087 in PS_Conv_ToFixed third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/psaux/psconv.c:275
    #1 0x7f4b558ba581 in ps_parser_load_field third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/psaux/psobjs.c:1105
    #2 0x7f4b559799a9 in t1_load_keyword third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/type1/t1load.c:1016
    #3 0x7f4b559799a9 in parse_dict third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/type1/t1load.c:2001
    #4 0x7f4b5596c8d7 in T1_Open_Face third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/type1/t1load.c:2118
    #5 0x7f4b5596c8d7 in T1_Face_Init third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/type1/t1objs.c:339
    #6 0x7f4b558464cd in open_face third_party/pdfium/core/src/fxge/fx_freetype/src/../fxft2.5.01/src/base/ftobjs.c:1180



The fix: 


--- a/core/src/fxge/fx_freetype/fxft2.5.01/src/psaux/psconv.c
+++ b/core/src/fxge/fx_freetype/fxft2.5.01/src/psaux/psconv.c
@@ -202,7 +202,7 @@
     FT_INT64  integral = 0;
     FT_INT64  decimal = 0;
 #else
-       FT_Long integral;
+       FT_Long integral = 0;
        FT_Long decimal = 0;
        FT_Int temp0 = 65536;
        FT_Int temp1 = power_ten;


What is the expected output? What do you see instead?

msan and valgrind should be silent

What version of the product are you using? On what operating system?


Please provide any additional information below.

fresh trunk, x86_64 linux

What steps will reproduce the problem?
Currently, there is no API in pdfium that provides all the named destinations 
and the associated page numbers. 

There is an existing API - PDFiumEngine::GetNamedDestinationPage() - that 
returns page number for a particular destination. But to support nameddest open 
pdf parameter in OOP PDF, using this API can cause race condition while setting 
up the viewport because of use of asynchronous messages between plugin and page.

Another possible use case (for example) for such an API is when we want to 
extend UI and show list of all named destinations.

For more info, please see :
https://codereview.chromium.org/535823005/

What is the expected output? What do you see instead?
It will be useful to have such an API as there is none as of now.

What version of the product are you using? On what operating system?
Linux/Chrome/39.0.2166.0

Please provide any additional information below.

What steps will reproduce the problem?
1. View pdf in browser; renders with a pink/magenta cast.

What is the expected output? What do you see instead?
Shouldn't have pink/magenta cast.

What version of the product are you using? On what operating system?
Viewing on Mac OS 10.9.4 using google chrome 36.0.1985.125.

Please provide any additional information below.
Pdf renders properly in firefox 30.0 + safari 7.0.5 on the mac.

The anti-pattern

     m_pAltCS->GetRGB(results, R, G, B);
     return TRUE;

occurs frequently in fpdf_page_colors.cpp.  These should be changed to

     return m_pAltCS->GetRGB(results, R, G, B);

to propagate errors to callers.

There's an interesting difference between CFX_Font::LoadFile(IFX_FileRead* 
pFile):

    FXFT_Set_Pixel_Sizes(m_Face, 0, 64);

and FT_LoadFont(FX_LPBYTE pData, int size):

    error = FXFT_Set_Pixel_Sizes(face, 64, 64);

I guess LoadFile() should also pass 64 for the width.

What steps will reproduce the problem?

run "valgrind --track-origins=yes ./out/Release/pdfium_test 23.pdf"
or build pdfium_test with msan from the chromium tree 
(http://www.chromium.org/developers/testing/memorysanitizer)
and run "./out/Release/pdfium_test 23.pdf"

==17269== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7ff044db4aa4 in get_dqt third_party/pdfium/core/src/fxcodec/libjpeg/fpdfapi_jdmarker.c:559
    #1 0x7ff044db4aa4 in read_markers third_party/pdfium/core/src/fxcodec/libjpeg/fpdfapi_jdmarker.c:1067
    #2 0x7ff044dab11e in consume_markers third_party/pdfium/core/src/fxcodec/libjpeg/fpdfapi_jdinput.c:297
    #3 0x7ff044da962c in FPDFAPIJPEG_jpeg_consume_input third_party/pdfium/core/src/fxcodec/libjpeg/fpdfapi_jdapimin.c:302
    #4 0x7ff044da9218 in FPDFAPIJPEG_jpeg_read_header third_party/pdfium/core/src/fxcodec/libjpeg/fpdfapi_jdapimin.c:250
    #5 0x7ff044ba0e38 in _JpegLoadInfo(unsigned char const*, unsigned int, int&, int&, int&, int&, int&, unsigned char**, unsigned int*) third_party/pdfium/core/src/fxcodec/codec/fx_codec_jpeg.cpp:309
    #6 0x7ff044ba06c1 in CCodec_JpegModule::LoadInfo(unsigned char const*, unsigned int, int&, int&, int&, int&, int&, unsigned char**, unsigned int*) third_party/pdfium/core/src/fxcodec/codec/fx_codec_jpeg.cpp:569
    #7 0x7ff044ae24db in CPDF_DIBSource::CreateDecoder() third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:596
    #8 0x7ff044adc2e9 in CPDF_DIBSource::StartLoadDIBSource(CPDF_Document*, CPDF_Stream const*, int, CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:361
    #9 0x7ff044ac5541 in CPDF_ImageCache::StartGetCachedBitmap(CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int, CPDF_RenderStatus*, int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:310
    #10 0x7ff044ac4ec4 in CPDF_PageRenderCache::StartGetCachedBitmap(CPDF_Stream*, int, unsigned int, int, CPDF_RenderStatus*, int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:131
    #11 0x7ff044af3d7d in CPDF_ProgressiveImageLoaderHandle::Start(CPDF_ImageLoader*, CPDF_ImageObject const*, CPDF_PageRenderCache*, int, unsigned int, int, CPDF_RenderStatus*, int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1437
    #12 0x7ff044af50f2 in CPDF_ImageLoader::StartLoadImage(CPDF_ImageObject const*, CPDF_PageRenderCache*, void*&, int, unsigned int, int, CPDF_RenderStatus*, int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1497
    #13 0x7ff044acc8c8 in CPDF_ImageRenderer::StartLoadDIBSource() third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:371
    #14 0x7ff044ac70b2 in CPDF_ImageRenderer::Start(CPDF_RenderStatus*, CPDF_PageObject const*, CFX_Matrix const*, int, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:525
    #15 0x7ff044ab5017 in CPDF_RenderStatus::ContinueSingleObject(CPDF_PageObject const*, CFX_Matrix const*, IFX_Pause*) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render.cpp:350
    #16 0x7ff044ac1256 in CPDF_ProgressiveRenderer::Continue(IFX_Pause*) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1175
    #17 0x7ff044abfdbc in CPDF_ProgressiveRenderer::Start(CPDF_RenderContext*, CFX_RenderDevice*, CPDF_RenderOptions const*, IFX_Pause*, int) third_party/pdfium/core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1114
    #18 0x7ff0448749db in FPDF_RenderPage_Retail(CRenderContext*, void*, int, int, int, int, int, int, int, IFSDK_PAUSE_Adapter*) third_party/pdfium/fpdfsdk/src/fpdfview.cpp:835
    #19 0x7ff044875339 in FPDF_RenderPageBitmap third_party/pdfium/fpdfsdk/src/fpdfview.cpp:633
    #20 0x7ff04486da34 in RenderPdf(char const*, char const*, unsigned long, bool) third_party/pdfium/samples/pdfium_test.cc:239
    #21 0x7ff04486efc7 in main third_party/pdfium/samples/pdfium_test.cc:300
    #22 0x7ff0432a776c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #23 0x7ff04486be8c in _start (/usr/local/google/kcc/chromium/src/out/Release/pdfium_test+0x15ae8c)

  Uninitialized value was created by an allocation of 'jerr' in the stack frame of function '_JpegLoadInfo(unsigned char const*, unsigned int, int&, int&, int&, int&, int&, unsigned char**, unsigned int*)'
    #0 0x7ff044ba0730 in _JpegLoadInfo(unsigned char const*, unsigned int, int&, int&, int&, int&, int&, unsigned char**, unsigned int*) third_party/pdfium/core/src/fxcodec/codec/fx_codec_jpeg.cpp:276



The following patch fixes the problem:
diff --git a/core/src/fxcodec/codec/fx_codec_jpeg.cpp 
b/core/src/fxcodec/codec/fx_codec_jpeg.cpp
index 5e78e13..33afcc2 100644
--- a/core/src/fxcodec/codec/fx_codec_jpeg.cpp
+++ b/core/src/fxcodec/codec/fx_codec_jpeg.cpp
@@ -282,6 +282,7 @@ static FX_BOOL _JpegLoadInfo(FX_LPCBYTE src_buf, FX_DWORD 
src_size, int& width,
     jerr.output_message = _error_do_nothing;
     jerr.format_message = _error_do_nothing2;
     jerr.reset_error_mgr = _error_do_nothing;
+    jerr.trace_level = 0;
     cinfo.err = &jerr;
     jmp_buf mark;
     cinfo.client_data = &mark;



What is the expected output? What do you see instead?

msan and valgrind should be silent

What version of the product are you using? On what operating system?

Fresh trunk on linux x86_64

What steps will reproduce the problem?
1.compile pdfium with Microsoft Visual C++ 2010 Express

reason,
This header is a part of the MFC Library. VS Express edition doesn't contain 
MFC.

solution,

#ifdef _MFC_VER
    #include "afxres.h"
#else
    #include <windows.h>
#endif

At head

fxge currently removes NOMINMAX from defines in pdfium.gyp

safe_conversions_impl added recently uses numeric_limits::max() and 
numeric_limits::min() resulting in errors like

e:\b\build\slave\win\build\src\third_party\pdfium\third_party\numerics\safe_conv
ersions_impl.h(152) : error C2220: warning treated as error - no 'object' file 
generated
e:\b\build\slave\win\build\src\third_party\pdfium\third_party\numerics\safe_conv
ersions_impl.h(152) : warning C4003: not enough actual parameters for macro 
'max'
e:\b\build\slave\win\build\src\third_party\pdfium\third_party\numerics\safe_conv
ersions_impl.h(153) : warning C4003: not enough actual parameters for macro 
'max'


Removing the undef of NOMINXMAX results in

FAILED: ninja -t msvc -e environment.x86 -- 
"d:\src\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo 
/showIncludes /FC 
@obj\third_party\pdfium\core\src\fxge\win32\fxge.fx_win32_gdipext.obj.rsp /c 
..\..\third_party\pdfium\core\src\fxge\win32\fx_win32_gdipext.cpp 
/Foobj\third_party\pdfium\core\src\fxge\win32\fxge.fx_win32_gdipext.obj 
/Fdobj\third_party\pdfium\fxge.cc.pdb
d:\src\depot_tools\win_toolchain\vs2013_files\win8sdk\include\um\gdiplustypes.h(
475) : error C3861: 'min': identifier not found
d:\src\depot_tools\win_toolchain\vs2013_files\win8sdk\include\um\gdiplustypes.h(
476) : error C3861: 'min': identifier not found

so one or the other is going to need to be changed.

What steps will reproduce the problem?
1. Update an object (having object number N) 65534 times, then free it
2. Load the document in PDFium
3. All objects after N are shifted down one position

(Step 1 can be sped up by using editing the file directly or using a
PDF creator that uses generation number 65535 for free objects to
prevent objects from being reused or for whatever reason.)

What is the expected output? What do you see instead?

Expected: The attached document shows the test "ABC" on the first (and only) 
page.
Observed: Blank page.

What version of the product are you using? On what operating system?

git tag 6c673585ed6bcb9e330ea5ab716f496c5d5f37b4 of PDFium
Linux x86_64

Please provide any additional information below.

"0000000000 65535 f" is a perfectly valid xref table entry. There are some
broken PDF files which do have an extra xref entry of that type, requiring
shifting the xref table entries down. However, PDFium does that in too
many cases and breaks documents in the process. The broken documents I've
seen have an xref table starting at object number 1 with "0000000000 65535 f"
(which is what the xref table entry for object 0 should look like). You might
want to peek at the object pointed to by the next non-free object and compare
the object numbers (the index into the xref table and the object number found
in the actual object) to see if they differ by one.

1. Open the document attached.
2. Select the sentence "De onroerende-zaakbelastingen zijn belastingen 
voor de eigenaar van een woning of bedrijfs-pand en voor de huurder/gebruiker 
van een 
bedrijfspand." under the heading "Onroerende-zaakbelastingen (OZBE en OZBG)"
3. Open context menu with right click

You will see no copy text item in the menu. If you select a text without a 
hyphen, the "copy" menu item will appear in the context menu.

Mac OS X 10.9.3, Chrome 37.0.2008.2 dev

It seems like an unnecessary burden to continue to maintain this code given the 
alternatives.

Currently, Pdfium exposes FPDF_LoadDocument(path) and 
FPDF_LoadMemDocument(buffer), but those 2 should really be just convenience 
wrappers on top of a more fundamental FPDF_LoadDocument(fd).

Pdfium should accept the PDF to be given as:
- a buffer
- a file (with path or fd)
- a stream (fd works, except have to make sure it never calls seek... there may 
be an issue here with protected PDFs)

For information, currently, we have added our own FPDF_LoadFdDocument(fd) as 
this (on Android's Google PDF Viewer):

// Patch on Foxit's File reader class to accept a FD directly.
class FdAccess: public CFXCRT_FileAccess_Posix {
 public:
  using CFXCRT_FileAccess_Posix::Open;
  bool Open(int fd) {
    m_nFD = fd;
    return true;
  }
};

FPDF_DOCUMENT Document::LoadFdDocument(int fd, const char* password) {
  IFX_FileRead* fdReader = CreateFileRead(fd);

  // The rest of the method id copied from FPDF_LoadDocument
  CPDF_Parser* pParser = new CPDF_Parser;
  pParser->SetPassword(password);

  FX_DWORD err_code = pParser->StartParse(fdReader);
  if (err_code) {
    delete pParser;
    ProcessParseError(err_code);
    // TODO(tlb): This is not safe at all. Take a new fd instead.
    lseek(fd, 0, SEEK_SET);
    return NULL;
  }
  return pParser->GetDocument();
}

IFX_FileRead* Document::CreateFileRead(int fd) {
  // Adapted from FX_CreateFileStream
  FdAccess* pFA = new FdAccess;
  if (!pFA) {
      return NULL;
  }
  if (!pFA->Open(fd)) {
      pFA->Release();
      return NULL;
  }
  return FX_NEW CFX_CRTFileStream(pFA);
}

Hello

When I build project using VS 2010, I have an issue: 
http://pastebin.com/gWQ4gWRR.

I discover that it comes from [cceb554] commit and connected with FT_Vector 
font_offset initialization.

It works right when struct inits that way:

FT_Vector               font_offset = {0, 0};

I attached path for this issue.
Sorry for my English :)

What steps will reproduce the problem?
1. Build pdfium for android

What is the expected output? What do you see instead?

Binaries of pdfium for android?

What version of the product are you using? On what operating system?

Lastest development version

Please provide any additional information below.

I want to build pdfium for android. 
Could you please update the wiki with instructions?

Thank you very much.

Now CPDF_Bookmark::GetDest supports only document outlines with direct 
destinations.
But many docs have Go-To actions in outlines instead of destination. This patch 
adds action support to the function.

What steps will reproduce the problem?
1. Open a PDF file containing text in Chrome, e.g. 
http://www.adobe.com/enterprise/accessibility/pdfs/acro6_pg_ue.pdf
2. Double-click and drag on some text in a paragraph

What is the expected output?
Text is selected by words, which is the standard behavior on Linux. 
e.g. consider the text "Lorem ipsum dolor sit amet, consectetur adipisicing 
elit"
Then if you double-click-and-drag from the middle of "dolor" to the middle of 
"consectetur", then the selection will be "Lorem ipsum [dolor sit amet, 
consectetur] adipisicing elit".

What do you see instead?
Only the first word clicked is selected; the drag is ignored.

What version of the product are you using? On what operating system?
The versions in
Google Chrome   35.0.1916.153 (Official Build 274914)
and
Google Chrome   36.0.1985.84 (Official Build 277917) beta
on my Ubuntu workstation.