Re: UML and Fonts when changing monitor resolution
From: "Cameron S. Watters" <cam-listsubs h2os org>
To: <dia-list gnome org>
Subject: Re: UML and Fonts when changing monitor resolution
Date: Wed, 23 Jan 2002 13:10:54 -0800 (PST)
BAH> > I saw that. This is the lesser of my two problems as Dia seems to do what
BAH> > you describe pretty well if I make sure the lines actually attach to the
BAH> > connection points of the various objects. The only problem is that when
BAH> > switching between resolutions, some objects have to be moved slightly in
BAH> > order for the connection lines to remain straight (i'm anal ok?).
BAH>
BAH> Hmmm... let me see if I got this one straight <g>.
BAH> You want to have the lines sorta "connected" to the objects, yet don't want
BAH> to actually connect them (à la "red handle"), because that makes the lines
BAH> not 100 % vertical/horizontal in some cases?
BAH>
BAH> In that case, what about using zig-zag lines?
BAH> (It's what I do at least...)
No, I was just indicating that I had seen your solution, and was pretty
much happy with the way that dia does it (which is actually connecting
them with the red handle). What I've actually since determined is my
(the?) problem is that connection points "move" position because the
position of the connection point is based on the width of the class
object. When the class object size changes (because the different font
used at the different resolution causes the font_string_width function to
return a different value than when it was at the larger resolution), it
changes the position of the connection point in relation to the position
of other objects. This means that when the lines are actually connected
between two connection points, they may end up at odd angles when dia
recalculates the dimensions of the class objects, and therefore the
position of the connection points. Mostly I was just saying this
particular issue is not that big of a deal, but that I'm just super anal,
and that that is why I had mentioned it. I also seem to be wordy.
BAH> > BAH> What about scaling the entire diagram down to a lower factor? This
BAH> should
BAH> > BAH> cause smaller fonts to be selected as well.
BAH> >
BAH> > My document was built scaled down to 25. Also, changing the scale doesn't
BAH> > seem to do anything for me on screen WRT font size. It just makes the page
BAH> > borders on the background move.
BAH>
BAH> Zoom?
Well, let me clarify since we've now introduced both settings into the
discussion:
I'm assuming by "scale" you meant the setting in the diagram's "Page
Setup" dialog. By default this value is set to 100, but I usually reset it
to 20 or 25 because otherwise my UML class definitions take up an entire
page by themselves.
There is additionally a "zoom" setting at the bottom of the page. While I
find the zoom setting useful changing my perspective on the diagram
(especially nice for multipage diagrams), changing my zoom level doesn't
really solve the problem outright. If I zoom it way out, or way in,
sometimes the on-screen representation looks pretty much right, however,
printing is still an issue. Even if I play with the zoom so that it looks
right on the screen, it still doesn't size the class diagrams correctly
for printing. While I'm ultimately more concerned about onscreen at the
moment, zooming out to 25% or in to 200% makes working with the document
pretty cumbersome.
And finally, if someone could just point me to a way to make _only_ the
UML object library (libuml_objects.so) without having to make the rest of
dia, I'd leave everyone alone and hack a mod to it so that it estimates
the width a little better (should be a pretty straightforward hack).
I must also admit that my favorite comment in the code so far (which
actually seems to be at the root of this issue) is in the function
font_string_width in lib/font.c :
/* Note: This is an ugly hack. It tries to overestimate the width with
some magic stuff. No guarantees. */
--cameron