mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-25 01:28:06 +02:00
Code Activity
11210 commits 1 branch 93 tags 289 MiB
Commit graph

87 commits

Author SHA1 Message Date
Jonas Jenwald
95e5bad4c4 Attempt to find truncated endstream commands, in the fallback code-path, in Parser.makeStream (issue 10004) 
Apparently there's some PDF generators, in this case the culprit is "Nooog Pdf Library / Nooog PStoPDF v1.5", that manage to mess up PDF creation enough that endstream[1] commands actually become truncated.

*Please note:* The solution implemented here isn't perfect, since it won't be able to cope with PDF files that contains a *mixture* of correct and truncated endstream commands.
However, considering that this particular mode of corruption *fortunately* doesn't seem very common[2], a slightly less complex solution ought to suffice for now.

Fixes 10004.

---
[1] Scanning through the PDF data to find endstream commands becomes necessary, in order to determine the stream length in cases where the `Length` entry of the (stream) dictionary is missing/incorrect.

[2] I cannot recall having seen any (previous) issues/bugs with "Missing endstream" errors.
 2018-08-26 11:51:11 +02:00
Jonas Jenwald
c81cbe113c Extract the "scanning for endstream command" part of Parser.makeStream into a helper method 
With this code now living in a separate method, it can be simplified slightly (e.g. by using early returns).
 2018-08-26 11:51:09 +02:00
Jonas Jenwald
6bbcafcd26 Let Lexer.getNumber treat a single decimal point as zero (issue 9252) 
This is consistent with the behaviour in Adobe Reader.
 2018-06-20 13:41:21 +02:00
Jonas Jenwald
df4799a12a Ensure that line-breaks are *only* skipped after operators in Lexer.getNumber (PR 8359 follow-up) 
With the current code line-breaks are accepted not just after an operator, but after a decimal point as well. When looking at this again, the latter case seems prone to cause false positives and might also interfere with subsequent patches.

Hence this is code is adjusted to actually do what the original commit message says, and nothing more.
 2018-06-20 13:41:15 +02:00
Jonas Jenwald
4b69bb7fe9 Add a TESTING build option, to enable using non-production/test-only code-paths 
Since the tests (currently) run with the `pdf.worker.js` file built, i.e. with `PRODUCTION = true` set, there's no simple way to add e.g. `assert` calls for both non-production *and* test-only builds without also affecting PRODUCTION builds.
 2018-06-12 11:01:32 +02:00
Jonas Jenwald
f05e5c5460 Take the dictionary, and not just the image data, into account when caching inline images (issue 9398) 
The reason for the bug is that we're only computing a checksum of the image data itself, but completely ignore the inline dictionary. The latter is important, since in practice it's not uncommon for inline images to be identical but use e.g. different ColourSpaces.

There's obviously a couple of different ways that we could compute a hash/checksum of the dictionary.
Initially I tried using `MurmurHash3_64` to compute a hash of the keys/values in the dictionary. Unfortunately this approach turned out to be *way* too slow in practice, especially for PDF files with a huge number of inline images; in particular issue 2618 would regresses quite badly with this solution.

The solution that is instead implemented in this patch, is to compute a checksum of the dictionary contents. While this is a much simpler, not to mention a lot more efficient, solution there's one drawback associated with it:
If the contents of inline image dictionaries are ordered differently, they will not be considered equal with this approach which could thus lead to failures to cache repeated inline images. In practice this doesn't seem to be a problem in any of the PDF files I've tested, and generally I'd rather err on the side of *not* caching given that too aggressive caching can easily lead to rendering bugs.

One small, but somewhat annoying, complication is that by the time `Parser.makeInlineImage` is called, we no longer know the *exact* stream position where the inline image dictionary starts. Having access to that information is crucial here, and the easiest solution I could come up with is to track this in the current `Lexer` instance.[1]

With the patch, we're thus able to fix the referenced issues without incurring large regressions in problematic cases such as issue 2618.

Fixes 9398; also improves/fixes the `issue8823` reference test.

