Right now, the presenter notes window shows the current time.

It would be useful to be able to press t to start a timer (replacing or next to the clock) which would count up from 00:00:00.

Some margins and paddings in slides-theme-simple.css need tightening up, and some default Markdeep elements should be restyled.

Other theme ideas: A minimalist serif theme and a dark blue/gray theme, similar to Sublime's Mariana color scheme.

Theme CSS files should perhaps be named markdeep-slides-theme-....css and documented/previewed in the demo slides and README.md.

The presenter notes are looking a bit drab right now.

A related issue is that the presenter notes shown inline in draft mode inherit their styles from the slides, while the presenter notes window uses standard browser styles (which, come to think of it, will mess with some Markdeep features if the user chooses to be cute about their presenter notes).

Clearly, both of these points should be addressed, probably via style inheritance from the main window?

Shipping versioned "batteries included" releases with bundled Markdeep and MathJax (and perhaps some webfonts) would circumvent potential "I'm about to give my talk and my slides are utterly broken because there's no wifi" issues.

Downside: Extra work. But worth it, also to have well-defined versions (with specific upgrade instructions, if needed).

Right now, <video src="..." autoplay> causes the video to start playing on page load, which is not what you want in a presentation. Ideal behaviour would be...

• ...in draft mode, don't autoplay ever.
• ...in presentation mode, start playing once the slide containing the video is flipped to and stop once the next slide is requested.

I think this could be accomplished by translating the autoplay attribute into a data-autoplay attribute in a preprocessing step and invert this translation when the slide is active (and again once it becomes inactive).

This functionality is useful when distributing slides to attendees. It's implemented in most presentation software, e.g. in PowerPoint: https://www.cs.princeton.edu/~arvindn/talks/MIT-STS-AI-snakeoil.pdf

This would have to be a separate printing mode since printing the slides-and-nothing-else to PDF is a common use case. Not sure what the best way to trigger this would be. It could, of course, depend on a config option.

Like, "x/42".

Right now, whichever slide is completely visible and closest to the viewport's top edge is noted in the URL hash and thus aligned to the viewport's top edge on refresh.

This keeps things simple and somewhat transparent to the user, but perhaps it would make sense to maintain a more accurate position (or offset from the top of the slide specified in the URL hash) in local storage or something?

In presentation mode, this more accurate position should of course be ignored.

There can be errors when parsing HTML entities in slides, in particular <, > and & may be parsed incorrectly if not replaced by <, > and & or <, > and &. As an example

for(int i=0;i<10;i++){
  printf("%i\n",i);
}

will render incorrectly in slides, but

for(int i=0;i<10;i++){
  printf("%i\n",i);
}

will render correctly.

