pdfjs-dist

Commit Graph

Author	SHA1	Message	Date
Jonas Jenwald	cb5f9df0c8	[EnhanceTextSelection] Make `expandTextDivs` more efficient by updating all styles at once instead of piecewise I intended to provide proper benchmarking results here, as outlined in https://github.com/mozilla/pdf.js/wiki/Benchmarking-your-changes, but after wasting a couple of hours over the weekend getting weird results I gave up. It appears that there's a lot of, i.e. way too much, variance between subsequent runs of `text` tests for the results to be meaningful. (Previously I've only benchmarked `eq` tests, so I don't know if the `text` tests has never worked well or if it's a newer problem. For reference, please see the results of back-to-back benchmark runs on the current `master` with a very simple manifest file: [link here].) Instead I used `console.time/timeEnd` in `appendText` and `expandTextDivs` to be able to compare the performance with/without the patch. The entire viewer was (skip-cache) reloaded between measurements, and the result are available here: [link here]. Given the troubles I've had with benchmarking, I've not yet computed any statistics on the results (e.g. mean, variance, confidence intervals, and so on). However, just by looking at the data I think it's safe to say that this patch first of all doesn't seem to regress the current performance. Secondly it certainly looks very likely that this patch actually improves the performance, especially for the one-glyph-per-text-div case (cf. issue 7224). Re: issue 7584.	9 years ago
Tim van der Meij	323e86c442	Text widget annotations: implement unit testing and sanitize data values	9 years ago
Jonas Jenwald	356b321f6d	Fallback to the `StandardEncoding` for Nonsymbolic fonts without `/Encoding` entry (issue 7580) Even though this patch passes all tests (unit/font/reference) locally, including the new ones that I added in PR 7621, I'm still a bit nervous about modifying the code that choose the fallback encoding for fonts without an `/Encoding` entry. Note that over the years this code has been changed on a number of occasions, see a possibly incomplete [list here], to deal with various cases of incorrect font data. According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1904184, it seems that we should fallback to the `StandardEncoding` for Nonsymbolic fonts. There's obviously a risk that fixing this particular issue could break other PDF files for which we don't have tests. However I've tried to change the logic as little as possible in this patch, to hopefully reduce possible breakage. Based on debugging numerous font issue, it seems that a lot of fonts actually set the Symbolic flag, even when they are in fact not Symbolic. Fonts actually marked as Nonsymbolic seem to be somewhat less common, which I hope should reduce the risk of the patch somewhat. Fixes 7580.	9 years ago
Yash Srivastav	4e428c7675	Fix lint warnings in URL polyfill	9 years ago
Yury Delendik	160b176109	Adding "proper" message port for fake worker.	9 years ago
Jonas Jenwald	f620f61887	Change `src/core/jpx.js` to use the `error` utility function instead of using `throw new Error` Note that in `parseCodestream` I purposly left the `throw new Error` instances inside of the `try` block, since we don't want to throw any `Errors` while in recovery mode. Finally somewhat unrelated to the rest of the patch, but I moved the `doNotRecover` variable declaration outside of the `try` block to avoid variable hoisting given that it's accessed inside the `catch` block.	9 years ago
Jonas Jenwald	325f7afcca	For embedded Type1 fonts without included `ToUnicode`/`Encoding` data, attempt to improve text selection by using the `builtInEncoding` to amend the `toUnicode` map (issue 6901, issue 7182, issue 7217, bug 917796, bug 1242142) Note that in order to prevent any possible issues, this patch does not try to amend the `toUnicode` data for Type1 fonts that contain either `ToUnicode` or `Encoding` entries in the font dictionary. Fixes, or at least improves, issues/bugs such as e.g. 6658, 6901, 7182, 7217, bug 917796, bug 1242142.	9 years ago
Tim van der Meij	be485f59ab	Text widget annotations: implement maximum length and text alignment Moreover, we refactor the code a bit to extract code that is shared between the two branches and we only apply text alignment (and create the array) when it is actually defined, since it's optional and left is already the default.	9 years ago
Jonas Jenwald	0b75f63c03	Don't duplicate the first entry in the `charCodeToGlyphId` map for CIDFontType2 fonts with a `CIDToGIDMap` that already mapped the first entry to a non-zero `glyphId` (issue 7544) Fixes 7544.	9 years ago
Tim van der Meij	e686db250c	Render interactive form (AcroForm) text widget annotations This patch is the first step towards implementing support for interactive forms (AcroForms). It makes it possible to render text widget annotations exactly like Adobe Reader/Acrobat. Everything we implement for AcroForms is disabled by default using a preference, mainly because it is not ready to use yet, but has to implemented in many steps to avoid complexity. The preference allows us to work with the code while not exposing the behavior by default. Mainly storing entered values and printing them is still absent, which would be minimal requirements for enabling this by default.	9 years ago
Jonas Jenwald	44b75c01a1	Check that Type1C fonts does not actually contain OpenType font files (issue 7598) This patch is yet another instalment in the (never ending) series of patches for PDF files that specify completely incorrect Type/Subtype for its fonts. In this case Type1/Type1C, when in fact OpenType would have been correct. Fixes 7598.	9 years ago
Tim van der Meij	576f742047	Improve the structure for widget annotations Currently, we only support text widget annotations (field type 'Tx') partially. However, the current code does not make this entirely clear and does not provide a warning when an unsupported field type is encountered, making it harder to determine why rendering fails. Moreover, in the display layer we make no distinction between the various types of widget annotations, causing the code for text widget annotations to also be executed for other types of widget annotations in a fallback situation. This patch improves the structure of the widget annotation code. In the core layer, we use the same structure we use for non-widget annotations in the factory and provide a clear warning when an unsupported type is encountered. In the display layer, we do the same and split the `WidgetAnnotationElement` class into two classes, namely `TextWidgetAnnotationElement` for text widget annotations and `WidgetAnnotationElement` for other unsupported annotations as a fallback. From this it clear that we only support text widget annotations and nothing else.	9 years ago
Jonas Jenwald	37998076c9	In `display/api.js` ensure that we always reject with an `Error` in `JpegDecode`, and adjust a couple of other rejection sites as well In the case where the document was destroyed, we were rejecting the `Promise` in `JpegDecode` with a string instead of an `Error`. The patch also brings the wording more inline with other such rejections. Use the `isInt` utility function when validating the `pageNumber` parameter in `WorkerTransport_getPage`, to make it more obvious what's actually happening. There's also a couple more unit-tests added, to ensure that we always fail in the expected way. Finally, we can simplify the rejection handling in `WorkerTransport_getPageIndexByRef` somewhat. (Note that the only reason for using `catch` here is that since the promise is rejected on the worker side, the `reason` becomes a string instead of an `Error` which is why we "re-reject" on the display side.)	9 years ago
Tim van der Meij	96593571eb	Optimize scale calculation in `text_layer.js` This patch avoids having to calculate the scale twice by saving it in the properties object. Moreover, we remove a temporary variable and place parentheses around a calculation inside a string concatenation.	9 years ago
Jonas Jenwald	a35773ec8c	Change `src/core/jpg.js` to use the `error` utility function instead of `throw`ing 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`.	9 years ago
Tim van der Meij	b3818d5c36	Replace `div.dataset` with a `WeakMap` in `text_layer.js` This patch improves performance by avoiding unnecessary type conversions, which also help the JIT for optimizations. Moreover, this patch fixes issues with the div expansion code where `textScale` would be undefined in a division. Because of the `dataset` usage, other comparisons evaluated to `true` while `false` would have been correct. This makes the expansion mode now work correctly for cases with, for example, each glyph in one div. The polyfill for `WeakMap` has been provided by @yurydelendik.	9 years ago
Tim van der Meij	b10add14f3	Refactor `text_layer.js` to pass the task as a parameter We pass many parameters to `appendText` while we might as well pass the `task` object that contains them. This saves a few lines of code and makes the signature of `appendText` more clear. We do the same for `expand`, which is useful for the next commit in which we replace `div.dataset` with a `WeakMap`. Furthermore, this patch adds a missing parameter to a comment block to make it clear which parameters remain.	9 years ago
Tim van der Meij	7c961b6b7a	Minor code style improvements after #7539	9 years ago
Jeremy Press	6faa84abdb	Continuing fairexpand #6663 1. Expanding divs to improve text selection. (Yury) 2. Adding enhanceTextSelection as an option. 3. Moving feature functionality from text_layer_builder.js to text_layer.js. 4. Added expandTextDivs method to only load expanded divs on first click, and only show on subsequent clicks	9 years ago
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.	9 years ago
Jonas Jenwald	088ce6c009	Add a unit-test to check that `ProblematicCharRanges` contains valid entries When adding new entries to `ProblematicCharRanges`, you have to be careful to not make any mistakes since that could cause glyph mapping issues. Currently the existing reference tests should probably help catch any errors, but based on experience I think that having a unit-test which specifically checks `ProblematicCharRanges` would be both helpful and timesaving when modifying/reviewing changes to this code. Hence this patch which adds a function (and unit-test) that is used to validate the entries in `ProblematicCharRanges`, and also checks that we don't accidentally add more character ranges than the Private Use Area can actually contain. The way that the validation code, and thus the unit-test, is implemented also means that we have an easy way to tell how much of the Private Use Area is potentially utilized by re-mapped characters.	9 years ago
Jonas Jenwald	78889646c8	Create a fallback annotation `id` for entries in `Annots` dictionaries that are not indirect objects (issue 7569) According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#page=86, entries in `Annots` dictionaries should be indirect objects, but obviously there're PDF generators that ignore this. Fixes 7569.	9 years ago
Jonas Jenwald	5379749d4b	Try to prevent `CanvasGraphics_getSinglePixelWidth` from intermittently returning incorrect values in Firefox (issue 7188) Fixes 7188.	9 years ago
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.	9 years ago
Jonas Jenwald	83ce6f0b6d	Adjust the (applicable) existing `isName` callsites to use the new `isName(v, name)` version of the function	9 years ago
Jonas Jenwald	af636aae96	Add a parameter to the `isName` function that enables checking not just that something is a `Name`, but also that the actual `name` properties matches This is similar to the existing `isCmd` and `isDict` functions, which already support similar kind of checks. With the updated `isName` function, we'll be able to simplify many callsites from: `isName(someVariable) && someVariable.name === 'someName'` to: `isName(someVariable, 'someName')`.	9 years ago
Jonas Jenwald	77c6ed5389	Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before every showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.	9 years ago
Jonas Jenwald	558a22cd02	Prevent errors when parsing Annotations with missing (or invalid) /Subtype entries (issue 7446) Note that I used a separate warning message for this case, instead of utilizing the same one as in the unsupported subtype case, to more clearly indicate that the PDF file itself is to blame rather than PDF.js. Fixes 7446.	9 years ago
Jonas Jenwald	390c02a3e9	Attempt to cache fonts that are direct objects (i.e. `Dict`s), as opposed to `Ref`s, to prevent re-rendering after `cleanup` from breaking (issue 7403 and issue 7402) Fonts that are not referenced by `Ref`s are very uncommon in practice, but it can unfortunately happen. In this case, we're currently not caching them in the usual way, i.e. by `Ref`, which leads to failures when a page is rendered after `cleanup` has run. The simplest solution would have been to remove the `font.translated` workaround, but since this would have meant loading these kind of fonts over and over, the patch attempts to be a bit clever about this situation. Note that if we instead loaded fonts per page, instead of per document, this issue wouldn't have existed.	9 years ago
Jonas Jenwald	2e9cd3ea64	Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference and the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.	9 years ago
Jonas Jenwald	f297e4d17c	[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that controls whether `PartialEvaluator_getTextContent` will attempt to combine same line text items From the discussion in issue 7445, it seems that there may be cases where an API consumer would want to get the text content as is, without combined text items.	9 years ago
Jonas Jenwald	90d19de935	Catch errors and continue parsing in `parseCMap` (issue 7492) After PR 7039, the PDF file in issue 7492 no longer renders at all, but note that text selection wasn't working correctly previously. The problem with the PDF file in issue 7492 is that the `cMap`, in the `toUnicode` entry in the font, contains an invalid name: ``` /CMapName /-usr-share-fonts-truetype-Panton-Panton Family-Fontfabric - Panton.otf,000-UTF16 def ``` When we parse that line, things obviously break because there are spaces present in the wrong places. To avoid that issue, the patch simply lets `parseCMap` continue when errors are encountered, to try and recover usable data. Note that by not aborting immediatly when an error is encountered, we are also able to fix the text selection. Obviously, it could be argued that we should just immediatly reject a corrupt `cMap`. But given that they usually are correct, it seems that trying to recover as much data as possible from corrupt one can only be a good thing for both glyph mapping and text selection. Fixes 7492.	9 years ago
Jonas Jenwald	64783c8b6e	Don't map glyphs to the Lepcha Unicode block (issue 7426) In the PDF file in the issue, some of the glyphs end up being mapped to the Lepcha Unicode block; see https://en.wikipedia.org/wiki/Lepcha_(Unicode_block). This didn't use to matter, but after HarfBuzz updates that improved support for Lepcha fonts, in particular https://bugzilla.mozilla.org/show_bug.cgi?id=1249861, some glyphs are now moved horizontally. To avoid that, this patch adds the Lepcha block to the list of Unicode ranges that we skip when building the glyph mapping. Fixes 7426.	9 years ago
klemens	6f03f62327	trivial spelling fixes	9 years ago
Jonas Jenwald	8f4ec669d0	Remove the obsolete `MozBlobBuilder` fallback from the `createBlob` utility function `MozBlobBuilder` has been obsolete since Firefox 14, so there's no reason to keep this code around anymore.	9 years ago
Jonas Jenwald	51e46fa1a7	Change the `warn` to `info` in `recoverGlyphName` to reduce the console spam After PR 7441, where `recoverGlyphName` is used a lot more than before, many PDF files will generate a lot of warnings the console. For normal usage, compared to debugging/development, this is probably more annoying than helpful.	9 years ago
Simon Cornelius P. Umacob	d872fc90b9	Expose the text widget's maximum length.	9 years ago
Jonas Jenwald	bdd58ab1d2	Ignore .notdef in the `differences` array when building a fallback `toUnicode` map in `PartialEvaluator_buildToUnicode` (issue 5256) Fixes 5256.	9 years ago
Jonas Jenwald	7866109af9	Fallback to attempt to recover standard glyph names when amending the `charCodeToGlyphId` with entries from the `differences` array in `type1FontGlyphMapping` (issue 7439) Fixes 7439.	9 years ago
Jonas Jenwald	c1ca268ef3	Skip mapping of glyphs to Unicode "Ideographic space" (issue 7416) Fixes 7416, which is an IE specific issue.	9 years ago
Jonas Jenwald	6a0b047bfa	Add upper-case `I` as a possible space replacement fallback in `Font.spaceWidth` to improve text-selection (issue 7180) In fonts with only upper-case glyphs, that are also missing a space glyph, `get spaceWidth` won't be able to return anything useful. By adding upper-case `I` as a fallback, we can thus improve text-selection in some PDF files. Note that locally, the patch causes slight movement in a few existing `text` tests, but in my opinion this actually looks like slight improvements. Fixes 7180.	9 years ago
Jonas Jenwald	6260fc09a3	Attempt to recover valid `format 3` FDSelect data from broken CFF fonts (bug 1146106) According to the CFF specification, see http://partners.adobe.com/public/developer/en/font/5176.CFF.pdf#G3.46884, for `format 3` FDSelect data: "The first range must have a ‘first’ GID of 0". Since the PDF file (attached in the bug) violates that part of the specification, this patch tries to recover valid FDSelect data to prevent OTS from rejecting the font. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1146106.	9 years ago
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.	9 years ago
Jonas Jenwald	b02d560ae0	Fix errors in `setGState` in `PartialEvaluator_getTextContent` that prevents text-selection from working properly Currently `setGState` is completely broken, and looking through the history of that code, it seems to me that this may never have worked correctly. This patch fixes the text-selection in `extgstate.pdf` in the test-suite, which is also added as a `text` test.	9 years ago
Jonas Jenwald	98fe094d18	Let non-viewable Popup Annotations inherit the parent's Annotation Flags if the parent is viewable Fixes http://www.pdf-archive.com/2013/09/30/file2/file2.pdf. Note how it's not possible to show the various Popup Annotations in the above document. To fix that, this patch lets the Popup inherit the flags of the parent, in the special case where the parent is `viewable` and the Popup is not. In general, I don't think that a Popup must have the same flags set as the parent. However, it seems very strange to have a `viewable` parent annotation, and then not being able to view the Popup. Annoyingly the PDF specification doesn't, as far as I can find, mention anything about how this case should be handled, but this patch seem consistent with the actual behaviour in Adobe Reader.	9 years ago
Jonas Jenwald	b354682dd6	[api-minor] Let `LinkAnnotation`/`PDFLinkService_getDestinationHash` return a stringified version of the destination array for explicit destinations Currently for explicit destinations, compared to named destinations, we manually try to build a hash that often times is a quite poor representation of the actual destination. (Currently this only, kind of, works for `\XYZ` destinations.) For PDF files using explicit destinations, this can make it difficult/impossible to obtain a link to a specific section of the document through the URL. Note that in practice most PDF files, especially newer ones, use named destinations and these are thus unnaffected by this patch. This patch also fixes an existing issue in `PDFLinkService_getDestinationHash`, where a named destination consisting of only a number would not be handled correctly. With the added, and already existing, type checks in place for destinations, I really don't think that this patch exposes any "sensitive" internal destination code not already accessible through normal hash parameters. Please note: Just trying to improve the algorithm that generates the hash is unfortunately not possible in general, since there are a number of cases where it will simply never work well. - First of all, note that `getDestinationHash` currently relies on the `_pagesRefCache`, hence it's possible that the hash returned is empty during e.g. ranged/streamed loading of a PDF file. - Second of all, the currently computed hash is actually dependent on the document rotation. With named destinations, the fetched internal destination array is rotational invariant (as it should be), but this will not hold in general for the hash. We can easily avoid this issue by using a stringified destination array. - Third of all, note that according to the PDF specification[1], `GoToR` destinations may actually contain explicit destination arrays. Since we cannot really construct a hash in `annotation.js`, we currently have no good way to support those. Even though this case seems very rare in practice (I've not actually seen such a PDF file), it's in the specification, and this patch allows us to support that for "free". --- [1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.1951685	9 years ago
Jonas Jenwald	01ab15a6f1	[api-minor] Let `Catalog_getPageIndex` check that the `Ref` actually points to a /Page dictionary Currently the `getPageIndex` method will happily return `0`, even if the `Ref` parameter doesn't actually point to a proper /Page dictionary. Having the API trust that the consumer is doing the right thing seems error-prone, hence this patch which adds a check for this case. Given that the `Catalog_getPageIndex` method isn't used in any hot part of the codebase, this extra check shouldn't be a problem. (Note: in the standard viewer, it is only ever used from `PDFLinkService_navigateTo` if a destination needs to be resolved during document loading, which isn't common enough to be an issue IMHO.)	9 years ago
Jonas Jenwald	7ddb0bc718	Attempt to combine text runs positioned with `setTextMatrix`	9 years ago
Tim van der Meij	6a7012aaca	Remove unused variables These have been found using `gulp lint` in combination with the `unused: true` parameter for JSHint. Unfortunately there are too many false positives to enable this feature, but now that most globals have been removed because of the conversion to UMD the results are much more useful than before.	9 years ago
Jonas Jenwald	182d33800a	Ignore 'endobj' commands inside of `ObjStm` streams (issue 5241, bug 898610, bug 1037816) According to an example in the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#page=56, an `ObjStm` stream should not contain 'endobj' commands. Fixes 5241. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=898610. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1037816.	9 years ago

1 2 3 4 5 ...

2716 Commits (fd4428136b6a2dffb31b88f9b6da724623c5e8c5)