wwxxyx / pdfium Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/pdfium
Automatically exported from code.google.com/p/pdfium
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);
Original issue reported on code.google.com by [email protected]
on 27 Aug 2014 at 11:43
Original issue reported at
https://code.google.com/p/chromium/issues/detail?id=321681
Original issue reported on code.google.com by [email protected]
on 28 May 2014 at 6:00
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 6 Aug 2014 at 8:53
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
Original issue reported on code.google.com by [email protected]
on 10 Jul 2014 at 6:44
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.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2014 at 2:00
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 25 May 2014 at 8:08
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).
Original issue reported on code.google.com by [email protected]
on 29 Jul 2014 at 4:49
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 4 Jun 2014 at 1:10
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2014 at 11:38
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 11 Jun 2014 at 6:31
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
Original issue reported on code.google.com by [email protected]
on 4 Jun 2014 at 1:56
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2014 at 7:42
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.
Original issue reported on code.google.com by [email protected]
on 24 Jun 2014 at 11:02
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 12 Aug 2014 at 6:30
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 1 Jul 2014 at 12:21
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
Original issue reported on code.google.com by [email protected]
on 22 Aug 2014 at 7:02
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 24 Jul 2014 at 11:22
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);
}
Original issue reported on code.google.com by [email protected]
on 19 Sep 2014 at 2:09
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 on code.google.com by [email protected]
on 4 Aug 2014 at 7:18
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 10 Aug 2014 at 10:18
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.
Original issue reported on code.google.com by [email protected]
on 23 Jul 2014 at 6:16
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 1 Sep 2014 at 2:43
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 22 May 2014 at 2:42
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
Original issue reported on code.google.com by [email protected]
on 27 May 2014 at 5:43
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.
Original issue reported on code.google.com by [email protected]
on 30 Jul 2014 at 4:09
It seems like an unnecessary burden to continue to maintain this code given the
alternatives.
Original issue reported on code.google.com by [email protected]
on 15 Aug 2014 at 5:19
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.
Original issue reported on code.google.com by [email protected]
on 4 Aug 2014 at 10:51
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
Original issue reported on code.google.com by [email protected]
on 21 Jul 2014 at 8:03
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 23 Jun 2014 at 12:46
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 21 May 2014 at 7:30
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
Original issue reported on code.google.com by [email protected]
on 13 Aug 2014 at 10:23
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
Original issue reported on code.google.com by [email protected]
on 24 Jun 2014 at 7:26
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2014 at 10:53
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.
Original issue reported on code.google.com by [email protected]
on 28 Jun 2014 at 9:13
Attachments:
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.
Original issue reported on code.google.com by xtrochu
on 27 Jun 2014 at 6:58
Attachments:
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 :)
Original issue reported on code.google.com by [email protected]
on 9 Jul 2014 at 12:35
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 31 Jul 2014 at 11:55
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.
Original issue reported on code.google.com by [email protected]
on 24 May 2014 at 1:02
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.
Original issue reported on code.google.com by [email protected]
on 24 Jun 2014 at 7:57
Attachments:
I'm trying to roll pdfium here: https://codereview.chromium.org/432173002/
PDFExtensionTest.BasicPlugin is failing consistently on mac_chromium_rel
Original issue reported on code.google.com by [email protected]
on 1 Aug 2014 at 11:26
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.
Original issue reported on code.google.com by [email protected]
on 20 Jun 2014 at 6:00
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
Original issue reported on code.google.com by [email protected]
on 4 Aug 2014 at 7:38
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 23 Sep 2014 at 2:00
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.
"
Original issue reported on code.google.com by [email protected]
on 17 Aug 2014 at 5:43
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
Original issue reported on code.google.com by [email protected]
on 28 May 2014 at 9:38
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2014 at 11:50
Please review the attached patch. It fixes two potential resource leaks in
fpdfsdk/src/javascript/Document.cpp.
Best regards and many thanks
Martin Ettl
Original issue reported on code.google.com by [email protected]
on 13 Jun 2014 at 11:55
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 16 Aug 2014 at 12:10
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
Original issue reported on code.google.com by [email protected]
on 25 Jun 2014 at 9:38
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 28 May 2014 at 11:49
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.