Forums

Another idea is to make the rendering information a view style which can
be preloaded into JDesigner, that way we don't have to put any rendering
information into the SBML file just your layout info. Thinking more
about this possiblity, this might be the way to go, in this case we will
probably delay release of the new version.

I looked at the example you sent and I don't fully understand how to
interpret the reaction glyphs. Take for example the reaction:

2PG -> PEP + H2O

The XML code to specify this is given at the end (in the usual verbose
XML way). I don't understand what the four curve specifications are for
since I only need three to draw the reaction are, which ones do I use
for this? In particular what is the first curve for?

Herbert

-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <reactionGlyph id="glyph_Enolase"
reaction="Enolase">
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curve>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <listOfCurveSegments>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curveSegment xsi:type="LineSegment">
<start x="170" y="1290" />
<end x="170" y="1320" />
</curveSegment>
</listOfCurveSegments>
</curve>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <listOfSpeciesReferenceGlyphs>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <speciesReferenceGlyph
id="SpeciesReferenceGlyph_08" speciesReference="ref_2PG_2"
speciesGlyph="glyph_2PG" role="1">
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curve>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <listOfCurveSegments>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curveSegment xsi:type="LineSegment">
<start x="170" y="1290" />
<end x="170" y="1240" />
</curveSegment>
</listOfCurveSegments>
</curve>
</speciesReferenceGlyph>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <speciesReferenceGlyph
id="SpeciesReferenceGlyph_19" speciesReference="ref_PEP_1"
speciesGlyph="glyph_PEP" role="2">
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curve>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <listOfCurveSegments>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curveSegment xsi:type="LineSegment">
<start x="170" y="1320" />
<end x="170" y="1370" />
</curveSegment>
</listOfCurveSegments>
</curve>
</speciesReferenceGlyph>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <speciesReferenceGlyph
id="SpeciesReferenceGlyph_29" speciesReference="ref_H2O_1"
speciesGlyph="glyph_H2O_1" role="4">
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curve>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <listOfCurveSegments>
-
<file:///C:/Program%20Files/Borland/Delphi7/Projects/DelphiModules/JDesi
gner/GlycolysisModel-g++.xml#> <curveSegment xsi:type="CubicBezier">
<start x="170" y="1320" />
<end x="260" y="1360" />
<basePoint1 x="170" y="1360" />
<basePoint2 x="170" y="1360" />
</curveSegment>
</listOfCurveSegments>
</curve>
</speciesReferenceGlyph>
</listOfSpeciesReferenceGlyphs>
</reactionGlyph>

_____

From: Gauges, Ralph [mailto:Ralph.Gauges@eml-r.villa-bosch.de]
Sent: Wednesday, April 13, 2005 10:26 AM
To: LibSBML Discussion List; LibSBML Discussion List
Subject: RE: [libsbml-discuss] Re: libsbml-discuss] New release of the
layoutextension



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
>