mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-26 10:08:06 +02:00
Code Activity
11028 commits 1 branch 93 tags 290 MiB
Commit graph

50 commits

Author SHA1 Message Date
Jonas Jenwald
47bf12cbac Change JpegImage._isColorConversionNeeded into a getter, rather than a regular function 
Given how `_isColorConversionNeeded` is used, and that it always returns a boolean value, having it be a getter seems more appropriate.
 2018-09-02 13:06:28 +02:00
Jonas Jenwald
682672db8e Change the signature of the JpegImage constructor, to allow passing in various options directly 2018-06-16 17:56:54 +02:00
Jonas Jenwald
83ff7d9de9 Simplify the DNL (Define Number of Lines) marker warning in JpegImage.parse 2018-05-30 22:40:11 +02:00
Jonas Jenwald
620f65488b Ignore the rest of the image when encountering an EOI (End of Image) marker while parsing Scan data (issue 9679) 2018-05-30 22:40:11 +02:00
Jonas Jenwald
11ab3b5c00 Ensure that JpegImage.getData returns the correct data length when forceRGBoutput == true (issue 4888) 
With PDF.js version `2.0` we'll only support browsers with built-in `TypedArray` functionality, hence there doesn't seem to be any good reason not to implement this now.

Fixes 4888.
 2018-02-13 20:44:21 +01:00
Jonas Jenwald
bf4166e6c9 Attempt to handle DNL (Define Number of Lines) markers when parsing JPEG images (issue 8614) 
Please refer to the specification, found at https://www.w3.org/Graphics/JPEG/itu-t81.pdf#page=49

Given how the JPEG decoder is currently implemented, we need to know the value of the scanLines parameter (among others) *before* parsing of the SOS (Start of Scan) data begins.
Hence the best solution I could come up with here, is to re-parse the image in the *hopefully* rare case of JPEG images that include a DNL (Define Number of Lines) marker.

Fixes 8614.
 2018-02-05 21:05:32 +01:00
Jonas Jenwald
f4a95de694 Attempt to find the next valid marker when encountering invalid image data in JpegImage.parse (issue 9425) 
In the JPEG images in the referenced PDF file, the DHT (Define Huffman Tables) segments contain more data than expected based on the length parameter.

Fixes 9425.
 2018-02-03 16:01:19 +01:00
Jonas Jenwald
c5700211d6 Adjust decodeACSuccessive in src/core/jpg.js to improve the rendering quality of (progressive) JPEG images 
I've been looking into the remaining point in 8637 about blurry images, to see if we could perhaps improve the rendering quality slightly there. After quite a bit of debugging, it seems that the issue is limited to certain progressive JPEG images.

As mentioned previously, I've got no detailed knowledge of the JPEG format, but this patch does seem to improve things quite a bit for the images in question.
Squinting at https://searchfox.org/mozilla-central/rev/6c33dde6ca02b389c52e8db3d22494df8b916f33/media/libjpeg/jdphuff.c#492-639, it seems reasonable that we should take the sign of the data into account. Furthermore, looking at the specification in https://www.w3.org/Graphics/JPEG/itu-t81.pdf#page=118, the "F.2.4.3 Decoding the binary decision sequence for non-zero DC differences and AC coefficients" section even contains a description of this (even though I cannot claim to really understand the details).
 2017-12-30 15:24:09 +01:00
Jonas Jenwald
d6eed132e5 Correct the indentation in the switch statement in decodeACSuccessive in src/core/jpg.js 2017-12-30 15:22:30 +01:00
Jonas Jenwald
d6cd5355f0 Use Uint8ClampedArray, when returning data, and remove manual clamping in src/core/jpg.js (issue 4901) 
This patch removes the `clamp0to255` helper function, as well as manual clamping code in `src/core/jpg.js`.
The adjusted constants in `_convertCmykToRgb` were taken from CMYK to RGB conversion code found in `src/core/colorspace.js`.

*Please note:* There will be some very slight movement in a number of existing test-cases, since `Uint8ClampedArray` appears to use `Math.round` (or equivalent) and the old code used (basically) `Math.floor`.
 2017-08-14 16:19:57 +02:00
Jonas Jenwald
e2ea9b693c In src/core/jpg.js, ensure that the Adobe JPEG marker always takes precedence, even when the color transform code is zero 
According to the PDF specification, please see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G6.2394361, if an Adobe JPEG marker is present it should always take precedence. This even seem to be consistent with the existing comment that is present in the code.
Hence it seems reasonable to interpret `transformCode === 0` as no color conversion being necessary.

Fixes the rendering of page 1 in `issue-4926` (from the test-suite), when the built-in `src/core/jpg.js` image decoder is used.
 2017-07-11 17:08:30 +02:00