---

[1] Obviously I'd have preferred if this patch could be limited to `Parser.makeInlineImage`, without the need for this "hack", but I'm not sure what that'd look like here.
 2018-02-12 16:43:47 +01:00
Jonas Jenwald
36593d6bbc Move JpegStream and JpxStream to their own files 2017-11-11 11:22:16 +01:00
Max Schaefer
bc8f673522 Remove spurious arguments to NullStream constructor. 2017-11-03 10:14:32 +00:00
Jonas Jenwald
bb35095083 Move CCITTFaxStream and Jbig2Stream, from src/core/stream.js, to separate files 2017-10-24 12:00:40 +02:00
Jonas Jenwald
eece66fa3e For /Filter entries containing Names, ignore the /DecodeParms entry if it contains an Array (issue 8895) 2017-09-15 23:02:16 +02:00
Jonas Jenwald
cfb4955a92 Replace the isArray helper function with the native Array.isArray function 
*Follow-up to PR 8813.*
 2017-09-01 20:27:13 +02:00
Jonas Jenwald
11408da340 Replace the isInt helper function with the native Number.isInteger function 
*Follow-up to PR 8643.*
 2017-09-01 16:52:50 +02:00
Jonas Jenwald
49b8cd5a6a Attempt to improve the EI detection heuristics, for inline images, in streams containing NUL bytes (issue 8823) 
Since this patch will now treat (some) `NUL` bytes as "ASCII", the number of `followingBytes` checked are thus increased to (hopefully) reduce the risk of introducing new false positives.

Fixes 8823.
 2017-08-27 12:48:28 +02:00
Jonas Jenwald
cb55506b95 Try to recover if we reach the end of the stream when searching for the EI marker of an inline image (issue 8798) 2017-08-22 09:33:13 +02:00
Jonas Jenwald
2112999db7 Fix caching of small inline images in Parser.makeInlineImage (issue 8790) 
*Follow-up to PR 5445.*

Using the PDF file from issue 2618, i.e. http://bugzilla-attachments.gnome.org/attachment.cgi?id=226471, with the following manifest file:
```json
[
    {  "id": "issue2618",
       "file": "../web/pdfs/issue2618.pdf",
       "md5": "",
       "rounds": 50,
       "type": "eq"
    }
]
```
I get the following results when comparing `master` against this patch:
```
browser | stat         | Count | Baseline(ms) | Current(ms) |  +/- |     %  | Result(P<.05)
------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | -------------
firefox | Overall      |    50 |         4694 |        3974 | -721 | -15.35 |        faster
firefox | Page Request |    50 |            2 |           1 |    0 | -22.83 |
firefox | Rendering    |    50 |         4692 |        3972 | -720 | -15.35 |        faster
```

So, based on these results, it seems like a fairly clear win to fix this broken caching :-)
 2017-08-18 23:08:55 +02:00
Yury Delendik
d028c26210 Removes error() 2017-07-07 09:40:24 -05:00
Jonas Jenwald
ea71d23f74 Fix a stupid spelling error in the ASCII85Decode name in Parser.makeInlineImage (issue 8613) 
This is a trivial follow-up to PR 5383, and it's a bit strange that this has been wrong since late 2014 without anyone noticing (maybe because inline images aren't too common).
So, apparently code works better if you actually spell correctly, who knew ;-)

Fixes 8613.
 2017-07-05 19:43:09 +02:00
Jonas Jenwald
a8c87f8019 Fix inconsistent spacing and trailing commas in objects in src/core/ files, so we can enable the comma-dangle and object-curly-spacing ESLint rules later on 
*Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.*

http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing

Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead.

Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.

```diff
diff --git a/src/core/evaluator.js b/src/core/evaluator.js
index abab9027..dcd3594b 100644
--- a/src/core/evaluator.js
+++ b/src/core/evaluator.js
@@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() {
     t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, };
     t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, };
     t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, };
-    t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, };
+    t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1,
+                variableArgs: false, };
     t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, };
     t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, };
     t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, };
diff --git a/src/core/jbig2.js b/src/core/jbig2.js
index 5a17d482..71671541 100644
--- a/src/core/jbig2.js
+++ b/src/core/jbig2.js
@@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() {
      { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, },
      { x: -1, y: 0, }],
     [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, },
-     { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }]
+     { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, },
+     { x: -1, y: 0, }]
   ];

   var RefinementTemplates = [
     {
       coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }],
-      reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, },
-                  { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }],
+      reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, },
+                  { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, },
+                  { x: 0, y: 1, }, { x: 1, y: 1, }],
     },
     {
-      coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }],
-      reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, },
-                  { x: 0, y: 1, }, { x: 1, y: 1, }],
+      coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, },
+               { x: -1, y: 0, }],
+      reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, },
+                  { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }],
     }
   ];
```
 2017-06-02 11:20:19 +02:00
Jonas Jenwald
982b6aa65b Convert the files in the /src/core folder to ES6 modules 
Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
 2017-05-30 22:06:21 +02:00
Jonas Jenwald
40feca12c1 Ignore line-breaks between operator and digit in Lexer.getNumber 
This is consistent with the behaviour in Adobe Reader (and PDFium), and it fixes the display of page 30 in https://bug1354114.bmoattachments.org/attachment.cgi?id=8855457 (taken from https://bugzilla.mozilla.org/show_bug.cgi?id=1354114).

The patch also makes the `error` message for invalid numbers slightly more useful, by including the charCode as well. (Having that information available would have reduced the time spent on debugging the PDF file above.)
 2017-05-02 20:59:42 +02:00
Jonas Jenwald
afc74b0178 Enable the object-shorthand ESLint rule in src/shared 
Please see http://eslint.org/docs/rules/object-shorthand.

For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
 2017-04-27 17:29:40 +02:00
Jonas Jenwald
23c62cc321 Consume the current character when encountering illegal characters in Lexer.getObject, in order to prevent infinite loops during reading of streams (issue 8061) 
*Please note:* The rendering of the PDF file in issue 8061 first regressed in PR 7039, and then PR 7493 exacerbated the problem even further by causing an infinite loop.

In this particular case, when errors were encountered inside of the `Lexer.getObject` method *itself*, we didn't advance the stream position. This thus caused an inifinite loop in `parseCMap`, since the exact same character was then parsed over and over again.

Fixes 8061.
 2017-02-11 19:32:48 +01:00
Jonas Jenwald
50c2856097 Move EOF/isEOF from core/parser.js to core/primitives.js 
Given the nature of `EOF` and `isEOF`, it seems to me that they really ought to be placed in `core/primitives.js` instead.

In general, it doesn't seem great to have to depend on the entire `core/parser.js` file for such simple primitives/helper functions.
In particular, while `core/ps_parser.js` is completely separate from `core/parser.js` with regards to its function, it still depends on the latter for just *one* primitive.

Note that compared to e.g. PR 7389, this will not reduce the number of dependencies for `core/ps_parser`, however the new dependency IMHO makes more sense.
 2017-01-27 13:37:48 +01:00
Jonas Jenwald
2f3805efbc Switch to using ESLint, instead of JSHint, for linting 
*Please note that most of the necessary code adjustments were made in PR 7890.*

ESLint has a number of advantageous properties, compared to JSHint. Among those are:
 - The ability to find subtle bugs, thanks to more rules (e.g. PR 7881).
 - Much more customizable in general, and many rules allow fine-tuned behaviour rather than the just the on/off rules in JSHint.
 - Many more rules that can help developers avoid bugs, and a lot of rules that can be used to enforce a consistent coding style. The latter should be particularily useful for new contributors (and reduce the amount of stylistic review comments necessary).
 - The ability to easily specify exactly what rules to use/not to use, as opposed to JSHint which has a default set. *Note:* in future JSHint version some of the rules we depend on will be removed, according to warnings in http://jshint.com/docs/options/, so we wouldn't be able to update without losing lint coverage.
 - More easily disable one, or more, rules temporarily. In JSHint this requires using a numeric code, which isn't very user friendly, whereas in ESLint the rule name is simply used instead.

