RE: thoughts on fonts (was: text-decoration)
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
disappoint.
Sorry to be so slow in responding.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 13.01.2003 19:18:18 Victor Mote wrote:
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.
Mh, yes, I'm not so happy about it, yet. I'll add my comments as
soon as my current task is done.
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.
Yes, we're talking about Framework. Framework defines the contracts in
an Avalon system which includes ServiceManager. ServiceManager is the
successor to the ComponentManager which was deprecated because every
service/component had to implement a Component marker interface with no
methods. The ServiceManager now returns simple Objects that need to be
casted to their work interface.
Here's the link to the API docs of the Service package.
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/service/package-summary.html
See here for the Developing with Avalon guide:
http://jakarta.apache.org/avalon/developing/framework.html
(this is a MUST read)
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.
I guess I will. :-)
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.
There, you are on the right track IMO.
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
disappoint.
I guess Peter is right that we have to keep it simple for now. Let's
stay on the safe side and be ready to adapt to future changes.
Sorry to be so slow in responding.
No problem. There's so much to do that I'm not getting stuck.
Sorry for not immediately answering in more detail. I've got to get my
head clear for that first.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 11.01.2003 18:35:37 Victor Mote wrote:
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
The performance gain is not having to do the layout for each output
document which is the major part of a processing run.
The system I wrote for my former employer which is a solution for
high-volume digital printing had to provide a minimal number of pages
per minute. That's usually about 1 to 2 times the speed of the target
printer. So if you have a Xerox DocuTech with 180 pages per minute
and you have to fill an archive with a different format than the one
sent to the printer you'll be happy for such a feature. Especially, if
legal requirements dictate that you need to be able to reprint the
document from the archive and get the same document almost to the pixel.
I'd say we need to be able to do this sometime in the future but not
necessarily now. So let's just make sure this requirement doesn't get
lost and that it stays in the back of our minds when we design the new
thing.
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
That's bad, yes.
Or you could only allow one RenderingContext which results in a
restriction of the available fonts based on the output handlers. You'd
get an error message as soon as an unsupported font is used. When a
common set isn't possible you have to do two rendering runs anyway so we
might just as well delegate this to the caller/user.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
Won't be necessary with my alternative apporach above. But if the user
has to run the layout twice it might be good if the FO tree wasn't lost
between runs.
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
I think my approach could work in this regard. I'm not sure. We can let
the FO tree live for another layout run, can't we?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: Jeremias Maerki wrote: It is very possible that I am missing something, but our memory-lean event-based model would seem to dictate either 1) parsing the document twice, or 2) not allowing multiple output formats in the same document. I think my approach could work in this regard. I'm not sure. We can let the FO tree live for another layout run, can't we? I have no objection to it. However, AFAIK our processor doesn't really process an FO tree, it processes events that occur as the FO tree is built. So, you need to add something that walks through the existing FO tree starts creating events to feed into our processor. I don't know how much faster this might be than just reprocessing the original input. Then you need something in the process that says Oh, don't try to build an FO tree here, it already exists. In other words, we're kind of trying to reuse something that we didn't use the first time -- it all seems kind of klunky. It seems to me that if we want to go down that path, we would do well to build an FO tree up front, caching it for those who need a lean memory environment, then process that tree n times, all the same way. I am not really arguing for that, but merely pointing out that it seems like that is where reusing the FO tree leads us. There's one in alt.design if you ever need it. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: thoughts on fonts (was: text-decoration)
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: There are some big picture things that we should probably address: 1. (Biggest of all) Do we have users that need to be able to do this? Are the performance gains that they might get worth the pain on our end? Apart from this is the fact that our processing model for any rendering is still very much in a state of flux. It may be less painful to retro-fit when we have a comprehensive working renderer, keeping this possibility in mind as we go. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
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.
Re: thoughts on fonts (was: text-decoration)
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. If I understand it correctly we could have: - multiple output targets for one rendering run - targets with the same font metrics can layout to a common area tree - targets with similar or substitute metrics could force layout to one area tree - other targets can have different area trees from the same fo tree Would a rendering context make sense, which is created for each rendering instance and used to determine what to do for layout, rendering. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Hi Keiron If I understand it correctly we could have: - multiple output targets for one rendering run - targets with the same font metrics can layout to a common area tree - targets with similar or substitute metrics could force layout to one area tree - other targets can have different area trees from the same fo tree Yep, though as Victor said, it remains to be seen if we will implement every feature from the beginning. It could be a lot of work. But I'd like to write down every idea so we have a reference for future work. Would a rendering context make sense, which is created for each rendering instance and used to determine what to do for layout, rendering. Yes, we need something like that. That's what's next on my todo list right after finishing the first version of the tutorial. But if one of you wants to start already please add a new Wiki page and add your thoughts. In short, that page should describe the following: - We've got various information holders/sources. We need to list them and place them in the architecture. Some information is hold over multiple rendering instances, some is only hold for one. - Putting FOUserAgent in the right context. It's something rather static though we will want the ability to have multiple instances per VM. This is configurable by config file and by subclassing. - the rendering context you just mentioned. Is this the right name for this? What information will it hold? etc. - We've got various caches. Where will we place each one? - How Avalon and the future API(s) will play into this. - add your ideas... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
I've added my current thoughts to a Wiki page for those interested in this discussion: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign You're all welcome to participate. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: thoughts on fonts (was: text-decoration)
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
