Open ariutta opened 6 years ago
Hmm... The current way is how other tools do it as well, e.g., Cytoscape. I'd be concerned that if we change this, then all other tools that visualize GPML will be "off" a bit, unless they change too.
My first question is why change this at all? What is the bug or issue caused by the current definition of width and height?
The thing is that there is no current definition. There's only the subjective visual inspection of what PathVisio-Java does, and that varies depending on zoom level.
Ok. So we explicitly define GPML width and height as "the actual width and height", without specifying inner, outer, mid, etc... because those vary on zoom level? This means no change to how width and height are actually parsed and rendered in our current tools? That's fine with me.
Or, do you mean, let's explicitly define GPML width and height as "the outer width and height" (like described here) and it just turns out that PathVisio-Java is wrong sometimes, but nothing changes in the code in terms of parsing and rendering?
I'm also fine this with! :)
Yes, the latter.
I'm proposing we explicitly define GPML
Width
andHeight
to be actual width and height. See this issue for more details. Sound OK?