/botio-windows preview

From: Bot.io (Windows)

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://107.22.172.223:8877/b875434f4a528ae/output.txt

From: Bot.io (Windows)

Success

Full output at http://107.22.172.223:8877/b875434f4a528ae/output.txt

Total script time: 0.33 mins

Published

• Viewer: http://107.22.172.223:8877/b875434f4a528ae/web/viewer.html
• Extension: http://107.22.172.223:8877/b875434f4a528ae/extensions/firefox/pdf.js.xpi
• Extension (AMO): http://107.22.172.223:8877/b875434f4a528ae/extensions/firefox/pdf.js.amo.xpi

@Snuffleupagus I really like this feature. It makes the panel a lot more useful. I do agree that it would be better to split this up into several PRs, for example for moving the DocumentOutlineView code to a separate file.

I have experienced two problems when roughly testing this PR just now:

• If you open http://mirrors.ctan.org/info/lshort/english/lshort.pdf, go to the outline panel and click on the + sign next to Typesetting Text. Now click on the + before Line Breaking and Page Breaking. Then click Justified Paragraphs. You'll see that the document goes to Justified Paragraphs, but in the outline view Line Breaking and Page Breaking remains selected. Note that this always seems to happen for every first item in each level in the tree. All other items are fine.
• If you open the outline menu and then the secondary toolbar, the outline menu is closed. This isn't the case the other way around.

@timvandermeij Thanks for the feedback! Regarding your comments:

1. This is probably because I opted to use a really simple algorithm when deciding which Outline Items are selectable, see this function: https://github.com/mozilla/pdf.js/pull/3753/files#diff-687a3b6645757c9ec1df25c970eff9b8R72.
   To keep it as simple as possible, only one Outline Item per page is selectable. This also seems to be in line with how Adobe Reader does things.
   When deciding which Outline Items to select, the one placed highest up on the page will be chosen. This does appear to be handled slightly different in my code compared with Adobe Reader.
   EDIT: I'm guessing that Adobe Reader might use an algorithm that is aware of the actual structure of the Outline. My algorithm could be considered blind in that sense. I'm worried that improving this might be unnecessarily complex (= slower than necessary), given that this would be a pretty insignificant part of PDF.js.
   Is this a serious enough issue, that you believe that I should try to re-write the algorithm?
2. The "Outline Options" toolbar doesn't provide necessary functionality, like the Secondary toolbar. Since the "Outline Options" toolbar needs to be forced closed in a number of circumstances (e.g. when closing the sidebar), it was easier to just close it for every click event rather than only in some situation. This meant that the code could be kept cleaner.
   I think this might be OK, what do you think?

@brendandahl, @yurydelendik Are you interested in adding these features to the viewer?
If the answer it yes, I'll split this into a few different PRs.

@Snuffleupagus, I never felt collapsing the outline items -- finding information in huge collapsible tree is not a good thing. Inertia scrolling, e.g. two-finger scroll, is helping quicker find the info. (And I think it's a bad experience trying to hit a small icon with mouse) Ask shorlander for the input.

Highlighting currently visible bookmark might be a useful feature to have.

@yurydelendik OK, I understand your point of view.
If we remove the collapsing/expanding of outline items, would the following revised suggestion be better?

• Move DocumentOutlineView to its own file.
• Refactor the code somewhat, and add a few small tweaks of the CSS.
• Implement highlighting of the currently visible outline item.

@yurydelendik I think I like the collapsed tree better. I agree that finding information in a huge collapsed tree isn't exactly optimal, but I think finding information in a huge opened tree is also very difficult, not to mention that in the current version the tree is rather simple and therefore not nice to use. If the collapsed tree is really not the way to go according to you, I think adding the classic tree lines (see http://jquery.bassistance.de/treeview/demo/ for example) would already improve this a lot.

Regarding the highlighting, I agree that this is a useful feature, but I still think that the first child item should be selected once you click it and not the parent item (see #3753 (comment)). It's rather confusing otherwise, I'm afraid...

Regarding the highlighting, I agree that this is a useful feature, but I still think that the first child item should be selected once you click it and not the parent item (see #3753 (comment)). It's rather confusing otherwise, I'm afraid...

I don't know it there is a misunderstanding regarding how highlighting works in this patch. The way that this is implemented, it just highlights the first outline item on the currently visible page. It has nothing to do with what that the user clicked on.
The reason for this behaviour was that I wanted to keep the algorithms as simple as possible.

Just to add another thought, most documents have the outline in "expanded form" within the document, so a collapsed form can be nice when you don't want to go through all of that.

I highly approve of any version of this feature - As I see, it is set to "Work in progress". Is there any chance to know when you are planning on implementing this in the main branch? I tried merging it with the current releases, but to no avail - It seems the structure has change a little too much since the PR was posted...

@flopes89 As you can see from the discussion above, there isn't consensus on either:

1. If we actually need this feature at all in the standard PDF.js viewer; given that we're not sure if this would be a good UX, and that it would add a lot of code for a very minor feature.
2. How it should be implemented, if we do decide to implement it.

Given that this code is 1.5 years old, and that we've done (and are still doing) a lot of refactoring of the viewer code, it's to be expected that this won't work in it's current form.

@Snuffleupagus Thanks for the update. I can understand the disucssion, I wasn't sure if there was some progress, as it is still marked as "in progress" - Maybe this should be relabelled then?

[...] as it is still marked as "in progress" - Maybe this should be relabelled then?

No; the 4-work-in-progress label simply means that a PR is not ready to be merged. We use it as a quick indication to reduce the risk that a core contributor accidentally merges a PR that isn't ready yet.

Just as a status update for everyone following this PR: it is closed in favor of #6242 where we continue this feature development.