Age | Commit message (Collapse) | Author |
|
VS 2015 RC ships without afxres.h, so fpdfsdkdll.rc fails to
compile. afxres.h is really intended for MFC apps so depending on
it is a bad idea anyway, so I changed both references to
windows.h. See http://stackoverflow.com/questions/1575559 for
some other perspective on this.
R=tsepez@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1078513002
|
|
Rolls DEPS to pull in the first windows-specific .png files, and
unsupresses the corresponding tests.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1072613003
|
|
There is not a code page (CP) used for converting unicode to mutli-bytes
if the coding scheme is CID coding. Only return 0 if CID can't be retrieved.
The difference on Windows and other platforms should be the function used
for converting rather than others.
BUG=466790
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1074653002
|
|
It turns out that 'timezone' has been deprecated for a while. If
deprecation messages are enabled then VS 2013 says this when 'timezone'
is referenced:
warning C4996: 'timezone': This function or variable may be unsafe.
Consider using _get_timezone instead.
Sometimes features stay deprecated for decades, but in this case
'timezone' is now gone.
R=tsepez@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1075673002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1066253002
|
|
R=jam@chromium.org
Review URL: https://codereview.chromium.org/1066413004
|
|
BUG=469244
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1062983002
|
|
Original CL was accidentally based off of XFA. This CL is
off of master.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1069553002
|
|
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1068013002
|
|
This also fixes some IWYU in dependent files.
BUG=https://code.google.com/p/pdfium/issues/detail?id=66
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1068993002
|
|
Move some typedefs for v8 types into fxjs_v8.h wrapper to
avoid circular inclusions. Also delete JS_Module.h, as no
other file includes it.
BUG=https://code.google.com/p/pdfium/issues/detail?id=66
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1060133002
|
|
TBR=tsepez@chromium.org
BUG=N/A
Review URL: https://codereview.chromium.org/1068513002
|
|
BUG=454595
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1053373002
|
|
Confirmed manually that:
g++ --std=c++0x -o /dev/null -I. ... -c fx_xxxxx.h
is now error-free for the files in this directory. Also kill
some ifndef's around inclusion since we know this doesn't
provide benefit with modern compilers.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1064433005
|
|
BUG=N/A
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1059233005
|
|
Extract a common portions for determining suppressions and comparing pngs.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1057983003
|
|
Adds a comment and changes some whitespace.
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1059373002
|
|
BUG=N/A
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1057383002
|
|
When there is a wrong keyword like '??ze' in the dictionary
of the trailer, PDFium can't recognize it and aborts further
parsing. After this change, PDFium continues even it can't
get the right size at this moment. It will rebuild the cross
reference table later since the size of the table is missing.
BUG=459580
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1055323003
|
|
MSAN reported this issue when I tried to reproduce 460936 in the last version of freetype on Linux.
BUG=N/A
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1050333002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1058463004
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=137
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1039063002
|
|
Review URL: https://codereview.chromium.org/1050693002
|
|
BUG=465322
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1045553004
|
|
Now that there's a win bot, this needs to be more careful.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1036073002
|
|
Needed to fix the failed pdfium_unittests on windows. Ironically,
I created these constants so I wouldn't mix up size_t's and off_t's
in these tests, but I didn't apply them consistently.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1036743005
|
|
There's investigation required to see why there are such
platform differences, but for now, a perpetually red bot
isn't useful.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1002283003
|
|
This involves bringing some of the suppressions file
mechanism into run_pixel_tests.py (making a common
module would be a nice follow-up)
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1032923002
|
|
This is required now that we have win/mac bots, which may produce
different outputs.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1031203003
|
|
TBR=halyavin@chromium.org
Review URL: https://codereview.chromium.org/1032853004
|
|
No-op CL intended to trigger a rebuild.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1036583002
|
|
The comment character is #.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1029193002
|
|
This is needed to green the tree without continually reverting the
pdfium_tests (corpus) repository.
We will need to make this more sophisticated at some point, but for
now, let's try to green the buildbot.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1016613004
|
|
This should make the test logs more readable.
Also give failure summary at end of tests, since searching
through the log is tedious.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1026903002
|
|
See http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn_rel/builds/5674
Testing this is a two-step process: land CL to pdfium, then try DEPS roll
in chromium against this version on the win8 trybots.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1004733006
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1023383003
|
|
Next attempt to get GN build to work. Once this lands, doing a DEPS
roll against the win8_chromium_gn_dbg trybot seems to catch the issue.
Restore image_diff_png.cc to its previous state.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1024243003
|
|
Build broken on trybot at
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel/builds/66012/steps/compile%20%28with%20patch%29/logs/stdio
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1026843002
|
|
Failures from last roll need diagnosis.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1023913002
|
|
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1020093002
|
|
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1021003002
|
|
There are two reasons for doing this. The first is that adding files
to this repository doesn't trigger a rebuild on the bot, so the next
unrelated pdfium change will be the one to hit any issues with the
unversioned corpus.
The second is that we may need a specific version of the expected output
files (.pngs) to go with a specific pdfium build.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1019783003
|
|
Follow on to https://codereview.chromium.org/990683002/.
This more closely mimics what fseek() actually does, so as
to avoid subtle bugs down the road.
Move the DecodeData struct into a header so the test can
use it, and provide a constructor for it.
Along the way, I added include guards, removed the p_
prefix from some non-pointer vars, fixed some IWYU, and
resolved some signed/unsigned comparison warnings with
careful casting.
BUG=452671
R=jun_fang@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/1016203002
|
|
This reverts commit de00893874a9d5ecae497e00511e2395fc2f02e8.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1017793003
|
|
This will be immediately reverted, but I need to be sure that the
previous change actually detects failures.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1008873005
|
|
Consequently, some of the tests may diff but the waterfall remains green.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1014083003
|
|
space is used"
This reverts commit 5a0e504d53195892458d819e52c62bea0c710bd5.
Original review URL https://codereview.chromium.org/1009513003
Reason for revert: New "corpus" tests show that this is no longer rendering some images. See, e.g. http://chromegw/i/client.pdfium/builders/linux/builds/144/steps/corpus%20tests/logs/stdio for those that diff'd.
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1016823003
|
|
Add a run_corpus_tests.py script to run pdfium_test against
the corpus tree.
Note that this differs from the run_pixel_tests.py script,
since pre-processing is not required. I'll work on unifying
these in a subsequent CL.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1010833003
|
|
Speculative because we still don't have pdfium buildbots for mac/win
on the pdfium waterfall. Nonetheless, the two build errors reported
in https://codereview.chromium.org/989213003/ seem to be a default
statement in a switch fully covering all of an enum constant, and
the use of <cstdint> instead of <stdint.h> on mac.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1011803003
|
|
There are two issues in this bug.
One is that JP2 image is not displayed because it aborts loading Jpx bitmap when the number of components in color space is different with that one in JPX images. I found that the number of components in color space isn't updated after it's initialized. For index color space, the component shall inherit from its base color space.
The second issue is that displayed color is not correct after I fixed the first issue. The root cause is that sRGB is used in JPX image, it doesn't need to map from index to RGB again.
BUG=464215
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1009513003
|