Re: User configuration for hyphenation
Glen Mazza wrote: I believe the same logger reference would just be used with each thread instead, es, and this is exactly the problem. It is conceivable that different loggers might be used for different processors which run in concurrent threads. A static logger reference prohibits this. J.Pietschmann
Re: User configuration for hyphenation
J.Pietschmann wrote: Glen Mazza wrote: I believe the same logger reference would just be used with each thread instead, es, and this is exactly the problem. It is conceivable that different loggers might be used for different processors which run in concurrent threads. A static logger reference prohibits this. However, the logger naming is purely conventional (at least in 1.4 logging), so if the need for different logging in different threads arose, it could be accommodated by appending a thread-based suffix to the logger name. Or was there some other problem you had in mind here? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: User configuration for hyphenation
On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote: Joerg I believe just recommended storing the user configuration in FOUserAgent, which is already getting passed around everywhere. Using my favorite design pattern, Moving Part Reduction, I also think it would be ideal if we could place all of this in FOUserAgent. (I also suspect that much of what will be in FOUserAgent/User configuration will be variable over time, which may also suggest we keep this all in one class.) BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? I like Joerg's idea of a Global Context object. It seems to have a wider scope than FOUserAgent. An FOUserAgent object could be part of it. From the maintenance code's configuration it would need to have baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font information per renderer has already been implemented; only the pdf renderer really uses it. PDF filter lists have also been implemented in the pdf renderer. Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. I would prefer input file information in the Global Context object. InputHandler has more information than needed elsewhere in the process. 2.) For the fop.image package, and future packages which have a high chance of being used for transcoder or other non-FOP purposes, I'd like us to factor out the FOUserAgent. We had a small problem a few months back when Thomas DeWeese was updating our fop.image package for the transcoder and had trouble trying to figure out how to create an FOUserAgent in order to supply a method parameter. (Turned out only a logger within FOUserAgent was being used, so I changed the method signature to just require that.) More generally, explicitly send in the needed values from FOUserAgent into the called package (eliminating the need for other callees to create an FOUserAgent instance), or, for those packages which require lots of variables in order to be properly initialized, create the collection class (i.e., like a ImageUserAgent) in that package, not in the callee's package. Then *any* callee can just import that collection class, fill it up, and send it back to the called package. Would this not be modelled by a set of interfaces? Packages or other parts of FOP could define interfaces providing the information they need. A Global Context would probably implement them all. Users addressing only part of FOP may create their own implementation of the relevant interface. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: User configuration for hyphenation
Simon Pepping wrote: I like Joerg's idea of a Global Context object. It seems to have a wider scope than FOUserAgent. An FOUserAgent object could be part of it. From the maintenance code's configuration it would need to have baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font information per renderer has already been implemented; only the pdf renderer really uses it. PDF filter lists have also been implemented in the pdf renderer. Sounds good to me. While we're on the subject of '*Dir' configuration, now may be a good time to rename the hyphenation-dir object to something that is consistent with the other directory-related items: hyphenationBaseDir We could also shorten the name to something like 'hyphBaseDir', but I don't think it's worth it. Better to have clear names (and naming conventions). On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote: snip what=FoUserAgent stuff Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. I would prefer input file information in the Global Context object. InputHandler has more information than needed elsewhere in the process. It's not clear to me how these changes would affect things, but I would hope the following remains true: If FOP is 'compartmentalized' (modularized, etc.) to enable embedded or external 'non-FOP' usage, I would hope that any of the changes to FOUserAgent being discussed, do not impact integration via external usage (be it, cocoon, forrest or some other un-dreamed-of tool). In other words, my hope is that these types of changes to FOP make it even more desirable as a product to 'build on' than it already is. Web Maestro Clay
Re: User configuration for hyphenation
J.Pietschmann wrote: Mutable static data, like a static logger reference, interferes severely with using FOP in an MT environment, because this means one thread rendering globally rather than one thread per FO processor rendering, perhaps using multiple processors, each one in a separate thread. I believe the same logger reference would just be used with each thread instead, written to by multiple threads (which is another problem, but not this one.) Further, commons loggers are instantiated with a log name, usually the class name where it appears, with the same logger used only if the log name is the same. We probably still have some unnecessary get/set logger references, such as in FOUserAgent, no longer needed due to the architecture of Commons Logging (i.e., any class doing logging can now call a LogFactory to get a logging instance.) Getting rid of them would possibly alleviate some of these issues. Also, I'm not certain of the need for logging, at least to the degree that we are doing it--many other applications at our level or below--Xerces, Xalan, Batik, compilers--don't bother with it, relying on System.out/err.println() or glorified versions thereof. Glen
Re: User configuration for hyphenation
Simon Pepping wrote: But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? The idea is to use an object which represents some global context and is reachable from nearly anywhere in the FO tree and LM tree. I'd think the user agent should qualify. Static objects are bad because of the usual MT issues (yeah, even for logging). J.Pietschmann
Re: User configuration for hyphenation
J.Pietschmann wrote: Static objects are bad because of the usual MT issues (yeah, even for logging). Should FOP itself multithread, or would it be better to let whatever would call FOP do the multithreading? I don't know what Xalan does with their translets, I suspect they just rely on the caller to implement it. Also, would implementation of FOP MT cause the caller's MT to become inefficient or otherwise messed up? I think I can see more use cases of letting FOP's caller handle the MT (e.g., servlet implementing MT to return PDF's simultaneously to hundreds of users, one PDF generation on each thread) than of FOP doing it itself, at the same time the caller has implemented it. Glen
Re: User configuration for hyphenation
Jeremias Maerki wrote: The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? On first thought, yes. But I feel the scope of the FOUserAgent is still somewhat undefined. Maybe we need to finally settle this issue. Until this is done I consider it safe to hold the user configuration in there. Joerg I believe just recommended storing the user configuration in FOUserAgent, which is already getting passed around everywhere. Using my favorite design pattern, Moving Part Reduction, I also think it would be ideal if we could place all of this in FOUserAgent. (I also suspect that much of what will be in FOUserAgent/User configuration will be variable over time, which may also suggest we keep this all in one class.) BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. 2.) For the fop.image package, and future packages which have a high chance of being used for transcoder or other non-FOP purposes, I'd like us to factor out the FOUserAgent. We had a small problem a few months back when Thomas DeWeese was updating our fop.image package for the transcoder and had trouble trying to figure out how to create an FOUserAgent in order to supply a method parameter. (Turned out only a logger within FOUserAgent was being used, so I changed the method signature to just require that.) More generally, explicitly send in the needed values from FOUserAgent into the called package (eliminating the need for other callees to create an FOUserAgent instance), or, for those packages which require lots of variables in order to be properly initialized, create the collection class (i.e., like a ImageUserAgent) in that package, not in the callee's package. Then *any* callee can just import that collection class, fill it up, and send it back to the called package. Glen
Re: User configuration for hyphenation
Glen Mazza wrote: I don't know what Xalan does with their translets, I suspect they just rely on the caller to implement it. Oops--my error--the translets just generate Java code. My comment was in general for the need of XML processors such as Xalan and FOP to implement MT internally. Glen
Re: User configuration for hyphenation
Glen Mazza wrote: Should FOP itself multithread, or would it be better to let whatever would call FOP do the multithreading? I don't understand this. Even if the main processing methods of the FO processing object are synchronizend, which is probaly what you understand by FOP isn't MT safe itself, the user can create multiple processors and use them concurrently. Mutable static data, like a static logger reference, interferes severely with using FOP in an MT environment, because this means one thread rendering globally rather than one thread per FO processor rendering, perhaps using multiple processors, each one in a separate thread. That's going to raise complaints, check the posts complaining about the global options in the maintenance branch. I'd say we may use static data only in a few cases: - Immutable data, like name mappings and fallback options - Global font and perhaps image caches - Object pools (although they are said to decrease performance for modern JREs) J.Pietschmann
Re: User configuration for hyphenation
Glen Mazza wrote: BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? Various strategy parameters, once they are implemented, like line breaking strategy; furthermore callbacks for redrawing pages in a GUI renderer, font management, base URL for images etc. J.Pietschmann
Re: User configuration for hyphenation
On 08.05.2004 23:04:40 Simon Pepping wrote: I am trying to enable user configuration of the directory of hyphenation files, like in the maintenance code. Configuration of the renderers is easy, because they are instantiated in Fop.main(). But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? If I am correct, in the maintenance code the user configuration could be accessed by a static method, anywhere in the process, just like a log file in commons logging. I suppose that is not the preferred way of accessing configuration in HEAD? Indeed. Logging is a special case where static lookup is in order. For the other cases lookup via references is preferred (IMO). This is the stack frame: [1] org.apache.fop.layout.hyphenation.Hyphenator.getHyphenationTree (Hyphenator.java:67) [2] org.apache.fop.layout.hyphenation.Hyphenator.hyphenate (Hyphenator.java:232) [3] org.apache.fop.layoutmgr.LineLayoutManager.getHyphenContext (LineLayoutManager.java:479) [4] org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss (LineLayoutManager.java:228) [5] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss (BlockLayoutManager.java:204) [6] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss (FlowLayoutManager.java:79) [7] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:229) [8] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:194) The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? On first thought, yes. But I feel the scope of the FOUserAgent is still somewhat undefined. Maybe we need to finally settle this issue. Until this is done I consider it safe to hold the user configuration in there. We can change that easily later. Jeremias Maerki
User configuration for hyphenation
Hi, I am trying to enable user configuration of the directory of hyphenation files, like in the maintenance code. Configuration of the renderers is easy, because they are instantiated in Fop.main(). But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? If I am correct, in the maintenance code the user configuration could be accessed by a static method, anywhere in the process, just like a log file in commons logging. I suppose that is not the preferred way of accessing configuration in HEAD? This is the stack frame: [1] org.apache.fop.layout.hyphenation.Hyphenator.getHyphenationTree (Hyphenator.java:67) [2] org.apache.fop.layout.hyphenation.Hyphenator.hyphenate (Hyphenator.java:232) [3] org.apache.fop.layoutmgr.LineLayoutManager.getHyphenContext (LineLayoutManager.java:479) [4] org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss (LineLayoutManager.java:228) [5] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss (BlockLayoutManager.java:204) [6] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss (FlowLayoutManager.java:79) [7] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:229) [8] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:194) The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? Your advice would be appreciated. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