By default there's no rules enabled in ESLint, but there are some default rule sets available. However, to prevent linting failures if we update ESLint in the future, it seemed easier to just explicitly specify what rules we want.
Obviously this makes the ESLint config file somewhat bigger than the old JSHint config file, but given how rarely that one has been updated over the years I don't think that matters too much.

I've tried, to the best of my ability, to ensure that we enable the same rules for ESLint that we had for JSHint. Furthermore, I've also enabled a number of rules that seemed to make sense, both to catch possible errors *and* various style guide violations.

Despite the ESLint README claiming that it's slower that JSHint, https://github.com/eslint/eslint#how-does-eslint-performance-compare-to-jshint, locally this patch actually reduces the runtime for `gulp` lint (by approximately 20-25%).

A couple of stylistic rules that would have been nice to enable, but where our code currently differs to much to make it feasible:
 - `comma-dangle`, controls trailing commas in Objects and Arrays (among others).
 - `object-curly-spacing`, controls spacing inside of Objects.
 - `spaced-comment`, used to enforce spaces after `//` and `/*. (This is made difficult by the fact that there's still some usage of the old preprocessor left.)

Rules that I indend to look into possibly enabling in follow-ups, if it seems to make sense: `no-else-return`, `no-lonely-if`, `brace-style` with the `allowSingleLine` parameter removed.

Useful links:
 - http://eslint.org/docs/user-guide/configuring
 - http://eslint.org/docs/rules/
 2016-12-16 21:06:36 +01:00
Jonas Jenwald
28e50cfa21 Fix errors reported by the space-infix-ops ESLint rule 
http://eslint.org/docs/rules/space-infix-ops
 2016-12-12 20:36:00 +01:00
Jonas Jenwald
b4ac6bd2f6 Ensure that we resolve indirect objects in Filter and DecodeParms arrays in parser.js 
I've not actually, thus far, come across a PDF file that this patch fixes. However, given the string of recent patches that has fixed issues with indirect objects in arrays, I think that it makes sense to proactively avoid any issues in this code.
 2016-12-08 11:55:08 +01:00
Jonas Jenwald
c8f83d6487 Let Parser_makeFilter pass in the DecodeParms data to various image Streams, instead of re-fetching it in various [...]Stream.prototype.ensureBuffer methods 
In `Parser_filter` the `DecodeParms` data is fetched and passed to `Parser_makeFilter`, where we also make sure that a `Ref` is resolved to a direct object.
We can thus pass this along to the various image `Stream` constructors, to avoid the current situation where we lookup/resolve data that is already available.
Note also that we currently do *not* handle the case where `DecodeParms` is an Array entirely correct in the various image `Stream`s, and this patch fixes that for free.
 2016-10-15 12:09:51 +02:00
Yury Delendik
7b2a9ee4e0 Merge pull request #7670 from Snuffleupagus/Parser_makeFilter-maybeLength 
Only skip parsing a stream in `Parser_makeFilter` when we know for sure that it is empty (PR 6372 follow-up)
 2016-10-05 10:38:12 -05:00
Jonas Jenwald
116ba19dd9 Respect the 'ColorTransform' entry in the image dictionary when decoding JPEG images (bug 956965, issue 6574) 
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=956965.
Fixes 6574.
 2016-09-26 21:55:43 +02:00
Jonas Jenwald
a22f0ae820 Only skip parsing a stream in Parser_makeFilter when we know for sure that it is empty (PR 6372 follow-up) 
For PDF files with multiple `/Filter`s, where the `/Length` entry is zero, we fail to render the file correctly. The reason is that `maybeLength` is `null` for the every filter except the first, and `!maybeLength` is thus truthy.
Hence it seems that we should completely ignore the `/Length` entry and also explicitly check `maybeLength === 0`.

Note that I've not (yet) come across a PDF file with this issue in the wild, but given all the stupid things PDF generators do I wouldn't be surprised if such a file actually exists. In order to prevent a possible future bug, I'm submitting this patch which includes a hand-edited PDF file that we currently cannot render correctly (but e.g. Adobe Reader can).
 2016-09-25 12:40:15 +02:00
Jonas Jenwald
544d29f5cb Add a recoveryMode that suppresses errors from the Parser, and utilize it when searching for the main trailer in XRef_indexObjects (bug 1250079) 
Instead of having `Parser_getObj` fail unconditionally for the referenced PDF file, this patch attempts to let searching for the main trailer continue even if there are errors.

Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1250079.
 2016-08-17 12:37:35 +02:00
klemens
6f03f62327 trivial spelling fixes 2016-07-17 14:33:41 +02:00
Jonas Jenwald
a36a946976 Move the isSpace utility function from core/parser.js to shared/util.js 
Currently the `isSpace` utility function is a member of `Lexer`, which seems suboptimal, given that it's placed in `core/parser.js`. In practice, this means that in a number of `core/*.js` files we thus have an *otherwise* completely unnecessary dependency on `core/parser.js` for a one-line function.

Instead, this patch moves `isSpace` into `shared/util.js` which seems more appropriate for this kind of utility function. Not to mention that since all the affected `core/*.js` files already depends on `shared/util.js`, this doesn't incur any more file dependencies.
 2016-06-06 09:11:33 +02:00
Yury Delendik
6038c236b2 Removes core/stream circular dependency on core/parser. 2016-03-22 14:06:01 -05:00
Yury Delendik
825a2225ab Merge pull request #6915 from yurydelendik/lookuptables 
Refactor lookup hash tables/objects
 2016-01-28 15:01:06 -06:00
Yury Delendik
2edf2792dc Replaces literal {} created lookup tables with Object.create 2016-01-28 12:18:38 -06:00
Jonas Jenwald
15ce96a6eb Prevent failures in the "scanning for endstream" code, in Parser_makeStream, by handling the case where 'endstream' is split between contiguous chunks (issue 1536) 2016-01-26 09:03:51 +01:00
Yury Delendik
6b60c8f4db Adds UMD headers to core, display and shared files. 2015-12-15 13:24:39 -06:00
Jonas Jenwald
995e1a45b8 Ensure that Lexer_getName does not fail if a Name contains in invalid usage of the NUMBER SIGN (#) (issue 6692) 
*This is a regression from PR 3424.*

The PDF file in the referenced issue is using `Type3` fonts. In one of those, the `/CharProcs` dictionary contains an entry with the name `/#`. Before the changes to `Lexer_getName` in PR 3424, we were allowing certain invalid `Name` patterns containing the NUMBER SIGN (#).

It's unfortunate that this has been broken for close to two and a half years before the bug surfaced, but it should at least indicate that this is not a widespread issue.

Fixes 6692.
 2015-11-28 11:59:09 +01:00
Manas
a2ba1b8189 Uses editorconfig to maintain consistent coding styles 
Removes the following as they unnecessary
/* -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */
 2015-11-14 07:32:18 +05:30
