GNOME Bugzilla – Bug 108293
object placement is OS-dependent (font dependent)
Last modified: 2009-01-09 22:29:07 UTC
If I make a UML .dia file under Windows, and then view it under Linux, the arrows no longer attach to the boxes. (Win98, Debian Linux x86). (And yes, I'm filing the bug from MacOS.)
Dont use the release candidate builds of Dia, they are totally and absolutely just for beta testing. Please use the proper release versions. If you can I would appreciate if you could upgrade to 0.91 on both platforms and confirm that this problem still occurs. It would probably be helpful if you could attach the Dia file to this bug report, and i will try and check this out (I have Redhat, but i think the Cyrille and possibly Lars both use Debian).
I confirm the problem still happens, sometimes even within the Linux version. However, it seems to be just an effect of the font-scaling problem, already known.
Still there :)
Got a similar problem when upgrading dia under Windows. Installed newer dia on new box, opened old file and all the positions/sizes are screwed. The file contains a whole bunch of "ER - Entity" boxes joined by "Standard - Line" lines. Speculation ----------- When the file first loads, I noticed that the fonts appear to be a different size. The width of the boxes would appear to be dependant on the size of the font? eep! The (top?) left of the box would seem to remember where it was, but now that the right and center box nodes are in the wrong position, all of the lines joining them are situated in the old (and wrong) position. What is interesting is that although they no longer connect, as soon as I tried to do anything to the box such as move it, the lines would appear to all remember where they were connected to, and jump to the correct position (although the resizing of the boxes means now that the layout is still screwed). To further speculate, I would suggest that when you save the file, you save not just the top left, but also the bottom right. When you load the file and rerender it, do a double check that the sizes of the objects haven't changed due to font problems or what have you. If it has, a temporary solution would be to at least warn the user that the sizes of some things have changed and blah blah blah... "Continue/Don't Load". I guess a longer term solution might maybe be that if the object size changes, you set the object to use fixed size instead of text-dependenat, or something along those lines.
Created attachment 35879 [details] The file I discuss in comment #4 This file breaks badly when the font size changes, as has happened to me when upgrading to 0.94 from an older version.
Your speculation is right, the box size does depend on the font size. That is because different fonts (depending on what is installed as "sans", for instance), different zoom levels and even different renderers (Pango vs. old GTK vs. Win32) can give different sizes of the texts. If we left the box the same size, the texts would overlap the edges. A slight improvement would be to automatically move the lines connected, though that may leave other things messed up. Remembering the wanted length of text and forcing it to stay that size would be better, though the interaction between when the size changes, when the text changes, and when the font size changes is not trivial, and has to be intuitive. Upgrading from 0.90 or earlier to 0.91 or more has a big change in rendering system that would cause mayor messes. After that, the size should be much more stable.
*** Bug 122315 has been marked as a duplicate of this bug. ***
*** Bug 325596 has been marked as a duplicate of this bug. ***
*** Bug 381241 has been marked as a duplicate of this bug. ***
*** Bug 498766 has been marked as a duplicate of this bug. ***
The OS dependency is finally gone. When using the same fonts the produced sizes are finally identical between X (freetype2) and win32. I don't think it is feasible to ask for more ;) 2009-01-09 Hans Breuer <hans@breuer.org> * lib/font.h : declare dia_font_get_size() * lib/libdia.def : export it * lib/font.c : use pango_font_description_set_absolute_size() - the magic factor which tried to compensate for fontmap resolution issues _and_ the difference between Dia's intention of "font_height" and Pango's "font size" is gone. There is a much less magic factor just compensating the second issue. Dia's font-height always meant something like line height, i.e. a good difference between two consecutive lines baselines (Pango itself is using line_height=ascent+descent). Instead of searching the right size for a given height a new factor got introduced, which unfortunately changes the font-size on win32 and X, but all this finally fixes bug the OS dependent part of bug #108293