Forums

I totally agree that there is a lot missing, to be more specific, almost everything that relates to the actual rendering is missing since we seperated the rendering from the layout very early in process.
Back then it soon became clear that we could not get all people to agree on the whole package, so we decided to first do the layout extension so that there is some common ground to work from when it comes to the actual rendering.

So right now, I am more concerned with getting the layout nailed down and make it as good as possible while keeping it easy to implement. This said, I think we are almost there and the only additional features for the actual layout that I am missing right now is grouping and transformations.
Both of those were in an earlier proposal, but it was decided that they are to complicated. We can now either leave the layout proposal as it stands, or we can try to readd these features maybe in a way that would be less complicated. I know, I could use those features and if some other programs would make use of them as well, they should go in, otherwise we leave them out and it is up to the program to find a suitable substitute.

Concerning the rendering extensions, they could either be embedded in the layout extension, or as I would do it, be put alongside it on the same level as layout. Technically I think embedding would not be a problem since all layout classes are derived from SBase and therfore have annotations I just don't think this would be the cleanest solution.
What I would not do is mix the model and the extensions. I think the extensions should be as much seperated from the model as possible and I think it is better if the information is in one place. It works for the layout and it also should work for the render extensions. The cost of that is a little more cross referencing from layout to model. The rendering extension I actually have in mind would build on the layout extension and would probably not reference objects in the model, but rather objects in the layout which would be another reason to not embedd it in the model.
But this is just my opinion.


Ralph

-----Original Message-----
From: Herbert Sauro [mailto:Herbert_Sauro@kgi.edu]
Sent: Wed 4/13/2005 7:56 PM
To: LibSBML Discussion List
Cc:
Subject: RE: [libsbml-discuss] Re: libsbml-discuss] New release of the layoutextension


I just reread the transformation section, It certainly would be nice to
be able to specify orientations for text, but that said there are a
whole load of other things that could also go into the proposal. In the
next fews weeks or so we're about to release a new version of Jdesigner
which has a lot more facilities, this has resulted in updating our
annotation to version 2, but there is time to change this if necessary.
At the moment we're in limbo, we're wondering whether to support your
layout or both ours and yours, or currently our favourite option is to
support your layout and add the additional annotations we need (eg
colors, fonts etc) ourselves. One question is where should our
annotation go, would it be better to add it as a sub annotaiton to your
annotation (is this permitted in SBML) or to leave it where it is now,
associated with the elements they relate to?

Herbert

-----Original Message-----
From: Ralph Gauges [mailto:ralph.gauges@eml-r.villa-bosch.de]
Sent: Tuesday, April 12, 2005 11:16 PM
To: libsbml-discuss
Subject: [libsbml-discuss] Re: libsbml-discuss] New release of the
layout extension

Hello Herbert,

glad to hear that the proposal meets your expectations. We think that it
has gotten rather stable and that one can really work with it now.

I would be very interested if you had any comment on the transformation
problem I mentioned in my last mail (the one with the announcement of
the new release).
Actually any other comments on missing features are more then welcome.
As I think that transformations and grouping would be very nice features
to have back.

Currently I am working on a second example file which is a little more
complex and does a layout of glycolysis. I hope that I can finish it
today, but hand coding this is a rather lengthy procedure.

If you have any specific questions concerning the syntax or the
semantics, just write me an email.

I am looking forward to meeting Frank at the hackathon.



Ralph

On 13.04.2005, at 07:16, Herbert Sauro wrote:

>
> Ralph, as you probably know we implemented an early version of your
> layout annotation in Jdesiger some time ago. With your recent updates
> we decided to go back and update the code. In the process we
> discovered quite a few changes to your proposal and we therefore
> decided to reimplement the code, in fact we're seriously considering
> moving over completely to your proposal in preparation for the release

> of version 2 of JDesigner. In the process of doing this we need to
> make sure that we've got the syntax and semantics of your proposal
> correct and was wondering whether somewhere you have a bunch of sample

> files we could use to test the implementation. We're particularly
> interested in multi-substrate multi-product reactions and species
> aliasing. We noticed you had one sample available on your web site but

> could really do with more.
>
> Frank Bergmann will be attending the hackatghon and he will be able to

> demo the new version we have including support for your layout.
>
> Thanks
> Herbert
>
>
>
> -----Original Message-----
> From: Ralph Gauges [mailto:ralph.gauges@eml-r.villa-bosch.de]
> Sent: Monday, April 11, 2005 9:03 AM
> To: 'sbml-discuss@caltech.edu '; libsbml-discuss
> Subject: [libsbml-discuss] New release of the layout extension
>
> Hello,
>
> [ Also sorry if some of you get this twice, but I thought this was
> maybe of interest to both lists.]
>
>
> With the next Hackathon coming up so fast, I thought it might be the
> right time for a new release of the implementation of the layout
> extension. It contains some bugfixes and cleanups.
> This release is based on a CVS version of libsbml from 12/20/2004
which
> is basically version 2.2.0 with some bugfixes and some minor
> enhancements.
>
> I uploaded the patch and an already patched version of libsbml to our
> server at
>
> http://projects.eml.org/bcb/sbml/
>
> To enable the layout extension, you have to run configure with the
> "--enable-layout" command line switch prior to compiling libsbml.
> If you want to compile C or C++ programs that use classes or functions
> from the layout extension, you have to add the "-DMAKE_LAYOUT" command
> line switch to your compile command line (this is if you use gcc, for
> other compiler you have to consult the documentation of your
compiler).
>
> Additionally I uploaded three programming examples, one for C++, one
> for Java and one for Python. They all generate the same simple sample
> SBML file with layout information. Also on the webpage, you can
> download an XSLT stylesheet with which you can generate an SVG image
> from an SBML file with layout information. If you want to use this and
> are not familiar with XSLT, please contact me and I will provide you
> with some instructions on how to use this.
>
> If time permits, I will try to write another XSLT stylsheet that
> produces a PostScript file for printing. Also more complex programming
> samples are on my todo list.
>
> On the webpage, you can also see an example rendering of such an SVG
> file. It was generated from the SBML file that you get when you run
any
> of the uploaded programming samples. The PNG file was generated by
> running the rsvg program on the SVG file.
>
> This picture shows how I personally would render this layout
> information, but the stylesheet can be adapted to your needs without
> much effort.
>
>
>
> While we are at it, I also encountered a problem with the layout
> extension as it is now. Since possibility to transform objects has
been
> removed from the layout specification, it is now no longer possible to
> specify that you want to e.g. rotate a TextGlyph. That means that you
> can only have horizontal text labels in the layout. The question now
> is, if is this OK with everybody, or would some programs need text
> labels that are rotated, e.g. for labeling some reaction arrow. If
yes,
> I see two possibilities. Either we put the transformations back into
> the specification or we make this text specific by adding a new
> attribute to the TextGlyph object that specifies an angle of rotation.
> I would prefer to put the transformations back in since this would
> allow a lot more flexibility at the price of some added complexity.
> Please let me know what you think about this.
>
>
> As always if you have any comments, questions or suggestions please
> contact me.
>
> Thanks
>
> Ralph
>