Jonas Jenwald
b1d148a4aa Remove Parser_fetchIfRef since it's obsolete 
This code was added in PR 1214, but was made obsolete by PRs 1488/1493. Prior to the latter ones, `Dict_get` retured the raw objects. However, afterwards (and currently) `Dict_get` now resolves indirect objects, which makes `Parser_fetchIfRef` redundant.

*Potential risks with this patch:*
This patch passes all tests locally, but there's a *small* possibility that it could break some weird PDF files.
In the current code, wrapping `Dict_get` inside `Parser_fetchIfRef` will potentially mean two back-to-back call of `XRef_fetch`, if a reference points directly to another reference. I'm not sure if this can actually happen in practice, and I'd think that if that were the case we'd already have run into it elsewhere in the code-base, given that `Parser` is the only place where we try to "double" resolve references.
 2015-09-02 23:11:00 +02:00
Tim van der Meij
b42b894570 Merge pull request #6386 from Snuffleupagus/Parser_makeFilter-warn-on-empty-stream 
Add a warning when we encounter an empty stream in `Parser_makeFilter`
 2015-08-30 23:14:22 +02:00
Rob Wu
582573b96b Merge pull request #6358 from Snuffleupagus/Parser_tryShift-missingDataException 
Don't catch `MissingDataException` in `Parser_tryShift`
 2015-08-27 14:46:24 +02:00
