Inserting PDF or image file between background and drawing layers.

[tekhnee]

@francoisschwarzentruber I vaguely recall a proposal for embedded PDF, image, or audio/video files. The discussion elaborated on various design challenges. Unfortunately I cannot retrieve that discussion — may I ask about your thoughts on this? The lack of such a facility excludes this extraordinary software from entire disciplines — art history, music, manuscript studies, …

I realize that the dimensions of the tableau could be a major constraint — not an insurmountable one, though.

[francoisschwarzentruber]

@tekhnee, thank you for your message. You can already set an image file as a background. PDF, you cannot yet. I agree with you that it should be possible to add a PDF as a background. Now, there are several issues about the dimensions of the tableau:

• should the blackboard move with the pdf pages or not? The answer I guess is: it depends!
• should we allow a vertical scrolling too? especially, for a standard A4 pdf it would more reasonable to have a vertical scrolling.

[tekhnee]

@francoisschwarzentruber thank you for the speedy reply!

• should the blackboard move with the pdf pages or not? The answer I guess is: it depends!

It does depend, but I'd (anecdotally) I'd argue that the PDF should be "anchored" to a particular board and position—just like any other object. This would allow the teacher to prepare for a class with, say, a different image on each of the 5 available views.

• should we allow a vertical scrolling too? especially, for a standard A4 pdf it would more reasonable to have a vertical scrolling.

I'm glad you posed this question because it was on my mind, too. I cannot think of a good reason to prevent vertical scrolling… I might be wrong, though.

[francoisschwarzentruber]

Dear tekhnee,
now, a pdf can be added as a background. There are still many drawbacks related to several issues:

• there is a "unique" board so all the pages are displayed horizontally on the same board. (having the notion of pages + the notion of scrolling is too much I think, not sure)
• as you mentioned, if the pdf contains many pages, then the board should be very big. This is the issue of the "large board".

To be continued... :)

[tekhnee]

@francoisschwarzentruber on my system (macOS) it is not possible to choose a PDF file when clicking on Preferences > Background > Choose your own background. PDFs are all greyed out in the dialog box. Am I looking at the wrong place?
Thanks.

[francoisschwarzentruber]

@tekhnee thank you for reporting that bug on macOS. No you are exactly at the right place! I guess that is a bug with the format acceptance in the dialog box. What happens if you allow for any type of files in the dialog box? What is your browser?
Also only check on https://tableaunoir.github.io/ (other tableaunoir websites may not be up-to-date and do not accept pdf yet).
ps: it works on Firefox Linux Fedora.

[tekhnee]

@francoisschwarzentruber false alarm, my apologies! Presumably for security reasons, the browser blocks access to local files when the originating URI is a local file://. I wasn't able to load any background, PDF or otherwise, running the app locally. Everything works as expected, with the same browser, on your server.

[francoisschwarzentruber]

OK. Thank you. Do not load a heavy pdf. The code is not optimized yet! ;)

[tekhnee]

@francoisschwarzentruber a couple of comments on the implementation. At the outset, it looks great and adds significant power to the app.

Two questions:

1. What if the PDF was made moveable (like a magnet of sorts)? Would there be significant downsides or technical difficulties involved? I understand that moving the PDF around would change the position of all pages on the "sub-boards."

2. Not wishing to suggest any fundamental changes, nevertheless it might be worth considering the insertion of an additional layer between the "background layer" and the "drawing layer." This middle layer could then be used for such things as PDFs, videos, or (in the long run) other widgets. This would also solve the conceptual problem with PDF pages: adding a PDF on the middle layer would allocate space for one (1) page only. The user could then select which particular page of the PDF to display in that allocated space. I hope this makes sense... please let me know if you'd like me to clarify.

[francoisschwarzentruber]

@tekhnee. Thank you for your comments.

1. What if the PDF was made moveable (like a magnet of sorts)?

Do you mean completely freely? Why not, but this "pdf magnet" is big on the screen. Also, we should still be able to draw on the top of the PDF. So, moving the PDF should be done via an extra handle, or by pressing a key or whatever.

Would there be significant downsides or technical difficulties involved?

No, there are technical difficulties to move the PDF widget.

I understand that moving the PDF around would change the position of all pages on the "sub-boards."