Yury Delendik
d028c26210 Removes error() 2017-07-07 09:40:24 -05: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
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
62eee8c782 Try harder to find the next valid JPEG marker when decoding Scan data (issue 8182, issue 8189) 
Tentatively fixes 8182 and fixes 8189.
 2017-03-27 15:55:21 +02:00
Jonas Jenwald
e2e13df4a5 Merge pull request #8164 from Snuffleupagus/issue-7828 
Don't read past the EOI marker for JPEG images with non-default restart interval (issue 7828)
 2017-03-20 22:17:28 +01:00
Jonas Jenwald
d6d0f778aa Don't read past the EOI marker for JPEG images with non-default restart interval (issue 7828) 
*After browsing through (a version of) the JPEG specification, see https://www.w3.org/Graphics/JPEG/itu-t81.pdf, I hope that this patch makes sense.*

Note that while issue 7828 became a problem after PR 7661, it isn't really a regression from than PR. The explanation is rather that we're now relying on `core/jpg.js` instead of the Native Image decoder in more situations than before, which thus exposed an *existing* issue in our JPEG decoder.
Another factor also seems to be that in many JPEG images, the DRI (Define Restart Interval) marker isn't present, in which case this bug won't manifest either.

According to https://www.w3.org/Graphics/JPEG/itu-t81.pdf#page=89 (at the bottom of the page):
"NOTE – The final restart interval may be smaller than the size specified by the DRI marker segment, as it includes only the number of MCUs remaining in the scan."
Furthermore, according to https://www.w3.org/Graphics/JPEG/itu-t81.pdf#page=39 (in the middle of the page):
"[...] If restart is enabled and the restart interval is defined to be Ri, each entropy-coded segment except the last one shall contain Ri MCUs. The last one shall contain whatever number of MCUs completes the scan."

Based on the above, it thus seem to me that we should simply ensure that we're not attempting to continue to parse Scan data once we've found all MCUs (Minimum Coded Unit) of the image.

Fixes 7828.
 2017-03-20 17:16:33 +01:00
Jonas Jenwald
be1a6f294f Try to recover when encountering JPEG markers with too short marker lengths (issue 8169) 
The issue with the JPEG image in question, is that the COM (Comment) marker has an incorrect length entry.

Fixes 8169.
 2017-03-20 17:05:51 +01:00
Jonas Jenwald
52e0f51917 Enable the no-unused-vars ESLint rule 
Please see http://eslint.org/docs/rules/no-unused-vars; note that this patch purposely uses the same rule options as in `mozilla-central`, such that it fixes part of issue 7957.

It wasn't, in my opinion, entirely straightforward to enable this rule compared to the already existing rules. In many cases a `var descriptiveName = ...` format was used (more or less) to document the code, and I choose to place the old variable name in a trailing comment to not lose that information.

I welcome feedback on these changes, since it wasn't always entirely easy to know what changes made the most sense in every situation.
 2017-01-29 23:23:17 +01:00
Jonas Jenwald
4626fc8342 Enable the spaced-comment ESLint rule 
Please see http://eslint.org/docs/rules/spaced-comment.

Note that the exceptions added for `line` comments are intended to still allow use of the old preprocessor without linting errors.
Also, I took the opportunity to improve the grammar slightly (w.r.t. capitalization and punctuation) for comments touched in the patch.
 2017-01-19 16:41:59 +01:00
Jonas Jenwald
4046d67fde Enable the no-else-return ESLint rule 
Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
 2017-01-09 20:27:39 +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
3820946301 Fix (most) errors reported by the no-multi-spaces ESLint rule 
http://eslint.org/docs/rules/no-multi-spaces
 2016-12-12 20:35:51 +01:00
Tim van der Meij
5194e68134 Lint: correct code style violations 
Manual observations and working with other linting tools found these.
 2016-11-01 15:04:21 +01:00
Jonas Jenwald
54ee83eb12 Attempt to skip zero bytes at the end of Scan blocks when decoding JPEG images (issue 4090) 2016-09-28 16:31:02 +02: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
a35773ec8c Change src/core/jpg.js to use the error utility function instead of throwing 
This allows us to remove the `try/catch` statements used in `src/core/stream.js` when parsing JPEG images.
As far as I can tell, the only reason for the current usage of plain `throw` is that `jpg.js` originally was external code. Given that this code now lives in our repo, this patch brings the JPEG code more in line with e.g. `src/core/jpx.js` and `src/core/jbig2.js`.
 2016-09-04 16:28:23 +02:00
Jonas Jenwald
1bbc694ac3 Assign the quantizationTables after parsing the entire JPEG image, to prevent issues when the DQT (Define Quantization Tables) marker is encountered after SOF{n} (Start of Frame) markers (issue 7406) 
This is a tentative patch that fixes 7406.
 2016-08-31 18:42:05 +02:00
