You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Oleg Tkachenko <ol...@multiconn.com> on 2003/01/08 13:11:34 UTC
text-decoration
Hello!
How are we going to process underline/overline etc stuff?
It's a little bit confusing - we've got unused TextState class along with
TextInfo that includes text-decoration info already. Lets get rid of TextState ?
And what about rendering, does pdf support text-decoration directly or we have
to draw lines as in the branch?
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: text-decoration
Posted by Oleg Tkachenko <ol...@multiconn.com>.
Jeremias Maerki wrote:
> Wait a minute! I'm just about to commit a huge bunch of changes which
> includes TextInfo/FontState stuff. Not that I changed a lot. I've just
> got rid of stuff that wasn't used and I don't want you to have to change
> a lot again after my commit.
That's fine.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: text-decoration
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Oleg
Wait a minute! I'm just about to commit a huge bunch of changes which
includes TextInfo/FontState stuff. Not that I changed a lot. I've just
got rid of stuff that wasn't used and I don't want you to have to change
a lot again after my commit.
On your question, I can't answer right away, but it is one one the
things that got my attention when going over these classes. I'll dig
deeper into this as soon as the CVS commits are done. More to come...
On 08.01.2003 13:11:34 Oleg Tkachenko wrote:
> How are we going to process underline/overline etc stuff?
> It's a little bit confusing - we've got unused TextState class along with
> TextInfo that includes text-decoration info already. Lets get rid of TextState ?
> And what about rendering, does pdf support text-decoration directly or we have
> to draw lines as in the branch?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: thoughts on fonts (was: text-decoration)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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.
Mmmmmh, 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: thoughts on fonts (was: text-decoration)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: thoughts on fonts (was: text-decoration)
Posted by Victor Mote <vi...@outfitr.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: thoughts on fonts (was: text-decoration)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
Re: thoughts on fonts (was: text-decoration)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: thoughts on fonts (was: text-decoration)
Posted by Victor Mote <vi...@outfitr.com>.
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
Re: thoughts on fonts (was: text-decoration)
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Victor
Good that you spoke up, so we can discuss this.
On 08.01.2003 19:31:35 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > TextInfo looks better but could IMO be merged with FontState which only
> > hold the font name and size and a link to the FontMetrics. Anyway, I
> > think this merged class will be a candidate for the Flyweight pattern so
> > we don't generate so many TextInfo/FontState objects (one for each FObj
> > I think). Brings up the question of efficiently looking up existing
> > Flyweights, on the other side.
>
> I also saw elements of the Facade pattern here on the font stuff. I
> documented some of these thoughts at
> http://xml.apache.org/fop/dev/fonts.html.
Have seen that now for the first time. I shall check the design docs
more frequently in the future. :-)
> I suppose a wiki would have been
> better & that is pretty much how I viewed this page -- the point is to feel
> free to hack away at that document if you wish.
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.
> It looks like you have
> started some of the moving and consolidating work that needed to be done
> with the scattered classes.
Yep, it also helped me understand a lot more about its "design". It has
grown too much over time.
> I thought that most of the surviving
> font-related classes should be private & used only by a Font class that was
> a Facade for all of the underlying types of fonts, including (eventually)
> AWT fonts seen by any existing graphical environment.
I see it this way:
As you already figured out there are several aspects to the font
subsystem:
- Provide information (font metrics -> FontMetrics) for the layout
process
- Provide information (more detailed font metrics, pointers to font
files -> FontDescriptor) for the various output format handlers. I
don't say "renderers" here because the PDF library is actually the
recipient of the font information.
- Management of various font sources (file-based, AWT...)
- Management of the fonts actually used during a rendering run.
- Parsing of font files
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.
> I was all set to put
> the FontInfo into static variables so that it didn't have to be passed
> around so much. I see that multiple threads make that a bad idea. What we
> need (and probably already have -- I haven't had time to look) is the
> equivalent of a Document class that the FontInfo lists can be put into.
> Thus, our Font, Typeface, and TypefaceFamily classes apply to an FOP
> Session, but the /Document/ object keeps a list of at least Typeface
> 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...
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.
> 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.
> To get the Flyweight working, when a Font resource is requested during
> layout, we have to look in the tables of pre-existing objects (this should
> be static), and either return an existing one or create a new one, then also
> update the /Document/ info.
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).
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.
> Something like FontState or TextState (one or the other) is probably good to
> keep pointers to all of this stuff (including Font) in one place. However,
> since the other items are basically (I think) boolean in nature (underline
> on or off), maybe it is just as good to simply pass the area object around
> which should have all of this stuff. One of the "bad smells" was the amount
> of information that had to be passed to get anything done.
yes, and the amount of little objects that are similar or equal that are
generated. That's the reason for the Flyweight pattern.
> I don't know how this matches up with where you are going, but I thought I
> ought to throw it out there FWIW. You are probably way ahead of me on all of
> this. Also, I thought that a discussion of how "Session" stuff is separated
> from "Document" stuff for multithreading might be worthwhile.
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
properly discuss things like Session, Document, Rendering run, FOP
instances etc. Where to cache what? What objects/services hold/provide
which objects/services etc. Uh, I'm just going to create yet another
Wiki page for that and see what good comes from there. I think this is
very important to understand how Avalon fits into this.
> It will probably be a couple of weeks before I can get back into this much.
> Sorry to be on the sidelines for a bit.
I hope that I will have finished some preparational work (especially
Avalon) until then, so we can move forward.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: text-decoration
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> TextInfo looks better but could IMO be merged with FontState which only
> hold the font name and size and a link to the FontMetrics. Anyway, I
> think this merged class will be a candidate for the Flyweight pattern so
> we don't generate so many TextInfo/FontState objects (one for each FObj
> I think). Brings up the question of efficiently looking up existing
> Flyweights, on the other side.
I also saw elements of the Facade pattern here on the font stuff. I
documented some of these thoughts at
http://xml.apache.org/fop/dev/fonts.html. I suppose a wiki would have been
better & that is pretty much how I viewed this page -- the point is to feel
free to hack away at that document if you wish. It looks like you have
started some of the moving and consolidating work that needed to be done
with the scattered classes. I thought that most of the surviving
font-related classes should be private & used only by a Font class that was
a Facade for all of the underlying types of fonts, including (eventually)
AWT fonts seen by any existing graphical environment. I was all set to put
the FontInfo into static variables so that it didn't have to be passed
around so much. I see that multiple threads make that a bad idea. What we
need (and probably already have -- I haven't had time to look) is the
equivalent of a Document class that the FontInfo lists can be put into.
Thus, our Font, Typeface, and TypefaceFamily classes apply to an FOP
Session, but the /Document/ object keeps a list of at least Typeface
information for purposes of embedding & listing at render time. The
/Document/ object needs to get passed almost everywhere, but at least all
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.
To get the Flyweight working, when a Font resource is requested during
layout, we have to look in the tables of pre-existing objects (this should
be static), and either return an existing one or create a new one, then also
update the /Document/ info.
Something like FontState or TextState (one or the other) is probably good to
keep pointers to all of this stuff (including Font) in one place. However,
since the other items are basically (I think) boolean in nature (underline
on or off), maybe it is just as good to simply pass the area object around
which should have all of this stuff. One of the "bad smells" was the amount
of information that had to be passed to get anything done.
I don't know how this matches up with where you are going, but I thought I
ought to throw it out there FWIW. You are probably way ahead of me on all of
this. Also, I thought that a discussion of how "Session" stuff is separated
from "Document" stuff for multithreading might be worthwhile.
It will probably be a couple of weeks before I can get back into this much.
Sorry to be on the sidelines for a bit.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: text-decoration
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Oleg
On 08.01.2003 13:11:34 Oleg Tkachenko wrote:
> How are we going to process underline/overline etc stuff?
> It's a little bit confusing - we've got unused TextState class along with
> TextInfo that includes text-decoration info already. Lets get rid of TextState ?
> And what about rendering, does pdf support text-decoration directly or we have
> to draw lines as in the branch?
TextState seems to be dead. References in PageNumber, PageNumberCitation
and FOText but without any function. So remove it.
TextInfo looks better but could IMO be merged with FontState which only
hold the font name and size and a link to the FontMetrics. Anyway, I
think this merged class will be a candidate for the Flyweight pattern so
we don't generate so many TextInfo/FontState objects (one for each FObj
I think). Brings up the question of efficiently looking up existing
Flyweights, on the other side.
As far as underline/overline stuff is concerned, I like the idea of
having PrintRenderer calculate these and calling subclasses to draw the
lines (like in the branch). That makes the behaviour uniform over most
renderers (those derived from PrintRenderer).
Would it help if I started again with the PostScript renderer so code
factored out into PrintRenderer can be verified?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org