Re: User configuration for hyphenation

[Peter B. West]

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 

Re: User configuration for hyphenation

[J.Pietschmann]

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

[Glen Mazza]

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

[Clay Leeds]

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:

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

[Simon Pepping]

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

[J.Pietschmann]

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

[J.Pietschmann]

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]

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]

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]

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

[J.Pietschmann]

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

[Jeremias Maerki]

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