xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: thoughts on fonts (was: text-decoration)
Date Fri, 10 Jan 2003 08:32:58 GMT
Hi Victor

On 09.01.2003 19:09:17 Victor Mote wrote:
<snip/>
> Let me say up front that I am going to follow your lead here. 

I'm not taking the lead. We'll work together on this. I see that you
have some ideas yourself, so let's see what we can come up with together.
As far as I can see from your comments we will complement each other
nicely.

> However, from
> a design standpoint, the interface between Font stuff and the rest of FOP
> seems really simple -- 1) layout needs a method that it passes font
> descriptions to, and that it gets a Font object back; 3) layout needs font
> metric information; 3) the renderers need a list of fonts that need to be
> embedded. /Everything/ else can be hidden, including FontMetrics. Also, all
> of the differences between font types can be hidden behind this same facade.

Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like "Session" and "Document" on another page first.

> > I don't like FontInfo. I want that to be an interface.  Last night, I've
> > come up with a few ideas that I'm going to add to the Wiki page. There's
> > more and more Avalon that should be taken into account. I'm slowly
> > starting to understand how Avalon can be used within FOP.
> 
> Avalon is one area that I need to get up to speed on. The other is (and
> someone mentioned this several weeks ago), how Batik uses fonts, and to see
> whether we can share/use some of their work.

It would be great if you would read up on Avalon a bit.

> With regard to FontInfo being an interface, I thought the data in it simply
> became part of the Session and Document concepts.

Something along these lines, yes.

> > > I think the FontMetrics should eventually be seen only by the
> > Font object.
> > > However, it might need to be a Facade itself to deal with the
> > different ways
> > > font metric information can be returned.
> >
> > No, I think it's the other way around. FontMetrics should only be seen
> > by the layout engine. I don't even know what a Font object will be.
> > We'll have to define what a Font object is, if something like that will
> > ever exist. The Font object for me is just an implementation of a font.
> > Nothing that will be used directly, at least by the layout engine, well,
> > probably by the output handlers that need to access a myriad of values
> > for font registration.
> 
> OK, I have not made myself clear. First, see the wiki glossary, where I have
> added definitions for "font" and "typeface" to try to distinguish between
> the two. (The terms are negotiable, but I think distinguishing between these
> two concepts will help us).

well done.

> I think of the class as "Font" because it
> contains specific information about the typeface at a specific point size.
> The layout engine passes the triplet to a Font method called, say,
> provideFont. provideFont looks up the typeface in the list in Session. If
> there, it returns it. If not, it attempts to create one. It then updates the
> Document object or RenderingInstance object (probably the latter), with the
> new /typeface/, so that it can later be embedded. As metric information is
> needed by layout, it is gotten from this same Font class, which has hidden
> all of the details of getting the FontMetric information, and simply passes
> the size of the specific character back. Layout doesn't need to see anything
> about FontMetrics except the end results that it needs to lay a line out
> properly. In other words, if only two points of contact are needed, I prefer
> to limit the contact to that.

Do I get you right that you would get something like that?

public interface Font {

    String getFontName();
    int getFontWeight();
    int getFontSize();
    
    FontMetrics getFontMetricsForLayout();
}

public interface FontMetrics {

    //These methods already take font size into account
    int getAscender(); 
    int getDescender();
    int getCapHeight();
    //more...
    int getWidth(char c);
    boolean hasKerningAvailable();
    //more...
}

That looks promising.

> > No statics please. We'll use an interface for lookup. The interface will
> > be provided (IoC) to the objects that need font lookup (through Avalon's
> > ServiceManager for example).
> 
> That is fine. If they are not statics, then they need to be in a singleton,
> which is the Session concept. At the least, it seems good to have a static
> pointer to the singleton so that you don't have to pass the singleton object
> reference around everywhere you go. Maybe I am missing something here, and I
> don't know how anything about ServiceManager.

We'll see about that. I think first we have to define some interfaces
and we can handle the implementation specifics later.

The classic Singleton pattern implementation (using statics) usually
isn't used when working in an Avalon environment. You almost never use
static stuff except for constants. But there are ways to mimic the
singleton pattern.

> > You'll see that I have a two-step font lookup in mind. One step is the
> > low-level registry of fonts (all fonts that are available, a number of
> > font sources provide fonts) and the other is some kind of selector that
> > returns fonts that are usable by the set of renderers (the idea of
> > having multiple renderers in one run plays in here) used in one
> > rendering run. This second step will also do font substitution.
> 
> I added some comments to the wiki, in which I indicate my unease with trying
> to allow different fonts in different rendering contexts. I think you end up
> with, among other things, multiple area trees.

Yes, I share your unease, but I look at it from this side: Multiple area
trees mean possibly different layout which can be a problem when you're
working in an environment where you're working with legally relevant
documents. Two generated documents from the same source must be as equal
as possible. (funny use of "equal", I know)

> > We'll see how this matches up. We probably have to start with
> > synchronizing our dictionaries. I also think that it's VERY important to
> 
> I added some glossary entries to the wiki. We probably need more.

Yep.

> > properly discuss things like Session, Document, Rendering run, FOP
> > instances etc. Where to cache what? What objects/services hold/provide
> 
> In my mind Document and Rendering run (as defined in the glossary) are
> probably the same thing (??). I added something called Rendering instance to
> distinguish between different output media for the same document. Feel free
> to choose different terms -- I throw those out only to draw the distinction.

That's good. I wonder what the others think about this terminology,
because IMO this affects the whole redesign.

> I also added some comments, mostly in footnotes, to the wiki.
> 
> I guess what I am arguing for here is an /extremely/ minimal interface
> between the Font stuff and the rest of FOP, highly encapsulated. Does that
> make sense?

Of course.


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Mime
View raw message