xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Mote" <...@outfitr.com>
Subject RE: thoughts on fonts (was: text-decoration)
Date Thu, 09 Jan 2003 18:09:17 GMT
Jeremias Maerki wrote:

> A Wiki is probably easier to work with in this case. CVS update, edit,
> CVS commit, Website update is a lot of work. I'll start a Wiki page and
> add my thoughts to it. We can always transfer the contents back to XML
> later.

Good. I don't think I knew what a wiki was when I wrote this page. Thanks
for transferring it over.

> During the refactoring I've made FontDescriptor extend from FontMetric.
> That was a natural thing to do at that point. Thinking about this some
> more, I don't think that was a wise move.  From an SoC (Separation of
> Concerns) point of view this is bad, because I mix the concerns
> "information for layout" (ex.  Ascender depending on the font size) and
> "information for output formats" (ex. Ascender for standard font size).
> It's probably best to break off a common anscestor interface (probably
> containing on two methods: getFontName() and getFontType()).
> FontMetrics und FontDescriptor will then extend from that common
> interface. A font implementation may implement one or both interfaces.
> AWT output will probably only implement FontMetrics.

Let me say up front that I am going to follow your lead here. 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.


> > information for purposes of embedding & listing at render time. The
> > /Document/ object needs to get passed almost everywhere, but at
> least all
>
> Is that sentence finished? Anyway...

Only in my mind -- sorry. What I meant to say is that if we have a Document
object that we put this information into, yes, we have to pass it around,
but we can put other non-Font stuff into it as well.

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

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

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

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

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

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

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

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?

Victor Mote


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


Mime
View raw message