Hi Graydon,
GH = graydon hoare <[EMAIL PROTECTED]> wrote:
SB = Sascha Brawer <[EMAIL PROTECTED]> wrote:
GH> [should Classpath have extended peers for java.awt.Font?]
SB> [proposal for ClasspathToolkit/ClasspathFontPeer]
GH> the font-related factory method on the toolkit should produce a
GH> ClasspathFontPeer, not a java.awt.Font.
SB> If the toolkit produces ClasspathFontPeers instead of java.awt.Fonts, the
SB> implementations of java.awt.Font.createFont and deriveFont somehow need
SB> to know whether the constructed Font should implement the
SB> java.awt.font.[OpenType, MultipleMaster] interfaces.
GH> (1) Font constructors [...]
GH> (2) [static] Font.createFont, Font.decode, Font.getFont [...]
GH> (3) Font.deriveFont [...]
GH>
GH> my inclination is to call peer-returning factory methods on the
GH> Toolkit in case (1), call Font-returning factory methods on the
GH> Toolkit in case (2), and to call a method *on the peer* in case (3).
Case (1): Agreed.
Case (2): So, you're retracting the statement that font-related factory
methods should produce a ClasspathFontPeer instead of a java.awt.Font? I
think either way is fine. Presumably, producing Font might lead to a
cleaner code structure, while producing ClasspathFontPeer to less
duplication of code between toolkits. At the current stage, I'd prefer
simplicity (i.e., producing Fonts).
Case (3): I wonder whether this wouldn't make the peer interface
unnecessarily complicated. Since the static getFont(Map) method needs to
be supported anyway, I believe the following implementation for
deriveFont should do it. Or am I missing a reason why any toolkit would
want to override this?
package java.awt;
public class Font
{
public static Font getFont(Map attrs)
{
// this assumes that ClasspathToolkit returns Font, see (2) above
return ((ClasspathToolkit) Toolkit.getDefaultToolkit())
.getFont(attrs);
}
public Font deriveFont(float size)
{
Map attrs = getAttributes(); // returns a clone
attrs.put(TextAttribute.SIZE, new Float(size));
return getFont(attrs);
}
// more deriveFont methods, all done in a similar way
}
SB> I thought it would not hurt to allow that a single font peer is shared
SB> between scaled/transformed fonts. On the other hand, if you think that
SB> passing the Font to the peer's methods is bad, I wouldn't have a problem
SB> to omit that argument.
GH> the benefit of this approach is that it places all the decisions about
GH> a font's behavior purely in the realm of the specific Toolkit and Peer
GH> subclasses, along with any choices you make about state representation.
GH> the Font has no policy of its own; you store all state in the peer,
GH> where all policy is. imo it improves flexibility quite a bit.
>>> [some code snippets]
GH> well, how are you going to implement peer.getItalicAngle(), if the
GH> italic angle state is stored in the Font rather than the peer?
Ah, I didn't mean to suggest storing anything besides point size,
transform, attribute map and peer in the font. For example, the italic
angle for the unscaled/untransformed font would be retrieved via some
platform-specific font ID. That ID would be stored inside the peer, not
inside the font.
// On the Foo platform, one FooFontPeer is shared among all
// scaled/transformed variants of the same font. Other
// platforms are free to do it in a different way.
class FooFontPeer
extends ClasspathFontPeer
{
protected long platID;
private static native getUntransformedItalicAngle(long platID);
public float getItalicAngle(Font font)
{
float angle = getUntransformedItalicAngle(platID);
if (font.isTransformed())
{
// Retrieve a clone of the font's transform.
AffineTransform tx = font.getTransform();
angle = someFunction(tx, angle);
}
return angle;
}
}
As I said before, I wouldn't consider this to be very important. I think
it could be a nice optimization that might possibly be applicable in some
cases. Everywhere else, the "font" argument would be ignored. But if you
don't see the point, let's leave it away.
Best regards,
-- Sascha
Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