Jonas Jenwald
f814fdc215 Add a warning when we encounter an empty stream in Parser_makeFilter 
Having a warning here would have meant that issue 6360 could have been solved in approximately five minutes, instead of an hour. To avoid that happening again, this patch adds a warning whenever we treat a stream as empty.
 2015-08-26 20:14:30 +02:00
Jonas Jenwald
5128603f64 Also check maybeLength when deciding if a stream is empty in Parser_makeFilter (issue 6360) 
The problem with the PDF files in the issue, besides the obviously broken XRef tables which we're able to recover from, is that many/most of the streams have Dictionaries where the `Length` entry is set to `0`. This causes us to return `NullStream`, instead of the appropriate one in `Parser_makeFilter`.

Fixes 6360.
 2015-08-20 23:04:18 +02:00
Jonas Jenwald
8c3b8238ac Don't catch MissingDataException in Parser_tryShift 
I overlooked this while reviewing PR 6197, but I don't think that we should be catching that particular kind of exception here; hence this patch.
 2015-08-16 11:35:54 +02:00
Jonas Jenwald
c718d1ab10 Ignore double negative in Lexer_getNumber (issue 6218) 
Basic mathematics would suggest that a double negative should always become positive, but it appears that Adobe Reader simply ignores that case. Hence I think that it makes sense for us to do the same.

Fixes 6218.
 2015-07-16 12:11:49 +02:00
Rob Wu
e211c25f06 Improve robustness of stream parser (invalid length) 
When the parser finds a stream, it retrieves the Length from the stream
dictionary and advances the lexer to the offset as specified in Length.
If this Length is incorrect, the lexer could end up anywhere.

When the lexer gets in an invalid state, it could throw errors. For
example, in issue 6108, the lexer ends up inside the stream data. This
stream has the ASCIIHexDecode filter, so all characters are made up from
ASCII characters, and the lexer interprets it as a command token. Tokens
cannot be longer than 127 bytes, so eventually 128 bytes are consumed
and the lexer throws "Command token too long" error.

Another possible error is "Illegal character: 41" when the lexer happens
to end up at a ')' due to the length mismatch.

These problems are solved by catching lexer errors and recovering the
parser via the existing stream length detection branch.
 2015-07-11 20:12:49 +02:00
Rob Wu
456ad438d8 Issue a warning instead of an error for long Names 
The PDF specification (cited below) specifies a maximum length of a name
in bytes as a minimal architectural limit. This means that PDF *writers*
should not create names that exceed 127 bytes.

It does not forbid PDF *readers* to accept such names though. These
names are only used internally to link PDF objects to other objects. For
these use cases, the lengths of the names do not really matter. Hence I
have changed the implementation to not treat long names as errors, but
warnings.

> (7.3.5) The length of a name shall be subject to an implementation
> limit; see Annex C.
>
> (Annex C.2) Table C.1 describes the minimum architectural limits that
> should be accommodated by conforming readers running on 32-bit
> machines. Because conforming readers may be subject to these limits,
> conforming writers producing PDF files should remain within them.
>
> (Table C.1) name 127 "Maximum length of a name, in bytes."

http://adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
 2015-07-10 16:10:24 +02:00
Jonas Jenwald
eac168f3cc Refactor searching for end of inline (EI) JPEG image streams 
This patch changes searching for EI image streams to rely on the EOI (end-of-image) marker for DCTDecode filters (i.e. JPEG images).
 2015-01-10 23:55:55 +01:00