Hello Chris,

thanks for your quick response on the texts of menu items.

What follows is on zooming of long node editors, and is a bit longer post.

I have set the property
"experimental_font_sizing_for_long_node_editors" to "true" in
"auto.properties" in 0.9.0 RC8, and then have tested the long node
editors upon zooming. Both the plain text and rich text editors of
long nodes show zooming as they should, and look basically okay, so
congratulations! However, both plain text node editor and rich text
node editor show slightly larger fonts than the node viewers. When I
set the property "experimental_font_sizing_for_long_node_editors" to
false, only plain text long node editor zooms, but again with slightly
larger fonts than the node viewers. So the only zooming issue to be
solved is the determination of proper font size for the long node
editors, regardless whether plain text or rich text. The property
"experimental_font_sizing_for_long_node_editors" can be removed, and
zooming of the rich text node editor should be switched on by default.

I have found a fix to the problem of slightly larger fonts. I have
tested the fix: I have FreeMind 0.9.0 RC8 source code in Eclipse, and
I can run it in a debug mode.

The fix requires an adjustment of the method Tools.updateFontSize:

1390  public static Font updateFontSize(Font font, float zoom, int
normalFontSize) {
1391    if (font != null) {
1392    float oldFontSize = font.getSize2D();
1393    float newFontSize = normalFontSize * zoom;
1394    if(oldFontSize != newFontSize)
1395    {
1396    font = font.deriveFont(newFontSize);
1397    }
1398    }
1399    return font;
1400    }

The adjustment consists in replacing

1396 font = font.deriveFont(newFontSize);

with

1396 font = font.deriveFont(newFontSize  * 0.97F);

An explanation for why the fix is needed follows. In FreeMind 0.9.0,
the method NodeView.updateFont shows no zooming code. Then how is it
achieved that the node views actually appear zoomed? It is achieved in
the method MainView.paint, where there is some magical zoom correction
factor: zoom *= ZOOM_CORRECTION_FACTOR, which is "static final float
ZOOM_CORRECTION_FACTOR = 0.97F;"

Of course, the constant ZOOM_CORRECTION_FACTOR should be used in Tools
instead of "0.97F", but this requires that the constant is made public
in MainView.

The magical constant can alternatively be placed in the class
EditNodeWYSIWYG.java, where it says:

189 if 
(Resources.getInstance().getBoolProperty("experimental_font_sizing_for_long_node_editors"))
{
190     /* This is a proposal of Dan, but it doesn't work
191     * as expected.
192     *
193     * 
http://sourceforge.net/tracker/?func=detail&aid=2800933&group_id=7118&atid=107118
194     */
195     font = Tools.updateFontSize(font, this.getView().getZoom(),
196     font.getSize());
197     }

It can instead say Tools.updateFontSize(font, this.getView().getZoom()
* 0.97F), or Tools.updateFontSize(font, this.getView().getZoom() *
ZOOM_CORRECTION_FACTOR). I am not sure what the best place for the
correction is. The magical zoom correction factor makes me slightly
uneasy; it should be explained somewhere what it is meant to achieve.
It is unclear why the zoom correction factor is applied to node views
but not to arrow link views and other views. This is not to say that I
recommend that the correction factor is also applied elsewhere; I do
not understand the purpose of the zoom correction factor.

In any case, when you remove the now-superfluous option for zooming of
the rich text editor and add the zooming correction factor to both
long node editors, zooming of the long node editors should work
correctly.

Best regards,
Dan

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer

Reply via email to