Forums

That's good news. I don't think we need information on the overall
dimensions of the diagram, simply the units for coordinates and fonts.
72dpi sounds correct, font infomation I feel should be in pts since one pt
equals 1/72 inch.

Herbert


On Wed, 10 Sep 2003, Ralph Gauges wrote:

> 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
>
> Ralph
>
> 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
> > know
> > what size to draw the diagram. As far as I can tell your proposal does
> > not
> > 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
> > do
> > 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
> > font
> > info is expressed in pts. Currenlty even Jonathon's proposal will not
> > be
> > 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
> > further
> > material but this was done before the DWG got going.
> >
> > Herbert
> >
> >
> > 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
> >> to
> >> 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
> >> to
> >> the SBML compartment id in the compartmentGlyph is now called
> >> compartment. We also got rid of all the ...GR(s), they are now called
> >> ...Glyph(s).
> >> There are some smaller changes (See "List of Changes" in the
> >> document).
> >>
> >> 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
> >> a
> >> 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
> >> discussion
> >> 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
> >> that
> >> 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
> >> really
> >> 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.
> >> Jonathan
> >> 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
> >> layout
> >> information since we wanted to separate the layout information from
> >> the
> >> render information. So in order to get an agreement on the layout
> >> part,
> >> 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
> >> from
> >> 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.
> >>
> >> Ralph
> >>
> >
>