caching issue with ids

[openbrian]

I'm still getting disappearing svg paths. As I get more familiar with your system of components, I see there's caching. So here are my thoughts.

We should not force unique IDs, as I have done because break caching.

There should be a query string parameter on the IDs with the option to have no prefix, use a given prefix, or have svgo generate a random one.

slides.md could have syntax like this

    ```render_a2s {"id": "markdek_random"}
    ```

    ```render_a2s {"id": "a2sketch_random"}
    ```

    ```{.render_a2s id=a2sketch_random}
    ```

If it's markdeck random, markdeck creates the id and passes it to a2sketch. Caching is enabled.

If it's a2sketch_random, a2sketch generates the id. Caching must be avoided.

Thoughts?

[openbrian]

Could just say to disable caching in general.

[openbrian]

Interesting, pandoc has support for identifiers https://pandoc.org/lua-filters.html#type-codeblock

[openbrian]

For now, I'm hacking slides.md and just adding space to the end of the codeblock in order to make each one unique. This later gets hashed (sha1) and used for the filename that is the key for the cache.

[arnehilmann]

I am not quite sure if I understand the problem:
You are using the same (same as in 1:1 copy) code block multiple times;
due to caching based on the code block content, only one svg gets rendered and then referenced multiple times;
resulting in non-unique ids.
Is that right?

[arnehilmann]

To solve these svg-id issues once and for all, I consider replacing my (too?) simple inlining solution (pandoc filter, written in Lua) with something that runs onLoad of the deck, like https://github.com/iconfu/svg-inject
any ideas?

[openbrian]

What do they say the 2 hardest problems in programming are? Variable naming, cache algorithms, and the off by one issue.

I was always a fan of xhtml, and how the svg namespace could reside in it, with validation! I just used the python html5 validator to find all the dupe IDs.

I'd lean towards keeping it embedded on the server side. I like being able to open a plain HTML file in the browser and not needing a web server. Though you can still use onLoad that way, I think. And you could still load references (src) to svg files.

I think using pandoc lua plugins is fine. But maybe a node based webserver that calls PHP on the command line is overkill.

When markdeck/pandoc calls a2sketch, does it have to be over http? Maybe markdeck can docker mount a volume that has the a2sketch php command. That's a different issue. Not to mention the php project is EOL.

[arnehilmann]

But in this case, the caching algorithm actually works... 🤔
We cannot blame the caching for its re-using the svgs, introducing the id-problem.
And we cannot drop the caching, because otherwise the images would be rerendered on every change (and rerendering already takes much longer than I like).
So, I think about something like this: if the pandoc filters detects that an svg with the same name was already rendered previously (i.e. in the same pandoc run), then a2sketch gets called again and the result gets stored under a different name (that name gets calculated not only based on the content alone, but also on a running number). Thus we have different ids (because the svg was rendered twice) and we have caching (because the file name can be computed beforehand).

And yes, both nodejs and php are not my first-choice languages, but until a few month ago a2sketch was rather on the markdeck periphery. So, it could need some overhaul/refactoring (when I am done with the markdeck issues)...
The sole reason for sticking with the not-longer-supported version of a2sketch is the support of custom shapes; some users are using them quite intensively, so as long as the container isn't imploding I will stick with the php version...

[arnehilmann]

Please give markdeck 0.54.2 a try: identical render_a2s code blocks should result in different svgs, thus avoiding the (non)unique-id-experience...