Welcome to yEd Q&A!
Here you can ask questions and receive answers from other members of the community and yEd developers. And you can tell us your most wanted feature requests.

Consider spatial resolution

+1 vote
I would really appreciate making yEd "aware" of spatial resolution.

At the moment I really enjoy the control I have over the layout of the graph but I find it really difficult to produce an image where I can control the physical size of the objects.

I have a rather large graph which is to be embedded to a poster and become about 80cm wide.

Ideally, I would like to be able to control the size of the graphical elements (font size, node width and height, edge width, etc) in physical units (e.g. mm) by setting a rasterisation resolution (e.g. 300 dpi) from the preferences window. At the moment, I am doing the transformations manually and I must say it is really difficult, primarily because of the size of the graph, both in number of nodes but also physical size.

Looking forward to a more spatial resolution aware yEd :)
asked May 2, 2015 in Feature Requests by anonymous

1 Answer

0 votes

When printing at (user-defined) scaling of 1, then 72 space units will be 1 inch (or 2.54cm) on the print out.

Please see what is scaling, and does it effect margins and created graph size for a more detailed explanation.

answered Apr 15, 2016 by thomas.behr [yWorks] (122,590 points)
Is this not something that can be controlled by the user or is it not considered as high priority at the moment?

The point here is to be able to control the output of yEd in a meaningful way and that is in physical units.

What I do not get at the moment is whether the scaling is applied before or after rasterisation. If it is applied after rasterisation, then the resolution is not affected.

Perhaps the more accurate question here is "How is it possible to relate the size of the rendering to its physical size".

A related problem that I am facing at the moment is that some layouts appear to be too sparse. This means that the diagram has to be rendered at a high scaling factor (so that the letters are legible) at which point the whole operation runs out of memory.

I think that adding the capability of working with physical sizes is worth the trouble. For example, the control that graphviz allows for its output is incredible both in vector and raster formats.

All the best

Java's printing framework does not expose the actual print resolution to the rendering client but requires the rendering client to always work on 72dpi. I.e. this is something we have no control over.

 

The user-defined scaling that can be specified in yEd's printing options is applied before rasterization.

 

The answer to the question "How is it possible to relate the size of the rendering to its physical size" is the formula

print-size = (size-in-space-units * scaling) / 72

with print-size being in inches and size-in-space-units being the value that yEd displays as width or height for nodes.

 

You can "condense" layouts by adjusting the properties of the layout algorithm(s) used for arranging your diagram or by using the "Scale" operation from "Tools" -> "Geometric Transformations".

 

Finally, do you have a link to a site that shows/explains the Graphviz control you mentioned?

The first part of the comment is encouraging. There will shortly be a chance of producing large prints again (~A2 or bigger), so I will give that a go again and see how it works. I have been doing the same by:

1. Produce a draft low res rendering. 2. Measure the width of the reference node (the node that I want to make sure that it will be the "smallest" but still legible). 3. Workout the scaling 4. Apply scaling to get the final size

Which however, does not match exactly for some reason :/ Will try it again soon and let you know, I am not sure if I used inches or mm in my case and since the 72 is with reference to inches, this may have introduced the offset.

The "shrink" is not practical. It does do what it is supposed to do but for large graphs it is totally impractical. I wonder if an "implode" option would be worth considering. Shrink step, check for minimum distance, stop the nodes that are in minimum distance, shrink, check, shrink check, etc until no more nodes can be moved. And clusters can be taken into account in the imploding as well so that the layout is shrunk consistently.

Yes, the link is this one and the key options are: dpi, fixedSize, height, page etc. That is, key properties that determine the graph's appearance can be specified in physical units so that you get an idea of what the rendering is going to look like.

When I design a poster for example (not necessarily for a conference), I don't design based on what I see on the screen but what this thing is going to look like in reality. So I always work with a ruler and physical scrap bits of paper if required. In Inkscape, when I am drafting the layout I can say "I want this area to be 50cm x 50cm". And the software handles everything, including the image resampling (if required) so that the image occupies the intended space (NOT its spatial resolution's space). In the bigger picture of what yEd does, this might look like a detail. But having to constantly work with derived numbers is tiring when you consider that you may have a large number of them.

All the best

Imprint | Privacy Policy