It depends. The different pages could also be separated. In PS, I explain how PDF.js, that library is convenient.

2. It makes sense. As far as I understand, your implementation proposal is:

• the PDF is fixed on the screen (when the board scrolls, the PDF remains at the same place)
• there is a single page shown (a bit like if the board is a table, and the PDF magnet is a book)
• If you draw on the PDF, either you draw really on the PDF page, so if you change the page, your drawing disappear but remains in that page. Or you draw transparently over the PDF: if you change the page, your drawing remains.
  It corresponds to the use in a conference where you have slides and a (paper)board. You can change the slide page and the paperboard page independently. The advantage is that the explanation given in the side of the PDF remains when a page is changed, as the audience still sees the explanation in the paper-board if you change slides. The drawback: many features: "change PDF page", "scroll on the board".

The current implementation of Tableaunoir corresponds to a classical PDF annotation software, and scrolling in the board will show the PDF pages in order. In some sense, the features "change PDF page" and "scroll on the board" are merged.

All the solutions "conference mode with writing on the pdf", "conference mode with writing on the board independent from the PDF", "PDF pages already arranged behind the board" are implementable. I am bit puzzled and I want tableaunoir to be simple to use. ;)

PS: with PDF.js, everything is implementable! Actually, the library PDF.js works as follows. Just allocate an HTML canvas for a page, and then you ask PDF.js to draw a specific page on that canvas. There are no memory issues, because we can discard pages that are not on the screen.

[tekhnee]

1. It makes sense. As far as I understand, your implementation proposal is:

• the PDF is fixed on the screen (when the board scrolls, the PDF remains at the same place)

I'm sorry, I probably was not clear: when the board scrolls, the PDF would scroll with the board just like any other drawing. (In other words, the PDF would have a constant position in the board space, not in the browser window space).

• there is a single page shown (a bit like if the board is a table, and the PDF magnet is a book)

Exactly. The book would be movable on the table (via drag and drop). And if you moved the table (scrolling), the book would move with the table (not "float" above the table).

• If you draw on the PDF, either you draw really on the PDF page, so if you change the page, your drawing disappear but remains in that page. Or you draw transparently over the PDF: if you change the page, your drawing remains.

I had the second option in mind (transparency) but either would be fine, to my mind.

The drawback: many features: "change PDF page", "scroll on the board".

Ah, I see what you mean. What if the page was selectable only once (when the PDF is actually uploaded onto the board), and then remained static?

All the solutions "conference mode with writing on the pdf", "conference mode with writing on the board independent from the PDF", "PDF pages already arranged behind the board" are implementable. I am bit puzzled and I want tableaunoir to be simple to use. ;)

Agreed! I hope the above clarification might simplify the feature.

[francoisschwarzentruber]

OK! Anyway, the PDF book, or the PDF pages always move with the board! I agree! So we have three possibilities.

• PDF pages arranged on the board (like now, maybe with some improvements)
• a PDF book and we draw by transparency (when we change the PDF page, the drawing remains and is on the top of the book)
• a PDF book and we draw on the pages (except magnets that are still part of the board)

I guess that importing only one specific page could be done in the PDF book option: simply go to that page! Now, remains some issues:

• how do we change the current page in PDF book? Do we display the classic buttons "previous page", "next page", "write a page number"? Also how do we move the book in the board? by dragging it I guess... maybe a sort of window title bar ;).

[tekhnee]

I think there is a whiteboard project that implements the page selection feature quite well. The relevant lines are here. The elegance of the result belies the brevity of the code!

[francoisschwarzentruber]

Thank you! I tested that whiteboard project and it works! In fact, it works like... a magnet! I will think about it.

[francoisschwarzentruber]

Thank you for all this discussion. I try to follow the KISS principle. Here is where Tableaunoir is now for the insertion of images or PDF.