Jonas Jenwald
a494e33776 Update JpegImage.getData to support forceRGBoutput for images with numComponents === 1 (issue 6066) 
*A more robust solution for issue 6066.*

As a temporary work-around for (the upstream) [bug 1164199](https://bugzilla.mozilla.org/show_bug.cgi?id=1164199), we parsed *all* images in the Firefox addon during a short time.
Doing so uncovered an issue with our image handling (see 6066), for JPEG images with a `DeviceGray` ColorSpace *and* `bpc !== 1` (bits per component).

As long as we let the browser handle image decoding in this case, this isn't going to be an issue, but I do think that we should proactively fix this to avoid future issues if we change where the images are decoded (in `jpg.js` vs in browser).
Also, we currently don't seem to have a test-case for that kind of image data.
 2016-02-18 10:12:37 +01:00
Tim van der Meij
df81b832bb Remove unused variables 2015-12-16 23:52:16 +01:00
Yury Delendik
6b60c8f4db Adds UMD headers to core, display and shared files. 2015-12-15 13:24:39 -06: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
4a9ff471c4 Correctly detect the presence of the Adobe specific APP14 JPEG marker (bug 1140761) 
According to the specification, http://partners.adobe.com/public/developer/en/ps/sdk/5116.DCT_Filter.pdf#G3.851943, the content of the marker segment should begin with `Adobe`, and not `Adobe\x00` as the code currently look for.

Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1140761.
Fixes the colour conversion part of issues 4090 and 5623.
 2015-03-10 13:07:09 +01:00
Jonas Jenwald
3651c9e1f7 Skip fill bytes (0xFF) when decoding JPEG images (issue 5331) 2015-02-14 00:08:43 +01:00
fkaelberer
5fcf3d37a7 use fewer multiplications in convertYcckToRgb 2014-11-05 15:53:10 +01:00
fkaelberer
ea719ae805 remove null checks that always evaluate to false 2014-11-05 15:19:30 +01:00
Tim van der Meij
2796d1bf10 Use strict equalities in src/core/jpg.js 2014-08-01 23:02:56 +02:00
fkaelberer
f9cde5d93e faster JPEG transform 2014-06-17 10:09:17 +02:00
Yury Delendik
cff2c3afc1 Merge pull request #4892 from yurydelendik/issue4890 
Fixes masked JPEG image
 2014-06-10 09:16:12 -05:00
Yury Delendik
9308c7c82f Merge pull request #4896 from CodingFabian/cleanup-jpgjs-buildComponentData 
Deleted unused variables in jpgjs buildComponentData.
 2014-06-06 09:48:30 -05:00
Fabian Lange
030a188af7 Deleted unused variables in jpgjs buildComponentData. 2014-06-05 16:20:29 +02:00
Fabian Lange
0a42edf82f Optimize JPG.js receiveAndExtend for 1 bit case. 
Profiling showed that receiveAndExtend is frequently called with the length of
one bit. This happens for example in decodeBaseline.
For a single bit, the loop and shift in receive, as well as the shifts in
receiveAndExtend are overhead.
This shortcut manually calculates the shifts by either returning 1 or -1 from
receiveAndExtend by reading the bit and deciding on the return value.
While it comes with an overhead for each non-one length, the speedup is at about
10% in the hot parse/decode path.
 2014-06-05 12:24:53 +02:00
Yury Delendik
6b411b559d Fixes masked JPEG image 2014-06-04 15:53:46 -05:00
Yury Delendik
43a103d5d3 Merge pull request #4889 from CodingFabian/optimize-jpg-loops 
Optimized loops in JPG conversion.
 2014-06-04 15:34:48 -05:00
Fabian Lange
dcde59fa76 Optimized loops in JPG conversion. 
This change makes the 4 conversion loops look the same.
It optimizes access of the array length and access of the property
numComponents, which is known to be constant.
 2014-06-04 10:02:47 +02:00
Yury Delendik
6235e3a61c Adds color components decoding to the JPEG 2014-06-03 08:51:57 -05:00
p01
14a2d74d16 Optimized JPG.js - 33% faster convertCmykToRgb 2014-05-05 14:36:46 +02:00
p01
287274d3dc Optimized JPG.js - reduced memory usage + 2.16x faster getLinearizedBlockData 
Linearize and scale the mcu blocks into the destination buffer in a single pass
 2014-05-05 14:36:46 +02:00
Thorben Bochenek
e8f0700bfa Move the colour conversion to jpg.js 
Benchmarking shows that this improves performance for the invitation document
from https://github.com/mozilla/pdf.js/issues/3809 by 35%
 2014-04-24 15:07:12 +02:00
Renamed from external/jpgjs/jpg.js (Browse further)