This allows including spans that contain variables in footers. This does
mean that if you pull in a variable like `{title}` that contains `<` or
`>` it will be included as-is and would allow creating valid HTML tags,
but this is harmless so I don't see a problem with it.
Fixes#574
#566 did the heavy work to allow HTML exports but the one thing missing
is that images were still referenced on their external paths, which
caused 2 issues:
* Files were not redistributable unless you included images and fixed
their paths.
* Generated images (e.g. mermaid diagrams) were likely pointing to a
temporary directory so they'd be lost.
This changes that so HTML exports are now fully self contained, using
`data:...` notation to inline images within the HTML.
the main modifications are
- makes every page exist in a separate container
- allows switching pages via left and right arrows
- merges the css from an outside file to directly within the html
- zooms the content to fit the browser width
This adds new optional `start_line` and `end_line` properties when using
a `file` type snippet, which allow specifying the line range to be used.
Caveats:
* The line selection is applied before highlighting so if you truncate
the file in a place that should be highlighted in some way because of
something that came before (e.g. multi line comments) it won't be
highlighted appropriately. This can be fixed but requires changing a few
things and I think this should not be hit very often.
* Using `+line_numbers` will always start at 1. In the future I may add
a property like `preserve_line_numbers` but again this would require
changing a few things (the same ones as the point above) so I kept it
this way for now.
Example:
~~~markdown
```file +line_numbers
language: rust
path: scripts/foo.rs
start_line: 3
end_line: 20
```
~~~
Closes#562
This hides the JSON schema generation for the config file behind a new
`json-schema` feature flag. This is not fundamental to the functioning
of this tool and also there's already a schema generated
[here](https://github.com/mfontanini/presenterm/blob/master/config-file-schema.json)
so there's no need to have this available in the tool when released. If
anyone does want the JSON schema for some specific version of the tool,
they can always clone the repo and `cargo run --features json-schema`.
This also removes the `serde_with` dependency and instead hand rolls the
`SerializeDisplay` and `DeserializeFromStr` macros manually. These are
very few lines long and doesn't make importing that crate worth it.
Overall these 2 changes cause the number of crates to go down by
something like 20 which is great.
This introduces the config property `export.pauses` which when defaults
to `ignore` but when set to `new_slide` causes the PDF export to contain
a new slide every time a pause is found.
Closes#555
This refactors how async renders work. Before this change, the presenter
had to periodically poll them to pull their state into the operation,
and had to figure out which slides had async renders to be able to poll
them at the right times. This was tedious and error prone, especially
once slide transitions were introduced: we now had to preemptively poll
the next/previous slide because there could be something being async
rendered (e.g. a mermaid diagram) and we didn't want to transition into
a slide with a "Loading..." text when the generated image was available,
just not polled yet.
This now moves all polling to a separate thread. When an operation needs
to be polled (be it because it automatically starts async rendering or
it requires to be triggered by pressing `<c-e>`), now a `Pollable` type
is created that is essentially a container for the logic to poll and a
state shared with the operation. This lets a `Poller` periodically poll
all `Pollables` that need polling (lols). The result is a lot less code
around `Presenter`/`Presentation` to deal with triggering and polling
async renders. Also the handling for async render errors is now much
nicer because it can be treated almost the same way as a successfully
finished async render.
This adds support for footer images on the right, just like allowed for
left/center. Now that there's tests for this and after being
restructured fairly recently it's much easier to get _right_.
The following presentation now renders like the following:
```markdown
---
theme:
override:
footer:
height: 5
style: template
left:
image: ../examples/doge.png
center:
image: ../examples/doge.png
right:
image: ../examples/doge.png
---
Footer images
===
```
Closes#549
Before this change only filesystem images were scaled when transitioning
between slides. This PR does that for generated images as well, and
polls other slides while doing transitions so any images generated
asynchronously are already ASCII'd before we transition into them.
This PR has shown that the async render code has reached proper 💩
level and requires changing it, more so since #537 will be implemented
soon-ish.
This pre-scales images when the presentation is reloaded and transitions
are enabled. For now only filesystem images are scaled but the next PR
will do this for generated ones as well. The end result of this is when
you transition between slides and there's images in them, the animation
is smooth the first time because the scaling, which is costly, is done
ahead of time.
This caches:
* Ascii images so we don't reload them every time we're doing slide
transitions.
* Ascii image resizes, so if we go to a slide that contains an image and
we're using slide transitions, the next transition that includes that
image won't require resizing it to that same sizes.
The one performance "issue" still present when using slide transitions
is that we still need to pay for that first image -> ascii image
conversion and that first ascii image resize the first time we
transition to a slide that contains an image. This is currently
noticeable in debug mode and not in release mode (at least in my machine
™️), but it would be sweet if it wasn't there ever. For this we need to
run through all slides, find all images, ascii convert them and resize
them to the current terminal size. The same should be done when the
terminal is resized.