1. I like the idea of inserting just one page, and it is now like this in Tableaunoir.
2. I like the spirit of the whiteboard project you mentioned. But I feel that it does not match the philosophy of Tableaunoir yet. In Tableaunoir, you have magnets, but you do not write on them (and making a "print to background", "print to board" like in that project, is too complicated.
3. For most users, I think that insertion the document (image or pdf page) in the top-left corner of the current screen is sufficient. Also, use the whole height is sufficient. I think that turning the images, pdf, resizing it very precisely is not very useful.
4. In the previous version, the notion of background images was confusing. Now, Tableaunoir uses the terminology:

• wallpaper for grid, or music score;
• document for adding an image/pdf page.

Of course, we should stay open with ideas. But we could also keep it simple like that. What do you think?

[tekhnee]

@francoisschwarzentruber I'm (mostly) convinced.

The distinction between wallpaper and document, which supersedes background images, makes perfect sense. At the moment the wallpaper is in front of the document, though (e.g. the staff paper background crosses out part of the PDF pages). Is this intentional or a bug?

The full-height view is indeed sufficient for most cases, and I'll agree that resize-move controls for the document would probably add noise to the UI. In case of ultra-small images requiring magnification or zoom, one can always produce a magnified copy in advance. I'll need to test this in actual teaching, especially with detailed manuscripts and scores, to discover potential weaknesses. At the outset, though, it does look very good and is delightful to use.

My first hunch was to complain for not being able to add more than one PDF at a time. Then I thought, one can always share two tableaunoir links at the same time, right? (Though of course the load on the serve would multiply.)

My only objection really is that I'd still prefer inline page forward-backward buttons on mouse hover — for quickly skimming through the PDF without returning to the settings. I cannot see how this would overcomplicate things; on the contrary, having to return to the settings for a simple page turn seems to me unnecessarily complicated. It's your call, of course…..

Thank you so much!

[francoisschwarzentruber]

Thank you for your message and the general discussion. It really helps to improve Tableaunoir.

Wallpaper should be behind documents (image or PDF)
Ooops, no this is a bug ;) The wallpaper should be behind! Thank you for having reported it. I made the modification.

Full-height
OK! Let us keep it like this for the moment. However I agree that sometimes it may require extra work to adjust the pdf/image. That is not perfect.

You can add more than one page.
Sorry for that. You can actually add as many pages you want. To do that, first you scroll the board where you want, and then in the menu, you insert another page of the PDF, or even the same page, or a page of another PDFs. It means that this functionality seems weaker than what it is. I put the text in the menu in plural form (insert documentS). I hope it is clearer.

inline page forward-backward buttons
Me too and I agree with you. My only problem is that I do not see where to add some buttons to the previous/next page buttons and the page number. An extra widget for that will take up a lot of space. A solution would be to add a small button... but then that button is already there: the menu button.

[tekhnee]

You can add more than one page.

Ah! Apologies, got you — will take a look and report back if needed. [UPDATE: Works beautifully.]

inline page forward-backward buttons…. My only problem is that I do not see where to add some buttons to the previous/next page buttons and the page number.

I was going to suggest that these controls be visible "on hover" but forgot, momentarily, that… hovering is the essence of this whiteboard app :) So this wouldn't work.

What could (?) work is a "dot" or "hamburger" button on the upper-left corner of the PDF, which would open a popup with these page controls. An extra-suave—if somewhat hidden—alternative would be to have a clickable 5px border around the PDF, which would open the popup… And so on… ideas aplenty… Thank you for this excellent piece of work.

[francoisschwarzentruber]

I continue thinking about it. For the moment, let us just imagine thatthe "dot", "hamburger" button is simply the menu button, and that the last open menu tab was "Background", so you are directly in the PDF page selector.

Maybe at some point, we could imagine that the full menu is not (always) full screen, but for the background tab for instance, the board itself is still visible in the menu. So the background tab will enable the user to directly interact with the background elements (for instance, change the page of a pdf or delete a pdf/image). I am not sure I am completely clear so I draw an image:

What do you think?

ps: this kind of graphical user interface is more difficult to develop. So we really need to be sure it is useful!

[tekhnee]

@francoisschwarzentruber, I think I understand what you mean — a "modal" element of some kind for the menu, perhaps in the shape of a "drawer" or pop-up dialog. This idea looks superior to mine for a number of reasons; it is more versatile and expandable, to begin with, and also provides much more space for laying out the controls.

It would probably take a few iterations until it is ergonomic and truly simple to use. But it opens up a few interesting directions — a (semi-)transparent background for the modal menu, for instance, which could allow the PDF/background controls to float above the board, until they are dismissed by the user.