Re: FOs and Areas
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] J.Pietschmann wrote: I've got a lot of ideas myself, perhaps too many. What the project needs is *working* *code*. Working code is predicated on working ideas, is it not? That's why I asked about ideas. Not necessarily (--that, I believe, is Victor's whole point). You can have perfectly working software, which turns out to be poorly designed, and the biggest problem there is that the flaws in the design will almost always turn up at a moment when it's least convenient to change it (we'll leave the name-dropping to _your_ imagination ;) ) My meaning was that software doesn't write itself - all software is thought into existence (even software from code generators.) I agree with your final point, with the substitution of imperfectly-working for perfectly-working. (Note - this was a conversation with Joerg.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
DO NOT REPLY [Bug 25582] - [PATCH] Remove unused imports.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582 [PATCH] Remove unused imports. --- Additional Comments From [EMAIL PROTECTED] 2003-12-20 12:38 --- I think that a commit is missing for the last 5 files in the patch: src/java/org/apache/fop/render/ps/PSTextPainter.java src/java/org/apache/fop/render/ps/PSXMLHandler.java src/java/org/apache/fop/svg/AbstractFOPTranscoder.java src/java/org/apache/fop/svg/PDFImageElementBridge.java src/java/org/apache/fop/util/CharUtilities.java Or maybe the patch file wasn't applied completely for these files. regards, finn
DO NOT REPLY [Bug 25673] New: - [PATCH] access to fobj.elementTable cause eclipse warning.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25673. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25673 [PATCH] access to fobj.elementTable cause eclipse warning. Summary: [PATCH] access to fobj.elementTable cause eclipse warning. Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I don't know to what extend we want to fix eclipse warnings, but by default eclipse complains about access to static fields through an instance variable. This patch fixes this and removes an unneeded import statement.
RE: Setup code in Driver
Jeremias Maerki wrote (Sent: Saturday, November 08, 2003 8:28 AM)
As you may have seen in the CVS messages I have moved most of the setup
code that was in the render() method to the getContentHandler() method.
This is necessary because not everyone uses the render() methods,
sometimes you simply need to have a ContentHandler to send SAX events to.
Some of our examples (and some of our basic test cases) use that
approach.
What is left to do is to enable the FOTreeListener for Document that is
currently added only if the render() method is called. Providing the
same functionality with getContentHandler() only means you're not in the
Driver class anymore when endDocument() is called on the ContentHandler
which makes it difficult to remove the FOTreeListener on the
FOTreeHandler when processing is complete.
If noone objects, if noone has a better idea and if noone fixes that
ahead of me, I'm going to write a ProxyingDefaultHandler as a utility
class that does nothing other than pass through all method calls to
another DefaultHandler (in other words: the FOTreeBuilder). I'll then
add an anonymous inner class derived from that ProxyingDefaultHandler in
getContentHandler that listens to the endDocument() event and calls
removeFOTreeListener on FOTreeHandler. Instead of the FOTreeBuilder that
anonymous inner class will be returned by getContentHandler().
First, my apologies for being so slow to respond. I am trying to clean up
some of this old stuff that I had flagged for followup. I also looked in the
CVS history source, and it looks like you have not finished this yet.
The answer to your question probably lies in understanding how and why
getContentHandler() is used without also using render(). The FOTreeListener
is only needed if the input document is parsed, and in fact is only needed
if you want to break out of parsing to go do something at a higher level
before returning (the normal SAX events are not affected at all). So:
1) if the process running getContentHandler() doesn't ever parse, don't
bother registering the FOTreeListener
2) if the process running getContentHandler() doesn't care about being
notified about the end of a PageSequence (which is the only FOTreeListener
event that is *unique*), don't bother registering the FOTreeListener
3) otherwise, have it wrap its parsing code inside of the following (which
is what is wrapped around parser.parse in render() now):
before
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.addFOTreeListener(currentDocument);
}
/before
after
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.removeFOTreeListener(currentDocument);
}
/after
Better yet, refactor both of the above code snippets into methods that can
be called more simply, since this code would now be used more than once.
Just looking at what is left in render(), I don't quite follow why it would
ever *not* be used if parsing will take place. The only thing left in there
is parser.parse(), the above code that it is wrapped in, and the code to
*not* parse based on the LayoutStrategy's wishes. Since the parser itself
can be passed as a parameter, it seems like anybody parsing could/would use
it. If you will describe the use case(s) a bit, I'll try to be of more help.
Part of what is making this a bit ugly is that render() really belongs in
the Document class, but I don't think that can be done until FOP's API
issues are resolved.
Victor Mote
RE: Suppression of leading space
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] snip / The space constraints probably (hopefully )only applies to space specifiers on the FOs itself, i.e if I had written fo:inline space-end=2pt... Space characters ought to be another matter. Try: fo:block background-color=red font-size=20pt fo:inline background-color=blue font-size=10ptfoo /fo:inlinefo:inline background-color=green font-size=15pt bar/fo:inline/fo:block Arghh! First hadn't even noticed the lf after foo... Should it make a difference whether you write: fo:inline ...sth/fo:inline or fo:inline ...sth /fo:inline or fo:inline ... sth /fo:inline Doesn't that depend ... ? (I'm trying to see on what exactly) Using the default values for the related properties (see Finn's OP), space would *always* remain for the latter two cases. Now, don't know for sure what's considered to be best practice, but maybe the only way to really 'solve' the original issue, would be at the FO level. Just advise everyone to use LF rather in the markup itself (like in your example, the second fo:inline). So if, in the last case here above, one *really* needs to avoid trailing and leading spaces, one could rearrange it like (most extreme case) : fo:inline ... sth/fo:inline or fo:inline ... someverylongphraserunningthroughtotheendofthepagewhichiseemtobeunabletoachi eveatthemoment /fo:inline So, in short, no LF between and the start of the content, nor between the end of the content and . Perfectly admitted. Cheers, Andreas
DO NOT REPLY [Bug 25673] - [PATCH] access to fobj.elementTable cause eclipse warning.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25673. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25673 [PATCH] access to fobj.elementTable cause eclipse warning. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-20 16:11 --- Fixed. You'll see shortly--thanks, Glen.
RE: Setup code in Driver
Jeremias Maerki wrote:
The answer to your question probably lies in understanding how and why
getContentHandler() is used without also using render(). The
FOTreeListener
is only needed if the input document is parsed, and in fact is
only needed
if you want to break out of parsing to go do something at a higher level
before returning (the normal SAX events are not affected at all). So:
1) if the process running getContentHandler() doesn't ever parse, don't
bother registering the FOTreeListener
Does that ever happen? I would assume that anyone who calls
getContentHandler() will want to send SAX events. I don't think I
understand what you're trying to explain. Sorry.
I don't know whether it happens or not. I can't think of a reason for this
to be done. Since I don't understand how this is getting used, I was just
trying to cover all possibilities.
2) if the process running getContentHandler() doesn't care about being
notified about the end of a PageSequence (which is the only
FOTreeListener
event that is *unique*), don't bother registering the FOTreeListener
Ok, I guess that is something that was introduced by your LayoutStrategy.
Would you explain to me what you mean by process in this context?
It is only loosely related to LayoutStrategy. It had more to do with trying
to separate the parsing and layout (somewhat foundational to LayoutStrategy,
but useful even apart from that). fo.FOTreeEvent and fo.FOTreeListener kind
of mimic what the SAX events do, but are fired from within FOP as the FOTree
is being built. This allows FOTree to do its thing without needing to know
how it is being used.
By process I just mean whatever embedded application is calling
getContentHandler().
3) otherwise, have it wrap its parsing code inside of the
following (which
is what is wrapped around parser.parse in render() now):
before
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler =
(FOTreeHandler)foInputHandler;
foTreeHandler.addFOTreeListener(currentDocument);
}
/before
after
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler =
(FOTreeHandler)foInputHandler;
foTreeHandler.removeFOTreeListener(currentDocument);
}
/after
Better yet, refactor both of the above code snippets into
methods that can
be called more simply, since this code would now be used more than once.
As methods of Document?
Since the code is in Driver now, I was thinking Driver. However, it will
work from Document also. You'll just need to use getDriver() to get to the
foInputHandler.
Just looking at what is left in render(), I don't quite follow
why it would
ever *not* be used if parsing will take place. The only thing
left in there
is parser.parse(), the above code that it is wrapped in, and the code to
*not* parse based on the LayoutStrategy's wishes. Since the
parser itself
can be passed as a parameter, it seems like anybody parsing
could/would use
it. If you will describe the use case(s) a bit, I'll try to be
of more help.
Use cases that are not using render? Most prominent use case is Cocoon
which build a SAX pipeline where FOP can be the end of that pipeline. So
Cocoon needs a ContentHandler. Cocoon will not be able to call the
render() method. Personally, I have never used FOP's render() method as
a FOP user. I've always worked with getContentHandler(). I guess the
Cocoon use-case should be enough to convince you that the
getContentHandler() is necessary.
The only thing going on in render right now is parser.parse(). Based on your
above answer to #1, Cocoon must be doing something like that internally???
And based on your answer immediately above, it absolutely cannot use
render() to do that. Although I don't grasp why this should be true, taking
it at face value, and assuming that we want FOP to layout this document,
here are the options:
1. The equivalent of parser.parse() that exists in the embedded app (Cocoon)
will need to be wrapped in the code that activates the FOTreeListener. The
code in render() that checks to see whether the LayoutStrategy wants to
build an FOTree or not probably needs to be included as well, and again, it
should probably be extracted into a method, or included in the before
method. (This was the code I recently added to accommodate alt-design so
that it could create its own data structure instead of using FOTree).
2. The FOTreeListener concept can be abandoned. Simply restore to the
original scheme, which had the FOTree start the layout process for the
PageSequence as parsing was completed for it. I don't remember exactly where
that is, but it is wherever the FOTreeEvent is being fired. Here are the
costs that I can think of to this approach:
a. Either LayoutStrategy needs to be abandoned, or the LayoutStrategy
implementation needs to be made
cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java PropertyList.java
gmazza 2003/12/20 09:40:01
Modified:.build.xml
src/java/org/apache/fop/fo FObj.java PropertyList.java
Added: src/codegen fo-property-mapping.xsl
Removed: src/codegen propmap.xsl
Log:
Property Makers now being activated via int constants. (Maker classes themselves,
as well as code referencing the properties, still need conversion to int's. Also,
HashMaps for String and Integer in FOPropertyMapping and FObj temporarily being
retained for troubleshooting purposes.) Contribution mainly from Finn Bock (Bug
#25480).
Revision ChangesPath
1.94 +1 -2 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -r1.93 -r1.94
--- build.xml 15 Dec 2003 01:07:50 - 1.93
+++ build.xml 20 Dec 2003 17:40:01 - 1.94
@@ -209,7 +209,6 @@
property name=colorkw.xml value=${build.codegen}/colorkw.xml/
property name=properties.xsl value=${build.codegen}/properties.xsl/
-property name=propmap.xsl value=${build.codegen}/propmap.xsl/
property name=enumgen.xsl value=${build.codegen}/enumgen.xsl/
property name=propinc.xsl value=${build.codegen}/propinc.xsl/
property name=src.charlist.xsl
value=${src.codegen}/code-point-mapping.xsl/
@@ -354,7 +353,7 @@
style in=${foproperties.xml} style=${properties.xsl}
out=${build.gensrc}/${replacestring}/fo/properties/fo_${ignore_this}/
-style in=${foproperties.xml} style=${propmap.xsl}
+style in=${foproperties.xml} style=${build.codegen}/fo-property-mapping.xsl
out=${build.gensrc}/${replacestring}/fo/properties/FOPropertyMapping.java/
style in=${foproperties.xml} style=${enumgen.xsl}
out=${build.gensrc}/${replacestring}/fo/properties/foenums_${ignore_this}/
1.1 xml-fop/src/codegen/fo-property-mapping.xsl
Index: fo-property-mapping.xsl
===
!--
$Id: fo-property-mapping.xsl,v 1.1 2003/12/20 17:40:01 gmazza Exp $
The Apache Software License, Version 1.1
Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names FOP and Apache Software Foundation must not be used to
endorse or promote products derived from this software without prior
written permission. For written permission, please contact
[EMAIL PROTECTED]
5. Products derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals
on behalf of the Apache Software Foundation and was originally created by
James Tauber [EMAIL PROTECTED]. For more information on the Apache
Software Foundation, please see http://www.apache.org/.
--
xsl:stylesheet version=1.0
AW: AW: What should I be doing ?
Christian Ziesemer wrote: Do you know other projects dealing with high quality typesetting with Java or if Java 1.5 will bring improvements? I'm thinking about writing my diploma thesis about how to extend the current/implement a typesetting API for Java. Batik extends text attributes with kerning, word and character spacing. The beauty of pure Java2D text is : you do not have to preprocess fonts files and to deal with glyph metrics. If you want I will send you my font test program. There will be a Java2D text rework in Java 1.5 to eliminate bugs and improve some internals. What is your idea of a typesetting API? Something like a FOP renderer interface, storing a document as graphics objects in memory, a formatter? Hansuli Anderegg
cvs commit: xml-fop/src/java/org/apache/fop/fo/properties TextDecoration.java Property.java Background.java
pbwest 2003/12/20 17:38:52
Modified:src/java/org/apache/fop/configuration Tag:
FOP_0-20-0_Alt-Design Configuration.java
src/java/org/apache/fop/fo/properties Tag:
FOP_0-20-0_Alt-Design TextDecoration.java
Property.java Background.java
Log:
Removed unnecessary semi-colons on advice from Eclipse.
Revision ChangesPath
No revision
No revision
1.1.2.2 +1 -2
xml-fop/src/java/org/apache/fop/configuration/Attic/Configuration.java
Index: Configuration.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/configuration/Attic/Configuration.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Configuration.java5 Jul 2003 19:05:39 - 1.1.2.1
+++ Configuration.java21 Dec 2003 01:38:52 - 1.1.2.2
@@ -77,7 +77,6 @@
* stores the configuration information
*/
private static HashMap standardConfiguration = new HashMap(30);
-;
private static HashMap pdfConfiguration = new HashMap(20);
private static HashMap awtConfiguration = new HashMap(20);
No revision
No revision
1.1.2.2 +2 -2
xml-fop/src/java/org/apache/fop/fo/properties/Attic/TextDecoration.java
Index: TextDecoration.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Attic/TextDecoration.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- TextDecoration.java 5 Jul 2003 19:22:24 - 1.1.2.1
+++ TextDecoration.java 21 Dec 2003 01:38:52 - 1.1.2.2
@@ -85,7 +85,7 @@
,LINE_THROUGH = 4
,BLINK = 8
- ,ALL_DECORATIONS = UNDERLINE | OVERLINE | LINE_THROUGH | BLINK;
+ ,ALL_DECORATIONS = UNDERLINE | OVERLINE | LINE_THROUGH | BLINK
;
1.1.2.2 +4 -4
xml-fop/src/java/org/apache/fop/fo/properties/Attic/Property.java
Index: Property.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Attic/Property.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Property.java 5 Jul 2003 19:22:26 - 1.1.2.1
+++ Property.java 21 Dec 2003 01:38:52 - 1.1.2.2
@@ -829,7 +829,7 @@
try {
colorFound = new ColorType(colorProp, ncname);
-} catch (PropertyException e) {};
+} catch (PropertyException e) {}
if (colorFound != null) {
if (color != null) MessageHandler.logln(propName +
: duplicate color overrides previous color);
1.1.2.2 +4 -4
xml-fop/src/java/org/apache/fop/fo/properties/Attic/Background.java
Index: Background.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Attic/Background.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Background.java 5 Jul 2003 19:22:22 - 1.1.2.1
+++ Background.java 21 Dec 2003 01:38:52 - 1.1.2.2
@@ -239,7 +239,7 @@
try {
colorval = new ColorType
(PropNames.BACKGROUND_COLOR, ncname);
- } catch (PropertyException e) {};
+ } catch (PropertyException e) {}
if (colorval != null) {
if (color != null) MessageHandler.log(background: +
duplicate color overrides previous color);
@@ -252,7 +252,7 @@
try {
enum = new EnumType
(PropNames.BACKGROUND_ATTACHMENT, ncname);
- } catch (PropertyException e) {};
+ } catch (PropertyException e) {}
if (enum != null) {
if (attachment != null)
MessageHandler.log(background: duplicate +
@@ -291,7 +291,7 @@
Object tmpo = elements.previous();
}
}
- } catch (PropertyException e) {};
+ } catch (PropertyException e) {}
if (pos1ok) {
if (position != null)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop .project
pbwest 2003/12/20 17:41:52 Modified:.Tag: FOP_0-20-0_Alt-Design .project Log: Meta-file update for Eclipse Revision ChangesPath No revision No revision 1.1.2.3 +8 -2 xml-fop/Attic/.project Index: .project === RCS file: /home/cvs/xml-fop/Attic/.project,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- .project 9 Jul 2003 00:30:50 - 1.1.2.2 +++ .project 21 Dec 2003 01:41:52 - 1.1.2.3 @@ -1,13 +1,19 @@ ?xml version=1.0 encoding=UTF-8? projectDescription - namefop-alt.design/name + nameFOP_Alt-Design/name comment/comment projects /projects buildSpec buildCommand - namecom.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder/name + nameorg.eclipse.ui.externaltools.ExternalToolBuilder/name arguments + dictionary + keyLaunchConfigHandle/key + valuelt;?xml version=quot;1.0quot; encoding=quot;UTF-8quot;?gt; +lt;launchConfiguration local=quot;falsequot; path=quot;/FOP_Alt-Design/.externalToolBuilders/com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder.launchquot;/gt; +/value + /dictionary /arguments /buildCommand buildCommand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Setup code in Driver
--- Victor Mote [EMAIL PROTECTED] wrote: Also, if possible, please let me know what you decide. I am evaluating in-progress projects right now to determine which ones I should finish and which ones I should abandon as I exit the project. You've mentioned before, I believe, there was some things you wished to do to improve the fonts. That may be good--because most of us have not researched them. If LayoutStrategy survives reasonably intact, I am much inclined to try to complete the port of the pioneer LS. I'd rather you not. I don't want to have to maintain the 0.20.x layout strategy in addition to the 1.0 strategy in 1.0. The committers and contributors (Simon and Chris, in particular) are happy working on the improving 1.0 layout and wish to remain with it. Recent patches (hyphenation, borders) to 1.0 LS have made 0.20.x even more behind. Also, the 1.0 Area Tree and Renderers are incompatible with 0.20.x LS, I don't want their architectures changed in order to accomodate it. Those who wish to use the 0.20.x layout strategy can continue to run 0.20.x. Let the decision to bring in that LS be with the ones who will have to maintain it. As for me, getting one LS right is more than enough work. Glen __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
