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 Mon, 13 Jan 2003 18:18:18 GMT
Jeremias Maerki wrote:

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

OK, I just put a proposal out there in the section discussing "Facade". More
on this below.

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

I assume that we are talking about the Framework stuff here. I still haven't
found the ServiceManager that you mentioned.

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

See the wiki where I have added a couple of things to your outline above.
The main difference is that I am not thinking of it as an interface, because
I only ever want one implementation. The concrete class is itself the
interface that the remainder of the system uses. My un-OOP (but not
anti-OOP) background is probably showing through here, so please talk me out
of this if I am out of line. The reason for my approach is that ideally,
what we might want here is for java.awt.Font to be in implementation of the
interface that we wish to use. That is not an option. So what we are
building is a /virtual/ interface that we can hide java.awt.Font and /all/
other font concepts behind. We are trying to find commonality between
objects that have similar real-world characteristics, but that have no
compiler-level common heritage. There may be a better way.

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

I guess what I am saying is that different fonts used will probably /force/
different area trees. So, from out standpoint, better to disallow it than to

Sorry to be so slow in responding.

Victor Mote

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

View raw message