You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The above returns a sane value only if name is a string. It would be great if tspan objects are also supported.
The current workaround that I am using to avoid the bug exposed in the above screenshot is to ensure that at least one non-tspan signal lane name is longer than the tspan ones. But, this might not always be possible (particularly if some diagram requires all signal names to be rendered differently using tspan support).
The text was updated successfully, but these errors were encountered:
Ganesh-AT
changed the title
Incorrect Signal Name Computation for tspan Entries
Incorrect Signal Name Width Computation for tspan Entries
Oct 30, 2023
Please describe your system environment before submitting your Issue.
WaveDrom v3.3.0 incorrectly computes the signal name width if the name is a tspan object instead of a string. Example:
The issue is due to Line 75 in render-wave-lane.js
glengths.push(name.textWidth ? name.textWidth : name.charCodeAt ? textWidth(name, 11) : 0);
The above returns a sane value only if name is a string. It would be great if tspan objects are also supported.
The current workaround that I am using to avoid the bug exposed in the above screenshot is to ensure that at least one non-tspan signal lane name is longer than the tspan ones. But, this might not always be possible (particularly if some diagram requires all signal names to be rendered differently using tspan support).
The text was updated successfully, but these errors were encountered: