DO NOT REPLY [Bug 27152] New: - AWT produces different layout than PDF renderer

2004-02-23 Thread bugzilla 
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=27152.
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=27152

AWT produces different layout than PDF renderer

   Summary: AWT produces different layout than PDF renderer
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: awt renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Layout from AWT Renderer differs considerably from PDF renderer:
letter spacing is different, line heights are different.

As I understand it, the AWT renderer retrieves font metrics from java.awt.Font.
The PDF renderer uses metrics files that were generated with TTFReader (from the
very same TrueType fonts).

I expect that both methods produce the same result, but they don't !?

It should be possible to use EXACTLY the same metrics info for the AWT Renderer.

DO NOT REPLY [Bug 27152] - AWT produces different layout than PDF renderer

2004-02-23 Thread bugzilla 
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=27152.
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=27152

AWT produces different layout than PDF renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-02-23 12:24 ---
This is NOT a bug. FOP is working as designed, and yes there are differences 
between AWT and PDF. What about text output, that is very different from PDF, 
but the difference is not a bug, because the differences are to be expected. 
The same is true for AWT.

What we could and should change is the website to explain what users can 
expect from AWT, here:

http://xml.apache.org/fop/output.html#awt

DO NOT REPLY [Bug 27152] - AWT produces different layout than PDF renderer

2004-02-23 Thread bugzilla 
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=27152.
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=27152

AWT produces different layout than PDF renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-02-23 12:45 ---
I see what you mean.

My problem is this: I would like to include a preview dialog in my application,
and it's very unfortunate when the preview looks different than the resulting PDF.

I would suggest that you either:
 * make metrics files available for AWTRenderer
or
 * make sure that these metrics files are identical to the AWT font metrics

Regards, Peter

cvs commit: xml-fop/src/java/org/apache/fop/area/inline InlineContainer.java

2004-02-23 Thread pbwest 
pbwest  2004/02/23 05:18:37

  Modified:src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
BlockContainer.java ReferenceArea.java Area.java
   src/java/org/apache/fop/area/inline Tag:
FOP_0-20-0_Alt-Design InlineContainer.java
  Log:
  Adjusted for new stubs
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.4   +5 -3  xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java
  
  Index: BlockContainer.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java,v
  retrieving revision 1.1.2.3
  retrieving revision 1.1.2.4
  diff -u -r1.1.2.3 -r1.1.2.4
  --- BlockContainer.java   1 Feb 2004 08:12:00 -   1.1.2.3
  +++ BlockContainer.java   23 Feb 2004 13:18:37 -  1.1.2.4
  @@ -25,7 +25,9 @@
* @author pbw
* @version $Revision$ $Name$
*/
  -public class BlockContainer extends BlockArea implements ReferenceArea {
  +public class BlockContainer
  +extends AbstractReferenceArea
  +implements ReferenceArea {
   
   /**
* @param parent
  
  
  
  1.1.2.3   +21 -3 xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java
  
  Index: ReferenceArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java,v
  retrieving revision 1.1.2.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- ReferenceArea.java1 Feb 2004 05:47:38 -   1.1.2.2
  +++ ReferenceArea.java23 Feb 2004 13:18:37 -  1.1.2.3
  @@ -23,6 +23,24 @@
* @author pbw
* @version $Revision$ $Name$
*/
  -public interface ReferenceArea {
  +public interface ReferenceArea extends Cloneable {
   
  +/**
  + * Set the Coordinate Transformation Matrix which transforms content
  + * coordinates in this reference area which are specified in
  + * terms of start and before into coordinates in a system which
  + * is positioned in absolute directions (with origin at lower left of
  + * the reference area.
  + *
  + * @param matrix the current transform to position this region
  + */
  +public void setCoordTransformer(CoordTransformer matrix);
  +
  +/**
  + * Get the current transformer of this reference area.
  + *
  + * @return the current transformer to position this reference area.
  + */
  +public CoordTransformer getCoordTransformer();
  +
   }
  
  
  
  1.1.2.5   +99 -1 xml-fop/src/java/org/apache/fop/area/Area.java
  
  Index: Area.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Area.java,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  --- Area.java 16 Feb 2004 00:15:29 -  1.1.2.4
  +++ Area.java 23 Feb 2004 13:18:37 -  1.1.2.5
  @@ -22,18 +22,32 @@
   import org.apache.fop.datastructs.SyncedNode;
   
   /**
  + * @author pbw
  + * @version $Revision$ $Name$
  + */
  +/**
  + * @author pbw
  + * @version $Revision$ $Name$
  + */
  +/**
* The base class for all areas.  codeArea/code extends codeNode/code
* because all areas will find themselves in a tree of some kind.
* @author pbw
* @version $Revision$ $Name$
*/
  -public class Area extends SyncedNode {
  +public class Area extends SyncedNode implements Cloneable  {
   
  +/** Current inline progression dimension.  May be unknown. */
   protected Integer iPDim = null;
  +/** Maximum required inline progression dimension.  May be unknown. */
   protected Integer iPDimMax = null;
  +/** Mimimum required inline progression dimension.  May be unknown. */
   protected Integer iPDimMin = null;
  +/** Current block progression dimension.  May be unknown. */
   protected Integer bPDim = null;
  +/** Maximum required block progression dimension.  May be unknown. */
   protected Integer bPDimMax = null;
  +/** Mimimum required block progression dimension.  May be unknown. */
   protected Integer bPDimMin = null;
   
   /**
  @@ -55,6 +69,90 @@
   throws IndexOutOfBoundsException {
   super(parent, areaSync);
   // TODO Auto-generated constructor stub
  +}
  +
  +/**
  + * @return the bPDim
  + */
  +public Integer getBPDim() {
  +return bPDim;
  +}
  +
  +/**
  + * @param dim to set
  + */
  +public void setBPDim(Integer dim) {
  +bPDim = dim;
  +}
  +
  +/**
  + * @return the bPDimMax
  + */
  +public Integer getBPDimMax() {
  +return bPDimMax;
  +}
  +
  +/**
  + * @param dimMax to set
  + */
  +public void setBPDimMax(Integer dimMax) {
  +bPDimMax =

Re: ASF Board Summary for February 18, 2004

2004-02-23 Thread Jeremias Maerki 
Ye. ;-)

On 23.02.2004 16:06:42 Glen Mazza wrote:
 Score (another) one for Jeremias...  ;)
 
 --- Greg Stein [EMAIL PROTECTED] wrote:
 
- author tags are officially discouraged. these
  create difficulties in
  establishing the proper ownership and the
  protection of our
  committers. there are other social issues
  dealing with collaborative
  development, but the Board is concerned about
  the legal ramifications
  around the use of author tags
  
- it is quite acceptable and encouraged to
  recognize developers' efforts
  in a CHANGES file, or some other descriptive
  file which is associated
  with the overall PMC or release rather than
  individual files.
  



Jeremias Maerki

DO NOT REPLY [Bug 27152] - AWT produces different layout than PDF renderer

2004-02-23 Thread bugzilla 
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=27152.
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=27152

AWT produces different layout than PDF renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-02-23 15:37 ---
If you need a preview, you could have a look at Multivalent 
(http://http.cs.berkeley.edu/~phelps/Multivalent/) which (I think) has a PDF 
viewer in Java under a BSD-style license. I haven't used it so I can't say 
anything about its quality. Another possibility may be to use Eclipse.org's 
SWT which enables you to display Acrobat Reader inside your application just 
as IE and Mozilla and friends can. I heard that it's now possible to use Swing 
inside SWT. Awkward but maybe it helps. Just a couple of ideas...

Re: embed images

2004-02-23 Thread Jeremias Maerki 
You're right. The URL protocol handler would have been simple.

Probably the easiest way is to modify
org.apache.fop.image.FopImageFactory. The Make method gets the URL
string and tries to get an InputStream.

VFS? At one time I suggested using the Source(Resolver) mechanism from
Avalon which originally came from the Cocoon project. It provides some
sort of VFS which could be used to do the kind of stuff you need. But
this is future talk and will take some time to implement.

On 22.02.2004 22:27:49 Heiko Barthel wrote:
 I've got a special question using FOP 0.20.5:
 I want to include GIF and JPEG images in the PDF which are not accessible
 neither through HTTP, FTP nor the local file system. They reside only in
 memory. I can imagine the following solutions:
 1. URL protocol handler
 2. FO extension
 3. something like a virtual file system
 
 URL protocol handler implemention is simple but unfortunately does not work
 because I had to set the System property java.protocol.handler.pkgs which
 is write protected in our production environment.
 
 Is there a possibility to embed the images in the FO file ? So I could
 implement an FO extension. What ideas about a VFS ?
 Any help and advice is welcome.



Jeremias Maerki

DO NOT REPLY [Bug 27152] - AWT produces different layout than PDF renderer

2004-02-23 Thread bugzilla 
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=27152.
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=27152

AWT produces different layout than PDF renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-02-23 16:37 ---
Thanks !!

Multivalent looks really interesting.

RE: [PATCH] Support for percentages and table-units

2004-02-23 Thread Andreas L. Delmelle 
 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]

Some babbling about trees and ladders ...
snip /
 There's a lot of subjective judgement in making such calls, which is why
 it's useful to have a number of different opinions kicking ideas around.


Yeah.. it probably is too subjective to settle in a few sentences. Of
course, a whole lot of different 'types' of 'most common cases' are possible
(--depending more on the usage context: 1 or 2 paged, but very
processor-intensive documents vs. 48 pages of plain body-text )

I guess it calls more for a sort of recon approach (checking out the tree
before deciding what ladder to bring :) one trip back to the workshop was
part of the deal...)

snip /
 I find the language of the java.lang.ref package confusing, but I think
 that phantom references open the possibility of performing serialization
   on demand, when the object is queued for GC.
 
 
 
  Can you elaborate a bit on this? AFAICT, the actual referent of
 a phantom
  reference is itself unreachable through the reference object (the ref's
  get() method always returns null), so you could indeed test via
 isEnqueued()
  whether or not the referent of a phantom reference is queued for GC, and
  then...? A soft reference at least would allow to get() the
 object and do
  something with it or make it do something with itself before actually
  clearing the ref.

 As I say, I find the language confusing, but it seemed to me that, as
 long as the object being GC'd contained enough information to determine
 its origins, when it found its way onto the reference queue for disposal
 the thread responsible could serialize it just before it was destroyed,
 and store the information required for its recovery in the appropriate
 place.  The same may be achievable using the other reference types.


In a way, I was actually wondering whether you were thinking of only using
the phantom ref to *test* for an object being queued, and possibly use the
object itself to do the serialization?
(science-fiction: I was thinking of an object being created and being
phantom referenced, and when being created, also being given a way to access
its own phantom reference to be able to find out whether it is scheduled for
GC, and if so, trigger a serialize() method... seemed a bit 'ridiculous'
when I thought it over --in the sense of: ridiculously unfeasible, my wild
imagination)

 Whether the imprecations against finalizers apply also to phantom
 reference finalizers I don't know.


Hmm. IIC the whole idea of Reference objects is to allow more fine-grained
control WRT object finalizing. Where a finalizer is executed *when* an
object is scheduled for GC, period. With the reference types, this control
is left to the programmers --i.e. conditional finalizing.. You could write a
finalizer whose body is totally conditional (enclosed in an if-statement),
but the method would be entered anyway in the case of a 'classic' finalizer,
even if only to perform the test.
By use of the ref types, one can even choose to execute a different kind of
finalizer for different situations, and, more importantly, it separates the
finalizing logic from the logic of the object/class.

So whether the imprecations against finalizers also apply here, depends
totally upon ourselves, it would seem.

Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

2004-02-23 Thread J.Pietschmann 
Finn Bock wrote:
I don't understand how you propose to solve any of this, but I hope it 
would be Ok to commit the straight forward solution I propose.
Whatever works. I just want to note that given the almost one-
to-one correspondence between FOs and LMs both in classes and
instances (with the exceptions of page, column and line LM),
the only advantages of having LMs is
- code reuse by inheritance
- no layout related data in the FO, for better sharing/reuse
Keeping area dimensions in the FO kills the latter.
For storing reference measurements for resolving in the layout
context, you have only to keep track of inheritable properties,
which are basically font-size, ipd and bpd. References to
specified values (in contrast to computed values) can be handled
by splicing in the parsed property expression for the referenced
property as replacement for the referencing function. This way
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
J.Pietschmann

Re: Fwd: ASF Board Summary for February 18, 2004

2004-02-23 Thread Peter B. West 
Don't speak too soon, Glen.  I'll  have words to the Board about this. 
If the Board were concerned about the legal ramifications, they would be 
obliged to mandate the removal of author tags.  Why don't they?  Until 
they demonstrate otherwise, I'll assume that the *real* agenda is 
...social issues dealing with collaborative development, and ignore 
the Board's discouragement.

Peter

Glen Mazza wrote:
Score (another) one for Jeremias...  ;)

--- Greg Stein [EMAIL PROTECTED] wrote:

 - author tags are officially discouraged. these
create difficulties in
   establishing the proper ownership and the
protection of our
   committers. there are other social issues
dealing with collaborative
   development, but the Board is concerned about
the legal ramifications
   around the use of author tags
 - it is quite acceptable and encouraged to
recognize developers' efforts
   in a CHANGES file, or some other descriptive
file which is associated
   with the overall PMC or release rather than
individual files.




--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

PS PCL: How do I test them?

2004-02-23 Thread Glen Mazza 
Team, simple question:

I use Adobe Acrobat to test PDF results.  Are there any free/open-source 
viewers to test PCL and PS results -- on either Windows or Linux?  I've 
never used PS  PCL before, so I don't know much about them.

Thanks,
Glen

cvs commit: xml-fop/src/java/org/apache/fop/area Resolveable.java RegionStartVport.java Viewport.java RegionEndVport.java RegionStartRefArea.java CoordTransformer.java RegionBeforeVport.java MainReferenceArea.java Span.java RegionRefArea.java RegionAfterVport.java RegionBodyVport.java PageRefArea.java PageViewport.java RegionBodyRefArea.java RegionEndRefArea.java RegionAfterRefArea.java RegionViewport.java RegionBeforeRefArea.java AbstractReferenceArea.java

2004-02-23 Thread pbwest 
pbwest  2004/02/23 23:54:00

  Added:   src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
Resolveable.java RegionStartVport.java
Viewport.java RegionEndVport.java
RegionStartRefArea.java CoordTransformer.java
RegionBeforeVport.java MainReferenceArea.java
Span.java RegionRefArea.java RegionAfterVport.java
RegionBodyVport.java PageRefArea.java
PageViewport.java RegionBodyRefArea.java
RegionEndRefArea.java RegionAfterRefArea.java
RegionViewport.java RegionBeforeRefArea.java
AbstractReferenceArea.java
  Log:
  More stubs for area processing.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +0 -0  xml-fop/src/java/org/apache/fop/area/Resolveable.java
  
  Index: Resolveable.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Resolveable.java,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  
  
  
  1.1.2.1   +42 -0 xml-fop/src/java/org/apache/fop/area/Attic/RegionStartVport.java
  
  
  
  
  1.1.2.1   +28 -0 xml-fop/src/java/org/apache/fop/area/Attic/Viewport.java
  
  
  
  
  1.1.2.1   +42 -0 xml-fop/src/java/org/apache/fop/area/Attic/RegionEndVport.java
  
  
  
  
  1.1.2.1   +41 -0 
xml-fop/src/java/org/apache/fop/area/Attic/RegionStartRefArea.java
  
  
  
  
  1.1.2.1   +333 -0xml-fop/src/java/org/apache/fop/area/Attic/CoordTransformer.java
  
  
  
  
  1.1.2.1   +42 -0 
xml-fop/src/java/org/apache/fop/area/Attic/RegionBeforeVport.java
  
  
  
  
  1.1.2.1   +86 -0 
xml-fop/src/java/org/apache/fop/area/Attic/MainReferenceArea.java
  
  
  
  
  1.1.2.1   +29 -83xml-fop/src/java/org/apache/fop/area/Span.java
  
  Index: Span.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Span.java,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  --- Span.java 11 Mar 2003 13:05:27 -  1.1
  +++ Span.java 24 Feb 2004 07:54:00 -  1.1.2.1
  @@ -1,83 +1,48 @@
   /*
  +   Copyright 1999-2004 The Apache Software Foundation.
  +
  +   Licensed under the Apache License, Version 2.0 (the License);
  +   you may not use this file except in compliance with the License.
  +   You may obtain a copy of the License at
  +
  +   http://www.apache.org/licenses/LICENSE-2.0
  +
  +   Unless required by applicable law or agreed to in writing, software
  +   distributed under the License is distributed on an AS IS BASIS,
  +   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  +   See the License for the specific language governing permissions and
  +   limitations under the License.
  +
* $Id$
  - * 
  - *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

cvs commit: xml-fop/src/java/org/apache/fop/datastructs SyncedNode.java

2004-02-23 Thread pbwest 
pbwest  2004/02/23 23:56:34

  Modified:src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design SyncedNode.java
  Log:
  Implement Cloneable.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.3   +8 -8  
xml-fop/src/java/org/apache/fop/datastructs/Attic/SyncedNode.java
  
  Index: SyncedNode.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/SyncedNode.java,v
  retrieving revision 1.1.2.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- SyncedNode.java   16 Feb 2004 00:15:29 -  1.1.2.2
  +++ SyncedNode.java   24 Feb 2004 07:56:34 -  1.1.2.3
  @@ -26,7 +26,7 @@
* @author pbw
* @version $Revision$ $Name$
*/
  -public class SyncedNode extends Node {
  +public class SyncedNode extends Node implements Cloneable {
   
   public final Object sync;
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop/src/java/org/apache/fop/area TransformMatrix.java

2004-02-23 Thread pbwest 
pbwest  2004/02/23 23:57:51

  Removed: src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
TransformMatrix.java
  Log:
  Renamed toi CoordTransformer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]