Customizable Helicorder Y-Label Spacing

[NavigSB]

Hey Phillip! I have a suggestion for some new functionality, and I'd be happy to make a quick implementation of it and make a pull request if you like the idea. This is Gavin from PNSN, by the way :)

1. Problem Statement

On the Helicorder element, when the seismograph rows get too close together, the time labels get hard to read because they render on top of each other. The reason we don't just avoid this problem by keeping them spaced apart, I've been told, is that seeing seismographs closer together for long time ranges makes it easier to see patterns or something like that (not a seismologist lol).

2. Describe the solution you'd like

The Helicorder config could have an option for timeLabelSpacing or something like that, which would control how many lines are rendered on the Helicorder. The option would use the value as an amount of lines to "skip" as it draws. A spacing of 0 would mean drawing every line, 1 would mean drawing every other line, etc.

I think this functionality would go well into the drawSeismograms method in helicorder.ts, using the modulus operator to skip a certain amount of line labels according to the config.

3. Assumptions

• The easiest implementation to solve this issue is adding a configuration option rather than a dynamic spacing system that may not always be what users want, if they want any dynamic spacing at all.
• Users would be satisfied with this option of handling the dynamic spacing themselves.

4. Use Cases

• When a user changes the line spacing to be smaller than the font size through the overlap config option, they would simultaneously reduce the timeLabelSpacing option to compensate.

[crotwell]

Sounds interesting, so yes.

I wonder if instead of "skipping" n rows, the config could be a multiplicative factor to decide what get labeled, so 1 is every line, 2 is every other line, etc. This, I think, fits with other common config options, like css ":nth-child".

I am less confidant that auto-determining the value when font size causes overlap. I my experience, you don't know the size of things, especially text stuff, until after the render step, so can be hard to precompute whether it will overlap or not. But if you have ideas, happy to hear them as there are other places where I have wanted to avoid text overlap but have not been able to figure out how to calculate how to size things. For example, seismograph has a xLabel and an xSublabel, but I have not figured out how to automatically adjust the margin for them so they don't overlap.

[crotwell]

Taking the css idea a bit further, if you could say label An+B rows where the config give A and B, then you have a lot of power to do a lot of variations.

[NavigSB]

Sounds like a good idea to me! I agree that it's hard to figure out good levels for when text starts to overlap, which is the main reason why I think manual config by the user is probably the best solution. In our project, we've basically just used the value 12 as the lowest amount of pixels apart that the seismographs should be just from experimenting, but I think it's really just user dependent on what they think looks good; like you said, hard to truly calculate it.

So, sounds good, I like the idea of using 1 being every line for timeLabelSpacing, then maybe a timeLabelOffset for that B value you mentioned. I'll get started on a PR 👍

[crotwell]

How about using this to get a and b from "an+b" and just have a single config item that allows both?

export function anplusb(value): Array<Number> {
  let a;
  let b = 0;
  if (typeof value === "number" && Number.isSafeInteger(value)) {
    a = value;
  } else if (typeof value === "string") {
    const re = /(\d+)\s*n\s*(?:\+\s*(\d+))?/;
    const m = re.exec(value.trim());
    if (m != null) {
      a = parseInt(m[1]);
      if (isDef(m[2]) ) {
        // will be undef if string doesn't contain "+b", default to 0
        b = parseInt(m[2]);
      }
    }
  }
  if (!isDef(a)) {
    throw new Error(`Unable to parse as 'an+b' like '3n+1', ${stringify(value)}`);
  }
  return [ a, b ];
}

[NavigSB]

Hey Phillip! Do you think there's any way we could get an alpha version (or some other mechanism) to test these new changes on our end? Or what's your policy on that?

[crotwell]

Sure, you can always npm run compile to build the standalone js file (will be in ./dist). Or if you are using something that uses npm, you can npm link in your seisplotjs checkout, and then npm link seisplotjs in your project. Sometimes there are cache issues (vite in pariticular, sometimes need to rm node_modules/.vite to reset things), but otherwise it seems to work, at least part of the time. :)

I have no problem with you using/testing alpha versions. I do hope to get to do some work on sp soon and release a new version, but seem to have been having trouble finding time lately.

Is that what you are asking?

[NavigSB]

Yeah, thanks! What I was basically thinking of was adding another alpha tag to make npm install-ing slightly easier, but I realize now that it's not much different from directly installing from a commit when there's only one change involved, which sounds fine to me 👍