Can you adjust the scale of live-rendered waveforms?

[bradleyharden]

I would prefer to live-render waveforms with inline javascript. But in some cases, the waveform is slightly wider than the page width. In those cases, I would prefer to scale down the image slightly, rather than use a scroll bar. I can accomplish this by switching to images, but it looks like images are generated using the wavedrompy library, which is out of date. I get very different results when rendering as an image.

Is it possible to scale the rendered javascript? It looks like the image options have no effect when inline javascript is enabled. If this isn't possible right now, is that a feature that could be implemented?

[bradleyharden]

I don't know much about HTML, but I was able to easily edit the output of Sphinx to get what I want. I only had to change the SVG height to auto and the width to a custom value. Would it be possible to set image dimensions from the reST directive for live-rendered plots? It seems like it would probably be pretty straightforward.

[bavovanachte]

Hi,

• I'll try to take a look at this still this week. I'm a bit swamped at the moment though, so can't promise much. Any concrete input from your trials would be welcome (the actual html changes you made, the actual diagram if you're allowed to share it) and could speed things up.
• As for the wavedrompy part, I'm sure @wallento would be interested in the different behaviour you noticed (maybe in an issue in the wavedrompy project, not here 😄 ) Getting the wavedrom-cli tool integrated would also be cool, but I don't see that happening short-term

[bradleyharden]

I did some research. It looks like it's not really possible to change the scale when live-rendering. The image tag doesn't exist until the JS runs, and Wavedrom does not have the ability to set the width or height of the output from javascript. You get what you get.

However, the wavedrom-cli is dead simple to use. I think that is the best path going forward. It's not a Python dependency, but it's not difficult to install. I appreciate what @wallento has done with wavedrompy, but I don't know that it makes sense to maintain an entirely independent rendering engine when wavedrom-cli exists. It makes the system Python-only, but it comes at the cost of a significant maintenance burden. He even mentions in the code for wavedrompy

# Originally translated to Python from original file
# Now many parts have been rewritten and diverged

We've already seen that it has become out of date as Wavedrom has evolved.

I think I can add support for the wavedrom-cli fairly easily. Would you accept a PR? I don't think we need to install it for the user though. I think we can just provide instructions on how to install it manually in the README. Do you like that approach?

[bradleyharden]

By the way, right now wavedrom-cli can only write to and read from files. You can't pipe data to or from it. In the first iteration of wavedrom-cli support, I would use temporary files. But I would also like to make a PR to wavedrom-cli to add support for piping. It used to support piping, but something about the interface was changed, and support was dropped. I think it will be easy to add it back though.

[bavovanachte]

I think I can add support for the wavedrom-cli fairly easily. Would you accept a PR?

I'd absolutely welcome such a PR.

I don't think we need to install it for the user though.

Agreed. I think we can assume that the user has installed it and the executable is in the path. We can indeed link to the installation instructions in the README

In the first iteration of wavedrom-cli support, I would use temporary file

I'm fairly sure that's also how the plantuml sphinx plugin works. Seems like a good start to me!

[bavovanachte]

For clarity, could you close this issue and open a separate one for the wavedrom-cli integration?

[bradleyharden]

Sure. See #23.