Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
Simon,
Why aren't these fatal errors--what's the gain in
having FOP continue running in an invalid state?
One-in-a-million bugs like these that occur for
inexplicable reasons should raise an
IllegalStateException and halt. FOP should not
continue running after catastrophic failures.
Glen
--- [EMAIL PROTECTED] wrote:
+} catch (FOPException e) {
+log.error
+(Failed to create a
StaticContentLayoutManager for flow
+ + flow.getFlowName()
+ + ; no static content will be
laid out:);
+log.error(e.getMessage());
+return;
+}
lm.initialize();
lm.setRegionReference(reg.getRegion());
..
if (pageSequence.getMainFlow() != null) {
-PageSequenceLayoutManager pageSLM =
-(PageSequenceLayoutManager)
+PageSequenceLayoutManager pageSLM;
+try {
+pageSLM =
(PageSequenceLayoutManager)
getLayoutManagerMaker().makeLayoutManager(pageSequence);
+} catch (FOPException e) {
+log.error(Failed to create a
PageSequenceLayoutManager; no pages will be laid
out:);
+log.error(e.getMessage());
+return;
+}
Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
This doesn't seem appropriate--the business logic to
determine whether or not a layout manager is needed
for a particular FO should be within that FO object,
where it reads its own private variables--in whatever
manner it is internally constucted--and makes its own
determination.
Otherwise (1) you're forcing the logic below to be
repeated in everyone else's subclasses of the Maker
method, also (2) it forces the internal state of each
FO (endIndex, startIndex) to be public, furthermore,
you're forever constraining all implementations of
FOText objects to have these method variables.
Someone could completely wish to redo FOText, and not
have a startIndex and endIndex indicators. With this
design, this is no longer possible.
Why not retain the addLayoutManager() method within
each FO, but just have it call this mapping function
to determine which LayoutManager object to create?
Why did you consider it better to strip out the
addLayoutMangers() from the FO's?
Glen
--- [EMAIL PROTECTED] wrote:
+public static class FOTextLayoutManagerMaker
extends Maker {
+public void make(FONode node, List lms) {
+FOText foText = (FOText) node;
+if (foText.endIndex - foText.startIndex
0) {
+lms.add(new
TextLayoutManager(foText));
+}
+}
+}
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
(not a real specialist in this area but...) On 26.12.2004 02:13:46 Peter B. West wrote: snip/ All of which seems redundant, given that we can get to a Graphics2d directly from a BufferedImage. I assume, though, that this is the way to introduce a foreign GraphicsEnvironment, e.g., PDFGraphicsEnvironment. Is this a fair assessment? fx type=serious-head-scratching/ IMO for BufferedImage you don't need any foreign GraphicsEnvironment. I wouldn't care what GraphicsEnvironment class is used for a BufferedImage. What puzzles me is the circularity of requiring a BufferedImage, with its implicit dependency upon getLocalGraphicsEnvironment(), which seems to be the only way to directly discover a GraphicsEnvironment. It's as though there is no formal way to introduce your own GraphicsDevices, apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf through the reliance on BufferedImage. Yes, I think there's no such thing, although I don't think it's necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all that's necessary to support Graphics2D output to PDF. And PDFGraphics2D instantiates the PDFGraphicsConfiguration as necessary. If you want to replace the default GraphicsEnvironment you'd probably set the java.awt.graphicsenv system property accordingly. But that's most probably not something you will want to do as it has consequences on the whole AWT subsystem in normal operations. What am I missing? I don't know. What are you trying to do? Is this about changing font support for the PDFGraphics2D? Knowing that I might have some better ideas. Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get a better understanding of what is involved in the whole thing. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
Glen,
In my view the FO system knows nothing about the LM system. That is
how the LM system can be pluggable. The FO system sets itself up and
waits if any subsequent system finds it useful. Its only connection
with the subsequent system is that it sends FO events to its
FOEventHandler.
The LM system, OTOH, knows about the FO system, because that is its
input. _This_ LM system chooses not to create a LM when it finds that
the FOText node is empty. Another LM system may do otherwise.
It is true that the use of endIndex and startIndex is too
detailed. Those details may be hidden behind a method hasText(),
similar to FObj.getChildren() returning null or not, which is used by
other LMMakers.
Regards, Simon
On Mon, Dec 27, 2004 at 07:36:31AM -0800, Glen Mazza wrote:
This doesn't seem appropriate--the business logic to
determine whether or not a layout manager is needed
for a particular FO should be within that FO object,
where it reads its own private variables--in whatever
manner it is internally constucted--and makes its own
determination.
Otherwise (1) you're forcing the logic below to be
repeated in everyone else's subclasses of the Maker
method, also (2) it forces the internal state of each
FO (endIndex, startIndex) to be public, furthermore,
you're forever constraining all implementations of
FOText objects to have these method variables.
Someone could completely wish to redo FOText, and not
have a startIndex and endIndex indicators. With this
design, this is no longer possible.
Why not retain the addLayoutManager() method within
each FO, but just have it call this mapping function
to determine which LayoutManager object to create?
Why did you consider it better to strip out the
addLayoutMangers() from the FO's?
Glen
--- [EMAIL PROTECTED] wrote:
+public static class FOTextLayoutManagerMaker
extends Maker {
+public void make(FONode node, List lms) {
+FOText foText = (FOText) node;
+if (foText.endIndex - foText.startIndex
0) {
+lms.add(new
TextLayoutManager(foText));
+}
+}
+}
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
Glen,
On Mon, Dec 27, 2004 at 06:55:01AM -0800, Glen Mazza wrote:
Simon,
Why aren't these fatal errors--what's the gain in
having FOP continue running in an invalid state?
One-in-a-million bugs like these that occur for
inexplicable reasons should raise an
IllegalStateException and halt. FOP should not
continue running after catastrophic failures.
Mostly, because that is not the problem I am solving at the moment. I
reimplemented the LM creation system. In so doing the fact that a
single LM is not guaranteed was exposed more clearly. I have contained
its effect by catching the exception, and have not explored the stack
of methods that may need to declare the throwing of an exception. That
is a problem in its own right, to be solved at another moment.
Regards, Simon
Glen
--- [EMAIL PROTECTED] wrote:
+} catch (FOPException e) {
+log.error
+(Failed to create a
StaticContentLayoutManager for flow
+ + flow.getFlowName()
+ + ; no static content will be
laid out:);
+log.error(e.getMessage());
+return;
+}
lm.initialize();
lm.setRegionReference(reg.getRegion());
..
if (pageSequence.getMainFlow() != null) {
-PageSequenceLayoutManager pageSLM =
-(PageSequenceLayoutManager)
+PageSequenceLayoutManager pageSLM;
+try {
+pageSLM =
(PageSequenceLayoutManager)
getLayoutManagerMaker().makeLayoutManager(pageSequence);
+} catch (FOPException e) {
+log.error(Failed to create a
PageSequenceLayoutManager; no pages will be laid
out:);
+log.error(e.getMessage());
+return;
+}
--
Simon Pepping
home page: http://www.leverkruid.nl
Horizontal Line
Hello All, Does anyone know what FO tags I need to use to generate a horizontal line given the width, color and justification for this line? Thanks, Kumar Puppala
Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
--- Simon Pepping [EMAIL PROTECTED] wrote: Glen, In my view the FO system knows nothing about the LM system. It appears that you've just made a friend in Colorado. ;) That is how the LM system can be pluggable. Not really, it can still be pluggable if you have addLayoutManager() in each FO, providing you pass in the LMMaker. (Minor point though that doesn't detract from the rest of your response here.) The FO system sets itself up and waits if any subsequent system finds it useful. Its only connection with the subsequent system is that it sends FO events to its FOEventHandler. OK. The LM system, OTOH, knows about the FO system, because that is its input. _This_ LM system chooses not to create a LM when it finds that the FOText node is empty. Another LM system may do otherwise. True. It is true that the use of endIndex and startIndex is too detailed. Those details may be hidden behind a method hasText(), similar to FObj.getChildren() returning null or not, which is used by other LMMakers. OK. In the future, we may wish to have a generic isEmpty() function in each FO, that the LM Maker can use to determine if a LM should be created. How isEmpty() would be implemented would then be up to each FO. Thanks, Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java
--- Simon Pepping [EMAIL PROTECTED] wrote: snip/ I have contained its effect by catching the exception, and have not explored the stack of methods that may need to declare the throwing of an exception. That is a problem in its own right, to be solved at another moment. OK...sorry to be rushing you. Glen
Re: Horizontal Line
Please use FOP-USER, to help in future searching of the ML archives. Developers are on both lists. Glen --- Puppala, Kumar (LNG-DAY) [EMAIL PROTECTED] wrote: Hello All, Does anyone know what FO tags I need to use to generate a horizontal line given the width, color and justification for this line? Thanks, Kumar Puppala
Re: Horizontal Line
Puppala, Kumar (LNG-DAY) wrote: Hello All, Does anyone know what FO tags I need to use to generate a horizontal line given the width, color and justification for this line? Try fo:leader with some appropriate attributes. J.Pietschmann
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias Maerki wrote: (not a real specialist in this area but...) On 26.12.2004 02:13:46 Peter B. West wrote: snip/ ... What puzzles me is the circularity of requiring a BufferedImage, with its implicit dependency upon getLocalGraphicsEnvironment(), which seems to be the only way to directly discover a GraphicsEnvironment. It's as though there is no formal way to introduce your own GraphicsDevices, apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf through the reliance on BufferedImage. Yes, I think there's no such thing, although I don't think it's necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all that's necessary to support Graphics2D output to PDF. And PDFGraphics2D instantiates the PDFGraphicsConfiguration as necessary. If you want to replace the default GraphicsEnvironment you'd probably set the java.awt.graphicsenv system property accordingly. But that's most probably not something you will want to do as it has consequences on the whole AWT subsystem in normal operations. Did you find the reference to java.awt.graphicsenv in PJA? What am I missing? I don't know. What are you trying to do? Is this about changing font support for the PDFGraphics2D? Knowing that I might have some better ideas. I'm just trying to understand what I'm doing when I fiddle with GEnv and GDev. When I first looked at using Java2D methods for all rendering, I concluded that the GraphicsEnvironment was closed, because there seemed to be no independent pathway to the creation of a modified GraphicsEnvironment. That's why I was so excited when SVGGraphics2D was mentioned on fop-dev. Looking at the implementation, though, I see that the same problems exist. I don't know quite how to express my disquiet about this, but in PJA's terms, it amounts to the implicit dependency on the underlying native graphics rendering. q java.awt.Graphics methods such as drawLine (), fillOval (), drawString (),... are implemented in the default JVM with native graphical functions (except in some cases for Java2D) : That means that drawLine () finally calls a GDI system function on Windows or X11 function on a X11/UNIX machine even if the drawing is done in an off-screen image using the class java.awt.Image. This ensures the best performance for drawing graphics with Java. /q Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get a better understanding of what is involved in the whole thing. I just took a glance at PJA. I'll have a look at the 2D implementation code. PJA seems to have gone right back to the root of GraphicsEnvironment and built its own from scratch. However, q Starting with release J2SETM 5.0, AWT has been re-implemented on the Solaris and Linux platforms. The new Toolkit implementation provides the following advantages: * Removes the dependency on Motif and Xt libraries. * Interoperates better with other GUI Toolkits. * Provides better performance and quality. /q I'll ask eTeks what the implications of this are for PJA. Peter
