Re: extended peers

[graydon hoare]

Sascha Brawer <address@hidden> writes:

> Hi Graydon,

hi. sorry I've taken 2 weeks to respond to this; I've been busy off
implementing a new font-access and glyph rendering system in cairo :)

> 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).

I think I probably blurred the cases in that statement. I meant to
point out that there are two significantly different sets of factory
methods we're going to put on the ClasspathToolkit, forced on us by
two separate technical concerns:

   - those factory methods called from Font, in a Font(...)
     constructor. they can *only* return ClasspathFontPeers, since
     they cannot influence the identity of the Font object being
     constructed. they have no option. it's not a matter of design or
     debate. this is the first case I pointed out in my earlier email,
     which you're asking about above.

   - those factory methods called from some other method or static
     function in the Font class namespace (deriveFont, createFont,
     whatever). in this case, as you've pointed out, it'd be nice to
     let the toolkit influence whether the resulting Font object
     implements OpenType or MultipleMaster, so the factory method
     should return a Font.

of these, the latter case actually has a (possible) subcase, in the
"deriveFont" method. as you've correctly noted (see below), this
subcase is not necessarily important. I thought I'd include it for
completeness.

> 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?

(re: particular toolkit overriding the meaning of deriveFont, case 3)

I can (vaguely) imagine some toolkits may want to override the meaning
of deriveFont. there is -- in some fonts -- a way of interpreting
"derive new font from old font" as a native call on an *existing*
native font object, rather than "getting a new font object", which I
think native peers might wish to use. a small point perhaps, and
you're probably right that for now it can be implemented either way
without making anyone upset. it is unlikely to disturb the interface
much if someone in the future insists it be moved from toolkit to
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.

I don't really like the notion of spreading font state out between
multiple objects, by design. my proposal is to have a Font *only*
contain a reference to its peer, and forward all state accessor
functions to the peer. the decision of which state to "design in" to
which object (font vs. peer) is going to be arbitrary, and is just as
likely to be unsatisfactory as satisfactory, for any particular native
font library.

I would prefer this be left to the implementor of a particular
peer. if they want to share state, they can. it's always possible to
split a peer in half (shared / unshared) at some "natural" boundary
that makes sense for a particular library, but I think it will be a
different boundary for each font library.  some will have
transformations in the native library, some will not.

anyways.. we seem to be mostly converging on a design, which is good;
I'd like to get code in which actually "works" in some operational
sense with both your font system and mine. do you mind if I implement
something based on what we've discussed, and modify later to suit any
remaining nits?

-graydon