mozilla :: #pdfjs

27 Mar 2017
10:49GhetHi, does PDFPageProxy.getTextContent() returns cached value or recompute for each calls ?
12:48github_pdfjs[pdf.js] yurydelendik pushed 2 new commits to master:
12:48github_pdfjspdf.js/master 25873e9 Yury Delendik: Enable babel translation to enable ES module support.
12:48github_pdfjspdf.js/master cd5acf5 Yury Delendik: Merge pull request #8195 from yurydelendik/babel...
12:48soakbotPull 8195: Enable babel on sources.
12:56github_pdfjs[pdf.js] pdfjsbot force-pushed gh-pages from c167e0f to 4013fe5:
12:56github_pdfjspdf.js/gh-pages 4013fe5 pdfjsbot: gh-pages site created via make.js script...
13:41SnuffleupagusNice, it looks like the switch from Esprima to Acorn meant that a couple of really long arrays are now being collapsed into one line instead of multiple lines in the output. The diff stats for pdfjs-dist looks good :-)
13:46yurySnuffleupagus: what's next? mass conversion of UMD headers?
13:46SnuffleupagusI'd say so, yes!
13:46yurythen closure to class?
13:47* yury did not check if we convert to ES5.1
13:48yurywe need to keep pdfjs-dist in older version of ES
13:49yurySnuffleupagus: I'm insterested in fixing #8155 next
13:49soakbotPull 8155: Move `Uint32ArrayView` from `shared/util.js` to `shared/compatibility.js`.
13:50yuryI hope the plan, I commented about, will work
13:50SnuffleupagusWe may need to add additional Babel plugins to get the ES6 -> ES5 conversion working for certain ES6 language constructs, but I've not really looked too closely at that yet.
13:50Snuffleupagusyury: Thanks for your review on PR #8190. Since the name |readUint16| already exists in that file, are you OK with keeping the |peekUint16| name?
13:50soakbotPull 8190: Try harder to find the next valid JPEG marker when decoding Scan data (issue 8182, issue 8189).
13:51yuryokay... for short time though
13:52yuryused as sharedUtil.readUint16?
13:53yurySnuffleupagus: I have a plan, can you move peekUint16 out of the closure?
13:53yuryThat's what I mostly worry about
13:54SnuffleupagusNote that jpg.js uses its own readUint16 function that increments the overall offset, see
13:55yuryokay, let's keep it as is
13:55* yury was no valuable input on this matter anymore
14:15Snuffleupagusyury: There's some really good point in, but unfortunately I don't fully grasp what the new compatibility code should look like.
14:16* Snuffleupagus is probably being slow today :-)
15:20Ghetso it seems TextContent from PageProxy is not cached and that we reextract it at each call. Could TextContent be different for a same page ?
15:20github_pdfjs[pdf.js] Snuffleupagus pushed 2 new commits to master:
15:20github_pdfjspdf.js/master 62eee8c Jonas Jenwald: Try harder to find the next valid JPEG marker when decoding Scan data (issue 8182, issue 8189)...
15:20github_pdfjspdf.js/master ede4d3c Jonas Jenwald: Merge pull request #8190 from Snuffleupagus/issue-8182...
15:20soakbotPull 8190: Try harder to find the next valid JPEG marker when decoding Scan data (issue 8182, issue 8189).
15:28github_pdfjs[pdf.js] pdfjsbot force-pushed gh-pages from 4013fe5 to a88b127:
15:28github_pdfjspdf.js/gh-pages a88b127 pdfjsbot: gh-pages site created via make.js script...
15:34yuryGhet: it shall not, but we don't want to cache it -- memory is valuable
15:34yurywe are caching font's only, but viewer normally purges cache on regular base
15:49Snuffleupagusyury: the mass conversion of UMD headers that you talked above previously, can that be automated or do we have to do it manually?
15:50yurymaybe, but you have to write analysis tool to check for * imports
15:51yurySnuffleupagus: sometimes we used module global import things for pdfjsLub
15:51yurymaybe for other stuff
15:52SnuffleupagusSure; so basically it could just be quicker to do it manually in then
15:53yuryprobably, I did not look that far :)
15:54yurywhat are pain to migrate to new technologies
15:54yuryhope fully using es classes will worth it
15:55* yury tired to write lots of useless closure code
15:56SnuffleupagusAren't we all :-)
15:57yury... and .bind(this)
15:57SnuffleupagusBtw, should we inline the |export| or keep them at the end as we currently do?
15:57yurygood question
15:57yurySnuffleupagus: I'll let you decide on this
15:58yuryor Tim
15:58* yury can toss a coin too
15:59SnuffleupagusHmm, I suppose that keeping them at the end helps give a quick overview of what the module exports, which is probably useful. So I'd probably tend towards keeping the current practice.
16:14yurysounds fine
16:15yuryis there eslint options for that?
16:18SnuffleupagusFrom a cursory glance, it doesn't look like there is :-(
16:19yuryprobably we shall suggest that to them
16:19SnuffleupagusHowever, I'll check the ESLint rules in a bit more detail after dinner, since we should probably enable some basic set of rules to avoid diverging styles right from the start.
16:20* Snuffleupagus will be back later tonight
27 Mar 2017
Last message: 8 minutes and 18 seconds ago