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 Keiron Liddle <ke...@aftexsw.com> on 2002/07/18 14:00:05 UTC
font state and associates
Hi All,
Has anyone looked at the font state stuff.
It appears we could make some changes to improve the way fonts are
handled.
- handle font information easily
- handle font lists, resolving on a char basis
- reduce number of FontState objects if information is the same (or
similar?)
- allow for serialization as part of area tree
Do we need the FontInfo and FontMetric inside the FontState?
Can we have a list of all font states so that it can be retrieved when
needed for a particular layout of area?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Thu, 2002-07-18 at 16:05, Oleg Tkachenko wrote:
> Keiron Liddle wrote:
>
> > - handle font lists, resolving on a char basis
> Do we really need it? It'll slow down rendering. btw, neither xep nor antenna
> don't support it.
Normally it does a lookup on every char anyway.
I would have to check but most of the time it should be the same lookup
as it does now. It is only of a list is specified and it doesn't find
the char the first go.
> > - reduce number of FontState objects if information is the same (or
> > similar?)
> That's good idea, now we create new FontState for each text node. What about
> FontState pool?
>
> > - allow for serialization as part of area tree
> >
> > Do we need the FontInfo and FontMetric inside the FontState?
> Not sure about FontMetric but FontInfo object is actually 1 for the whole
> rendering process and each FontState doesn't have to remember it.
The font metric has a number of sets that remain constant for the
process.
> --
> Oleg Tkachenko
> Multiconn International, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by Oleg Tkachenko <ol...@multiconn.com>.
Keiron Liddle wrote:
> - handle font lists, resolving on a char basis
Do we really need it? It'll slow down rendering. btw, neither xep nor antenna
don't support it.
> - reduce number of FontState objects if information is the same (or
> similar?)
That's good idea, now we create new FontState for each text node. What about
FontState pool?
> - allow for serialization as part of area tree
>
> Do we need the FontInfo and FontMetric inside the FontState?
Not sure about FontMetric but FontInfo object is actually 1 for the whole
rendering process and each FontState doesn't have to remember it.
--
Oleg Tkachenko
Multiconn International, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Thu, 2002-07-18 at 14:30, Jeremias Maerki wrote:
> Hi Keiron
>
> Not enough to be of any help right now. But reading this the Flyweight
> pattern from the Design Patterns book comes to my mind immediately. The
> list of all font states is the consequence of this pattern which could
> be very helpful for the renderers.
That sounds like a possible solution.
Mainly we should avoid the current situation, I think it creates a new
FontState object for every fo element even if it is the same.
> The PS renderer still writes a list
> of all registered (instead of used) fonts at the beginning so they are available
> when necessary. You can't just register objects into the stream when
> encountered like in PDF. Of course, the list grows over time during
> layout while the renderer should already start writing out pages. But
> that's another problem...
That is another area that will need some design application, the choice
is probably where to put the burden of storing the pages - the area tree
or the renderer.
> Sorry, if this a bit meager but on the other side.... In two weeks I'll
> be starting my well-earned 7 weeks long holidays after really intensive
> 10 months. I'll be away during two weeks in August but I'll have 5 weeks
> from which I'd like to spend at least a full week to help with the
> redesign without having customers in my neck (read: I want to have some
> fun). Let me know if there's a particular area I could help out. I was
> thinking about the following areas: Avalon, Configuration, API,
> renderers. But I'd be glad to help in other areas if I can.
Sounds like you need a good holiday then :-)
That sounds like a good order but whatever seems appropriate when you
get into it...
> While I'm at it, I'd like to apologize for my lack of participation
> during the last weeks (especially with the API stuff). Too many things
> buzzing around my head...
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Keiron
Not enough to be of any help right now. But reading this the Flyweight
pattern from the Design Patterns book comes to my mind immediately. The
list of all font states is the consequence of this pattern which could
be very helpful for the renderers. The PS renderer still writes a list
of all registered (instead of used) fonts at the beginning so they are available
when necessary. You can't just register objects into the stream when
encountered like in PDF. Of course, the list grows over time during
layout while the renderer should already start writing out pages. But
that's another problem...
Sorry, if this a bit meager but on the other side.... In two weeks I'll
be starting my well-earned 7 weeks long holidays after really intensive
10 months. I'll be away during two weeks in August but I'll have 5 weeks
from which I'd like to spend at least a full week to help with the
redesign without having customers in my neck (read: I want to have some
fun). Let me know if there's a particular area I could help out. I was
thinking about the following areas: Avalon, Configuration, API,
renderers. But I'd be glad to help in other areas if I can.
While I'm at it, I'd like to apologize for my lack of participation
during the last weeks (especially with the API stuff). Too many things
buzzing around my head...
> Has anyone looked at the font state stuff.
> It appears we could make some changes to improve the way fonts are
> handled.
>
> - handle font information easily
> - handle font lists, resolving on a char basis
> - reduce number of FontState objects if information is the same (or
> similar?)
> - allow for serialization as part of area tree
>
> Do we need the FontInfo and FontMetric inside the FontState?
> Can we have a list of all font states so that it can be retrieved when
> needed for a particular layout of area?
Cheers,
Jeremias Märki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> Can we have a list of all font states so that it can be retrieved when
> needed for a particular layout of area?
This is exactly what I'm currently thinking about. This
allies to all property bundles. There are only so much
different font states really used in a specific document,
usually one or two for the normal text (normal and perhaps
italic), a few more for headlines, and for software docs
also one or two with Courier.
Nevertheless FOP creates half a new FontState object every
time one is needed.
I imagine the following:
- Classsify all properties in various bundles. There is
already a bunch of them: FontState, TextState (should
be TextDecoration) and some unused classes.
- In the constructor, get the property bundle object from
the parent (if inheritable), or get the scratch object
for this bundle, or create a new one.
- Go through the XML attribute list, and get a property value.
- Check whether the value is alredy in the bundle object. If
not, and if it was inherited, clone the object. In either
case, store the property value afterwards.
- If all properties from the XML attribute list relevant to
the bundle are examined, go through the global table of
already allocated objects of this property bundle. If an object
with the same values is found, refer to this. If necessary,
put back the scratch object for reuse.
Of course, this requires that property bundle objects are
immutable once filled from the XML attributes (and local
property refinement). There is one instance where a
BorderAndPadding is abused in Table.java, but I think this
could easily be solved otherwise.
I think this way memory usage could be significantly reduced.
I'm going to implement this in the maintenance branch after
I finissh the cleanup I'm currently doing.
What do you think?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: font state and associates
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Victor
> I am new to this list, to FOP, and to open-source development. I have been
> trying to get up to speed so that I can help on a couple of my personal
> "itches". I was going to hold off on offering help / asking questions until
> I was farther along in that process, but your question addresses one of
> those itches. I noticed in the documentation (and by experience) that only
> the base-14 fonts are supported without building metric file information
> externally. Also, my perception is that OpenType fonts are not supported. I
> would like to look at the feasibility of making arbitrary system fonts
> available, not only for FOP, but for embedding (where necessary) in the
> output. I don't see this on the list of enhancements. Perhaps your question
> was oriented toward getting such a project on the list, or addressing some
> design issues that affect this.
>
> My questions (for now) are: 1) This project seems feasible, but am I missing
> something?
This is perfectly feasible. Making fonts available directly without
generating XML files is an important feature for FOP to be easier to
handle and to embed into an application. Supporting OpenType might be a
challenge (I don't know, haven't read the specs, yet) but it's cool if
you want to step in for that. Helpful additions to FOP are always
welcome.
> 2) Has anyone already started this? Perhaps you are thinking of
> starting into it? If so, I'll be happy to assist (if that is possible), or
> to work on something else -- there are plenty of other FOP projects that
> interest me.
Making fonts available without XML metric files is something that is on
my private task list so I would gladly help you with this one.
I think the TrueType support already contains some of the stuff
necessary to support OpenType fonts. But I'm pretty sure it needs some
more work and nobody is currently working on OpenType support at the
moment. This isn't a feature that has been asked for, I think.
> In short, I wanted to register an interest in this thread and offer to help.
> I apologize that I am not yet conversant in the details.
We can use all the help we can get. I suggest that we start a new thread
for the discussion on supporting multiple font sources. I've got a
couple of ideas on how we can improve font support in FOP. But I'd like
to ask your for patience until my holidays start (27.8.2002) since I've
got tons of work until then. In the meantime read into the OpenType
specs and familiarize yourself with the TrueType support classes in FOP
to get a feeling what needs to be done.
Cheers,
Jeremias Märki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: font state and associates
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-10-23 at 21:41, Victor Mote wrote:
> Keiron Liddle wrote (a long time ago, July 18 to be exact):
>
> > Has anyone looked at the font state stuff.
> > It appears we could make some changes to improve the way fonts are
> > handled.
> >
> > - handle font information easily
> > - handle font lists, resolving on a char basis
> > - reduce number of FontState objects if information is the same (or
> > similar?)
> > - allow for serialization as part of area tree
> >
> > Do we need the FontInfo and FontMetric inside the FontState?
> > Can we have a list of all font states so that it can be retrieved when
> > needed for a particular layout of area?
>
> My refactoring work will eventually handle most of this. However, I do not
> understand item 2: "handle font lists, resolving on a char basis". There are
> some lists in the FontInfo class now, which will end up as static fields in
> the new Typeface class (with Typeface instances behind them), and I will
> clean them up in the stage 2 work. The part I don't understand is the
> "resolving on a char basis". What does this mean? Thanks.
Those fonts in the font info class are the fonts available to the system
from default + embedded fonts.
I was refering to a list of fonts in the font-family attribute in the fo
document.
If I remember correctly it should keep the list of family names and
lookup the character depending on the font-selection-strategy. If it is
charactar-by-character then it will need to know if the font has that
character in its range otherwise to try the next font family in the
list. It needs to do this twice, for getting the char width and for
resolving the mapping.
This is only a rare case but it should be considered in the design.
The serialization part in trunk is handled by using the string internal
font name as a key.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: font state and associates
Posted by Victor Mote <vi...@outfitr.com>.
Keiron Liddle wrote (a long time ago, July 18 to be exact):
> Has anyone looked at the font state stuff.
> It appears we could make some changes to improve the way fonts are
> handled.
>
> - handle font information easily
> - handle font lists, resolving on a char basis
> - reduce number of FontState objects if information is the same (or
> similar?)
> - allow for serialization as part of area tree
>
> Do we need the FontInfo and FontMetric inside the FontState?
> Can we have a list of all font states so that it can be retrieved when
> needed for a particular layout of area?
My refactoring work will eventually handle most of this. However, I do not
understand item 2: "handle font lists, resolving on a char basis". There are
some lists in the FontInfo class now, which will end up as static fields in
the new Typeface class (with Typeface instances behind them), and I will
clean them up in the stage 2 work. The part I don't understand is the
"resolving on a char basis". What does this mean? Thanks.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: How can I put differents footers on odd & even pages?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jean-François Selber wrote:
> How can I put differents footers on odd & even pages?
> All pages must be in the same sequence.
This is a FAQ. Look for example at
docs/examples/pagination/franklin_2pageseqs.fo
or the XSL FAQ reachable through
http://www.mulberrytech.com/xsl/xsl-list/
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
How can I put differents footers on odd & even pages?
Posted by Jean-François Selber <jf...@oxymel.com>.
How can I put differents footers on odd & even pages?
All pages must be in the same sequence.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: font state and associates
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Victor,
I think that Jeremias covered most of your questions.
This is a related issue to handling the font state.
For embedded fonts it needs to create a font metrics and (at least in
the case of pdf) enable the font to be embedded.
So find out what font metrics are needed by FOP then the code will need
to supply these. Mostly it needs to get the various heights and the
character widths (look in org.apache.fop.layout.FontMetric).
I think the AWTRenderer does this for java fonts already.
On Thu, 2002-07-18 at 17:06, Victor Mote wrote:
> Keiron:
>
> I am new to this list, to FOP, and to open-source development. I have been
> trying to get up to speed so that I can help on a couple of my personal
> "itches". I was going to hold off on offering help / asking questions until
> I was farther along in that process, but your question addresses one of
> those itches. I noticed in the documentation (and by experience) that only
> the base-14 fonts are supported without building metric file information
> externally. Also, my perception is that OpenType fonts are not supported. I
> would like to look at the feasibility of making arbitrary system fonts
> available, not only for FOP, but for embedding (where necessary) in the
> output. I don't see this on the list of enhancements. Perhaps your question
> was oriented toward getting such a project on the list, or addressing some
> design issues that affect this.
>
> My questions (for now) are: 1) This project seems feasible, but am I missing
> something? 2) Has anyone already started this? Perhaps you are thinking of
> starting into it? If so, I'll be happy to assist (if that is possible), or
> to work on something else -- there are plenty of other FOP projects that
> interest me.
>
> In short, I wanted to register an interest in this thread and offer to help.
> I apologize that I am not yet conversant in the details.
>
> Victor Mote (mailto:vic@outfitr.com)
> Enterprise Outfitters (www.outfitr.com)
> 2025 Eddington Way
> Colorado Springs, Colorado 80916
> Voice 719-622-0650, Fax 720-293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: font state and associates
Posted by Victor Mote <vi...@outfitr.com>.
Keiron:
I am new to this list, to FOP, and to open-source development. I have been
trying to get up to speed so that I can help on a couple of my personal
"itches". I was going to hold off on offering help / asking questions until
I was farther along in that process, but your question addresses one of
those itches. I noticed in the documentation (and by experience) that only
the base-14 fonts are supported without building metric file information
externally. Also, my perception is that OpenType fonts are not supported. I
would like to look at the feasibility of making arbitrary system fonts
available, not only for FOP, but for embedding (where necessary) in the
output. I don't see this on the list of enhancements. Perhaps your question
was oriented toward getting such a project on the list, or addressing some
design issues that affect this.
My questions (for now) are: 1) This project seems feasible, but am I missing
something? 2) Has anyone already started this? Perhaps you are thinking of
starting into it? If so, I'll be happy to assist (if that is possible), or
to work on something else -- there are plenty of other FOP projects that
interest me.
In short, I wanted to register an interest in this thread and offer to help.
I apologize that I am not yet conversant in the details.
Victor Mote (mailto:vic@outfitr.com)
Enterprise Outfitters (www.outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice 719-622-0650, Fax 720-293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org