I just scanned over the document and you are right, obviously we forgot
to put the consensus we had reach in the discussion on this list into
writing. Sorry, I was under the impression that I put it in already. I
will add this at once.
As far as I remember it was agreed upon in this list that the default
unit of the layout would be a pt which is 1/72 inch.
The dimension of the whole diagram can then be easily calculated from
the components. Or do you think we would need to specify the dimension
of the diagram somewhere? We actually thought that this information was
not necessary because it could be deduced while reading in the objects.
Thanks for the feedback
On Dienstag, September 9, 2003, at 07:42 Uhr, Herbert M. Sauro wrote:
> Ralph, the main reason why I was going to look at Jonathon's proposal
> first was because he has some dimensioning information which means I
> what size to draw the diagram. As far as I can tell your proposal does
> have this information, are there even any default dimensions? As a
> result I am
> unable use your proposal as it stands. If I have a mistaken view here
> please correct me, and if you have suggestions on sizing the layout
> expressed in EML, I'd be happy to listen. I think Jonathon has yet to
> specify the font sizing, at the momemt the proposal suggests using the
> unitsin the diagram, not sure if this is a good idea as traditionally
> info is expressed in pts. Currenlty even Jonathon's proposal will not
> easy to use. So there appear to be issues with both. In
> Jdesigner I use pts to indicate font sizes and dimensions are set by
> default to by 92dpi. I have a version 2 (unpublished) which adds
> material but this was done before the DWG got going.
> On Fri, 5 Sep 2003, Ralph Gauges wrote:
>> Sorry for the delay, but with everybody on vacation, this has been
>> lying around for some time.
>> In case anybody is wondering. This is the next version of a proposal
>> for a layout extension to SBML2.
>> This version includes some important new features like the possibility
>> to group several layout objects and the possibility to specify edges
>> denote relations.
>> We also incorporated the suggestions we got from the discussion. E.g.
>> the syntax is now more SBML like as references attributes are called
>> after the thing that is being referenced. So the reference attribute
>> the SBML compartment id in the compartmentGlyph is now called
>> compartment. We also got rid of all the ...GR(s), they are now called
>> There are some smaller changes (See "List of Changes" in the
>> We tried to come up with layout problems that can not be solved with
>> this proposal and so far we have not been able to come up with any. So
>> if you know of some layout that can not be specified in terms of this
>> proposal, please let us know.
>> There has been a new proposal for a layout extension by Jonathan Webb
>> few days ago. We would have preferred for Jonathan to give us some
>> feedback as to what he didn't like about the proposal that was already
>> there and so help to speed things up, because this is what a
>> list is for and this is the reason why we made the proposal to the
>> discussion list in the first place.
>> Looking at his proposal we think that it is missing some things
>> that our proposal already has and that we think are important.
>> 1) Jonathan himself stated in his document that it was not a full 3D
>> specification, but rather 2.5D. But with the inclusion of geometry
>> information on compartments in upcoming versions of SBML, we think
>> the proposal should include the possibility to render objects in 3D.
>> 2) Jonathan's proposal takes color specifications from HTML and limits
>> colors to RGB instead of RGBA. Partly transparent objects might really
>> be useful when working with 2.5D or 3D layouts, so colors should
>> have an alpha channel.
>> 3) As has been noted in earlier discussions on this list, there was an
>> agreement that metaids should not be used to reference objects.
>> does this in his edge.
>> 4) In the edge object of his proposal, Jonathan references the species
>> reference of the model for the edge, but since a species can be
>> represented by several graphical objects in a layout, there is no easy
>> way to
>> find out which of possibly several species glyphs should
>> be connected to a given reaction. He tries to circumvent this problem
>> by identifying the species glyphs by coordinates which will fail if to
>> species glyphs share the same coordinates.
>> We are aware of the fact that so far our proposal only includes
>> information since we wanted to separate the layout information from
>> render information. So in order to get an agreement on the layout
>> we did not do much work on the render part yet. As we took from the
>> discussion, there was some agreement as to that it was a good idea to
>> separate render and layout information. As stated above, we tried to
>> find layout examples that could not be implemented with this proposal
>> and so far we found none. If someone finds such an example we would be
>> glad to hear of it so we could make the necessary changes. We also
>> would very much like more feedback on what else people are missing
>> the proposal since this is the only way we can reach an agreement.
>> Mails that only state that something is missing without ever
>> elaborating on this are therefore not very helpful and won't help in
>> reaching an agreement.
>> We feel that this proposal has come a long way and we thank all the
>> people that participated in the discussion. We don't know, if this new
>> proposal has everything that people expect of it, but as far as we are
>> concerned, we would be ready to move on to getting the specification
>> for the render information written down. Now if the majority of people
>> on this list feel that they would rather go with Jonathan's proposal
>> and work from there, we would appreciate it if you let us know as soon
>> as possible.