RE: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: font state and associates
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:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font state and associates
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
