Sorry we flew off the list accidentally. I like BASELINE_OFFSET_SAME_AS_HEIGHT.
This change in behavior will potentially break other layout managers which are
handling the baseline case. Specifically, we should test with MigLayout.
Otherwise this seems like a significant improvement in that we
I don't get it. When is the height ever the correct position for the
baseline? The height value can't actually be used as the baseline as that
would mean descenders are cut off.
How can the layout container compute the baseline for a node if it isn't
what is painting the text?
Scott
On Mon,
Hi Scott,
I don't know why it was decided that non-textual Nodes have baseline ==
height, but I suppose it was because HTML does the same.
E.g.
table border=1
tr
td valign=baselineabcde/td
td valign=baselinediv
style=width:100px;height:100px;border:1px solid;//td
td
Hi,
related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006
I propose to add constant public static final double
USE_COMPUTED_BASELINE_OFFSET to Node class.
This would be returned by the default Node implementation of
getBaselineOffset. Currently, the layout bounds are returned,
So how does the layout container ask for the computed baseline offset? It used
to be, by calling this method.
Richard
On Sep 3, 2013, at 6:11 AM, Martin Sladecek martin.slade...@oracle.com wrote:
Hi,
related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006
I propose to add