you are using my favorite font family for fixed width font contexts such as code snippets. Great!
I have spent a lot of time tweaking the iosevka font to have well-distinguishable l1ij, O0, {([ and a few others. I have attached the result with this issue ticket. Feel free to review it and, if you like, to replace the current default iosevka with my custom edition. I grant BSD style totally free use of these fonts with no requirement to mention where they are from. Just use it and be happy :-)

iosevka-Ingmar-narrow.zip

I use chrome 75.0.3770.142 64bit.
I test use the demo.md.html.

To be applied to the width and height styles computed in initSlides().

Being able to fill an entire slide with an image or video (perhaps with any aspect ratio mismatch-created gaps filled with black) would be neat.

This would be similar to how Deckset does slide-filling content and could be achieved by adding an attribute via Markdeep...

![](image.jpg full)

...and matching on this via CSS, something like this:

center img[full],
center video[full],
center iframe[full] {
    margin-top: -1rem;  /* counteract center top margin */
    margin-left: -2rem;  /* counteract side margin */
}
center img[full], ... {
    max-height: var(--slide-height);
    max-width: var(--slide-width);
}

I likely won't tackle this anytime soon, though.

The stylesheet that's built into Markdeep comes with some sizes defined in terms of px, which won't be consistent for arbitrarily sized slides (unless I switch to zooming slides from the default width of 640px (instead of increasing the root's font size and defining everything in terms of that), which would actually be worth exploring, but might open a whole other can or worms).

So it would make sense to "relativize" these sizes in another stylesheet that's applied before markdeep-slides.css to be defined in terms of rem (or em, where appropriate).

An issue, then, will be future updates and feature additions to Markdeep – I'd have to make sure to keep this "relativization" up to date.

Right now, the presenter notes window needs to be opened to review the notes as the user is building their presentation.

It would be neat if presenter notes were displayed below each slide in draft mode, on a black blackground (with some nice gradient?) to mirror the styling of the presenter notes window. This would, however, require some changes to the markup, from currently

<div class="slide" id="...">
    <div class="slide-number">...</div>
    <div class="presenter-notes">...</div>
    ...
</div>

to then

<div class="slide" id="...">
    <div class="slide-number">...</div>
    <div class="content">
            ...
    </div>
    <div class="presenter-notes">...</div>
</div>

which would also allow for a more elegant approach to letterboxing (because of the additional element being available for styling). Worth thinking about.

Add a progress meter/bar based on currentSlideNum and slideCount (the latter of which would have to be precomputed before <hr> replacement). It would make sense to add a <div class="progressbar" data-progress="...%"></div> (or just with ...style="width: ...%;"...) element to each slide, hidden by default and to be positioned and styled by each theme.

As of now, pressing t toggles the timer shown in the presenter notes window. That is,

• if the timer is inactive, it is started and shown, and
• if the timer is active, it is hidden and reset to 0.

I can imagine situations where it would be beneficial to pause the timer. The following interaction would make sense to me: If the user presses t,

• if the timer is inactive, it is started and shown (nothing new here), and
• if the timer is active, it is paused (this could be visually further emphasized by making it blink).
• To reset the timer, the user would have to press tt (i.e. twice in quick succession, perhaps within half a second), which would hide and reset the timer.

Since pausing the timer is implementation-wise not completely trivial, I might not address this unless someone wants me to (leave a comment!).

After the most recent commit, the slides are too zoomed in when trying to print in Chrome. Have you observed this?

Calendars and schedule lists are difficult to adapt to slides:

• Given a schedule list in Markdeep source code, Markdeep generates a calendar and, below that, a schedule list.
• There's no way both of them would fit on a single slide for even moderately busy schedules.
• They're both tables, with some lengths defined inline in terms of pixels – these need conversion to rem.

I likely won't tackle this anytime soon since I've yet to use a schedule list myself, but it's certainly worth taking at stab at.

Decide how much and which content to share between the demo slides and README.md. Add a note on why the license was chosen (because Markdeep was released under the same license).

Markdeep renders diagrams to SVG at a fixed pixel size. When resizing the window, the diagram isn't zoomed accordingly – but this will be required for presentation mode and exporting slides to PDF.

I've got the following procedure in mind:

• Assume all diagrams are rendered with respect to a slide width of 640px (or something like it; this is the default setting for PDF output).

• After diagrams have been rendered, grab their width and height values, convert them to rem (based on a 640px slide width), and store them in a data attribute or something.

• On

  • load,
  • resize, and
  • going fullscreen,

  re-convert the stored width and height back to pixels, compare them to the original width and height values, compute the required CSS zoom percentage and apply that.

This seems massively inelegant, complicated, error-prone and like too much work. Hmm.

For example, 1 2 Enter should book the user on a direct (and immediate) flight to slide 12, without any layovers on in-between slides.

Ideal for jumping to a pertinent slide during a post-talk Q&A.

(Most native presentation applications support this, I think. I've always missed the simplicity of this features in PDF readers.)

I'm just starting out with markdeep-slides, but am already very excited!
I'd like to have a bunch of slide sets, one for each chapter in my 'book'.
They all have accompanying files, so each chapter should be its own subdirectory.
With the current setup in the repo that means I need to copy the markdeep-slides folder into each of the chapter folders. That's a pain to maintain if there are changes to the folder and is a lot of wasted space. Instead, I'd like to move the markdeep-slides folder one up in the directory structure so it becomes a sibling of Chapter1, Chapter2, Chapter3, etc.
It seemed pretty straightforward. I simply edited the final section to prepend the paths with '../'. And it mostly works, but somehow the fonts are not the correct ones and it's not obvious why. So this issue is to get assistance in fixing the fonts. Here is my final demo.md.html section:

<!-- Markdeep slides stuff -->
<script>
    markdeepSlidesOptions = {
        aspectRatio: 16 / 9,
        theme: 'simple',
        fontSize: 28,
        diagramZoom: 1.0,
        totalSlideNumber: false,
        progressBar: true,
        breakOnHeadings: false,
        slideChangeHook: (oldSlide, newSlide) => {},
        modeChangeHook: (newMode) => {}
    };
</script>
<link rel="stylesheet" href="../markdeep-slides/lib/markdeep-relative-sizes/1.11/relativize.css">
<link rel="stylesheet" href="../markdeep-slides/markdeep-slides.css">
<script src="../markdeep-slides/markdeep-slides.js"></script>

<!-- Markdeep stuff -->
<script>
    markdeepOptions = {
        tocStyle: 'none',
        detectMath: false,
        onLoad: function() {
            initSlides();
        }
    };
</script>
<style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style>
<script src="../markdeep-slides/lib/markdeep/1.11/markdeep.min.js" charset="utf-8"></script>
<script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>

It is a feature request to consider. I would like to have the progress bar be directly below the slide title. If you look at the Metropolis theme for Beamer, they have options to place it at the top of a slide (like it is now), at the bottom, or under the title.

I don't know JS but I could probably take a stab at it if you could perhaps provide me with some pointers...

'n' doesn't work in the demo.
The error on the console is:
ncaught ReferenceError: theme is not defined
at togglePresenterNotes (markdeep-slides.js:497)
at HTMLBodyElement.keyPress (markdeep-slides.js:

Chrome or Firefox, MacOSX

As mentioned by @dirkk0 in #22.

Turns out that when scroll bars are set to always be visible and thus take up space (or the user is on an OS that always shows scroll bars), the slides aren't sized properly. This is bad because:

• In draft mode, a horizontal scroll bar is visible because the slides continue horizontally just a bit behind the vertical scroll bar.
• In presentation mode, a vertical scroll bar is visible. I'm not yet sure why exactly this is.

I didn't notice this during development because I'm using macOS on a laptop, where scroll bars are overlaid onto the content only when scrolling and don't interfere with the viewport.

I'll try to address this soon.

The standard Markdeep slides template works like this.

I'm not a fan of this behavior (slide separation via horizontal lines seems cleaner, it's also what Deckset does), but it makes sense to at least provide an option for compatibility.

Many slide decks out in the wild have a footer line that's shown at the bottom of each slide. It typically contains the name of the presenter and their affiliation.

This would be implemented as a null-by-default option.