Difference between revisions of "Wgraph:Known Bugs"
From FollowTheScore
(→The following bugs are known as of July, 2007:) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 8: | Line 8: | ||
* a duplicate definition of nearedges between two nodes will lead to a memory fault in aiSee. | * a duplicate definition of nearedges between two nodes will lead to a memory fault in aiSee. | ||
:: ''wgraph checks your input and avoids to generate GDL code which would lead to that error.'' | :: ''wgraph checks your input and avoids to generate GDL code which would lead to that error.'' | ||
| + | ::: We don't seem to be able to reproduce that. If you could provide an example graph, that would be greatly appreciated. | ||
| + | ::: --[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* edges do not understand "invisible yes" or "hidden"; instead "linestyle invisible" has to be used. In addition the textcolor of edge labels has to be set to "white". | * edges do not understand "invisible yes" or "hidden"; instead "linestyle invisible" has to be used. In addition the textcolor of edge labels has to be set to "white". | ||
:: ''wgraph handles this for you. But you must avoid to overwrite linestyle or textcolor once you have set a line to 'hidden' or 'invisible'. It is recommended to specify invisible/hidden as the last property within an edge definition. | :: ''wgraph handles this for you. But you must avoid to overwrite linestyle or textcolor once you have set a line to 'hidden' or 'invisible'. It is recommended to specify invisible/hidden as the last property within an edge definition. | ||
| + | ::: This is only true for labeled edges (the edge is being hidden just fine, but the label still shows up). That will be fixed in an upcoming version of aiSee. | ||
| + | ::: In the mean time, you could try switching to the <code>dirty_edge_labels</code> mode as a work-around. | ||
| + | ::: --[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* parameters for graph layout (regarding algorithms, spacing, edge control) can be defined within a subgraph declaration, but they do not have any effect. Instead they must be defined within the master graph. | * parameters for graph layout (regarding algorithms, spacing, edge control) can be defined within a subgraph declaration, but they do not have any effect. Instead they must be defined within the master graph. | ||
| + | ::: As far as I can tell, this is true for force-directed layout only. In hierarchical layout, the parameters should be interpreted and propagated correctly. If you have an example graph where this is not the case, please let me know. | ||
| + | ::: --[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* iconfiles do not display correctly in png (disturbing green pixels) | * iconfiles do not display correctly in png (disturbing green pixels) | ||
| + | ::: This is due to aiSee 2.2 having a color map of only 256 colors. That is a legacy issue and will be fixed in aiSee 3.0. | ||
| + | ::: In the mean time, the only work-around is to adapt your icons (using GIMP, Photoshop or similar) so that all the icons in a given graph use up a maximum of 256 colors (convert them to indexed PNG using a custom color palette). If you are using additional colors in the graph itself (edge colors, node border colors, etc), don't forget to account for that, too. | ||
| + | ::: The number 256 might sound very small at first, but the results are actually not bad. Here's an example of a graph that makes heavy use of icons, with anti-aliasing and shadows, yet manages with only 192 colors: [http://www.aisee.com/graph_of_the_month/euro2004.htm Euro 2004 playoff tree]. So, while converting the icons is admittedly a hassle, the results are worth it. | ||
| + | ::: Oh, and don't forget to set the graph attribute <code>iconcolors</code> to <code>256</code> and <code>fasticons</code> to <code>no</code>. (Perhaps, Wgraph should handle that internally?) | ||
| + | ::: --[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* \f- does not draw a horizontal line within a node label (although it should do so according to aiSee documentation) | * \f- does not draw a horizontal line within a node label (although it should do so according to aiSee documentation) | ||
| − | + | ::: We don't seem to be able to reproduce that. If you could provide an example graph, that would be greatly appreciated. | |
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
| + | :::::The reason was probably an error within Wgraph; now it works; in analogy to wiki syntax '----' will create a horizontal line. | ||
* in png the bitmaps are scaled by shrink/stretch/scaling, but not in svg | * in png the bitmaps are scaled by shrink/stretch/scaling, but not in svg | ||
| + | ::: Do you mean the scaling of icons or that of the entire graph? Thanks. | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* The effect of a "label" specification within the main graph is unclear | * The effect of a "label" specification within the main graph is unclear | ||
| + | ::: Both <code>label</code> and <code>title</code> have no effect for the top-level graph. They exist only for consistency reasons (since the graph format is the same for the top-level graph and the subgraphs). | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* the 'state' property is not accepted within the main graph. Why? | * the 'state' property is not accepted within the main graph. Why? | ||
| + | ::: That is actually consistency again, only a different kind of consistency (^_^). Accepting a <code>state</code> attribute for the top-level graph would mean, among other things, that the top-level graph could be folded into a single node (<code>state: folded</code>). However, GDL/aiSee does not allow a single node to exist on its own. It can only exist as an element within a graph. If you want to fold the top-level graph, you have to provide for an even higher-level top-level graph, and thus you run into an endless recursion. So basically, we cannot allow the top-level graph to have a state other that <code>unfolded</code>. | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* aiSee produces memory violations if (a) a node has two right near edges or two left near edges or a left and a right near edge AND a rightbentnear edge or a leftbentnear edge is added. Wgraph recognizes this situation and warns you. | * aiSee produces memory violations if (a) a node has two right near edges or two left near edges or a left and a right near edge AND a rightbentnear edge or a leftbentnear edge is added. Wgraph recognizes this situation and warns you. | ||
| + | ::: Do you happen to have an example graph? Thanks in advance. | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
| − | * textmode right_justify, left_justify and center do not work | + | * textmode right_justify, left_justify and center do not work consistently. (a) Only the length of the first line is taken for calculations; (b) in combination with bitmap fonts results are generally not what one would expect. |
| + | ::: That will change in upcoming versions (aiSee 3.0 for Mac OS X already handles that with much more grace). | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
* if wgraph produces invalid GDL then aiSee will "hang" as it expects a confirmation from the console. This should be changed because the user will get no answer and the server will be flooded with open processes. | * if wgraph produces invalid GDL then aiSee will "hang" as it expects a confirmation from the console. This should be changed because the user will get no answer and the server will be flooded with open processes. | ||
| + | ::: We'll see if we can fix that in an upcoming version. Also, we've forgotten to mention at our meeting that the current Windows and Unix versions of aiSee behave differently in that respect. While the Windows version does wait for confirmation, the Unix version should just quit. In other words, you might be running into problems in your development environment (Windows) which don't actually occur on the production server (Linux). Can you verify/falsify that? | ||
| + | :::--[[User:Schwallex|Schwallex]] 00:30, 7 October 2007 (CEST) | ||
[[Category:wgraph]] | [[Category:wgraph]] | ||
Latest revision as of 18:14, 21 October 2007
The following bugs are known as of July, 2007:
- borderstyle double or triple might look crippled at nodes which are placed at top and/or left border of the graph
- xbase,ybase could be set to a value greater than the default (=5) to avoid this
The following problems exist with GDL / aiSee:
- a duplicate definition of nearedges between two nodes will lead to a memory fault in aiSee.
- wgraph checks your input and avoids to generate GDL code which would lead to that error.
- We don't seem to be able to reproduce that. If you could provide an example graph, that would be greatly appreciated.
- --Schwallex 00:30, 7 October 2007 (CEST)
- wgraph checks your input and avoids to generate GDL code which would lead to that error.
- edges do not understand "invisible yes" or "hidden"; instead "linestyle invisible" has to be used. In addition the textcolor of edge labels has to be set to "white".
- wgraph handles this for you. But you must avoid to overwrite linestyle or textcolor once you have set a line to 'hidden' or 'invisible'. It is recommended to specify invisible/hidden as the last property within an edge definition.
- This is only true for labeled edges (the edge is being hidden just fine, but the label still shows up). That will be fixed in an upcoming version of aiSee.
- In the mean time, you could try switching to the
dirty_edge_labelsmode as a work-around. - --Schwallex 00:30, 7 October 2007 (CEST)
- wgraph handles this for you. But you must avoid to overwrite linestyle or textcolor once you have set a line to 'hidden' or 'invisible'. It is recommended to specify invisible/hidden as the last property within an edge definition.
- parameters for graph layout (regarding algorithms, spacing, edge control) can be defined within a subgraph declaration, but they do not have any effect. Instead they must be defined within the master graph.
- As far as I can tell, this is true for force-directed layout only. In hierarchical layout, the parameters should be interpreted and propagated correctly. If you have an example graph where this is not the case, please let me know.
- --Schwallex 00:30, 7 October 2007 (CEST)
- iconfiles do not display correctly in png (disturbing green pixels)
- This is due to aiSee 2.2 having a color map of only 256 colors. That is a legacy issue and will be fixed in aiSee 3.0.
- In the mean time, the only work-around is to adapt your icons (using GIMP, Photoshop or similar) so that all the icons in a given graph use up a maximum of 256 colors (convert them to indexed PNG using a custom color palette). If you are using additional colors in the graph itself (edge colors, node border colors, etc), don't forget to account for that, too.
- The number 256 might sound very small at first, but the results are actually not bad. Here's an example of a graph that makes heavy use of icons, with anti-aliasing and shadows, yet manages with only 192 colors: Euro 2004 playoff tree. So, while converting the icons is admittedly a hassle, the results are worth it.
- Oh, and don't forget to set the graph attribute
iconcolorsto256andfasticonstono. (Perhaps, Wgraph should handle that internally?) - --Schwallex 00:30, 7 October 2007 (CEST)
- \f- does not draw a horizontal line within a node label (although it should do so according to aiSee documentation)
- We don't seem to be able to reproduce that. If you could provide an example graph, that would be greatly appreciated.
- --Schwallex 00:30, 7 October 2007 (CEST)
- The reason was probably an error within Wgraph; now it works; in analogy to wiki syntax '----' will create a horizontal line.
- in png the bitmaps are scaled by shrink/stretch/scaling, but not in svg
- Do you mean the scaling of icons or that of the entire graph? Thanks.
- --Schwallex 00:30, 7 October 2007 (CEST)
- The effect of a "label" specification within the main graph is unclear
- Both
labelandtitlehave no effect for the top-level graph. They exist only for consistency reasons (since the graph format is the same for the top-level graph and the subgraphs). - --Schwallex 00:30, 7 October 2007 (CEST)
- Both
- the 'state' property is not accepted within the main graph. Why?
- That is actually consistency again, only a different kind of consistency (^_^). Accepting a
stateattribute for the top-level graph would mean, among other things, that the top-level graph could be folded into a single node (state: folded). However, GDL/aiSee does not allow a single node to exist on its own. It can only exist as an element within a graph. If you want to fold the top-level graph, you have to provide for an even higher-level top-level graph, and thus you run into an endless recursion. So basically, we cannot allow the top-level graph to have a state other thatunfolded. - --Schwallex 00:30, 7 October 2007 (CEST)
- That is actually consistency again, only a different kind of consistency (^_^). Accepting a
- aiSee produces memory violations if (a) a node has two right near edges or two left near edges or a left and a right near edge AND a rightbentnear edge or a leftbentnear edge is added. Wgraph recognizes this situation and warns you.
- Do you happen to have an example graph? Thanks in advance.
- --Schwallex 00:30, 7 October 2007 (CEST)
- textmode right_justify, left_justify and center do not work consistently. (a) Only the length of the first line is taken for calculations; (b) in combination with bitmap fonts results are generally not what one would expect.
- That will change in upcoming versions (aiSee 3.0 for Mac OS X already handles that with much more grace).
- --Schwallex 00:30, 7 October 2007 (CEST)
- if wgraph produces invalid GDL then aiSee will "hang" as it expects a confirmation from the console. This should be changed because the user will get no answer and the server will be flooded with open processes.
- We'll see if we can fix that in an upcoming version. Also, we've forgotten to mention at our meeting that the current Windows and Unix versions of aiSee behave differently in that respect. While the Windows version does wait for confirmation, the Unix version should just quit. In other words, you might be running into problems in your development environment (Windows) which don't actually occur on the production server (Linux). Can you verify/falsify that?
- --Schwallex 00:30, 7 October 2007 (CEST)
