Eclipse checkstyle
Jeremias, Joerg and other Eclipse users, I'm trying to apply Checkstyle 3.1.0 to fop-head via Eclipse 2.1, and am having a few problems. I cannot import the checkstyle.cfg file, so I have constructed a new one. I seem to have been much too restrictive in what I have tried, and am now working my way through deleting or detuning rules. I have since that paragraph was written received some info from David Schneider on the Eclipse-cs-developer list. It seems the checkstyle.cfg we have in fop-head is pre-version 3. Version 3.1.0 does not support the check for a header file, which is why it does not appear in the Preferences Checkstyle UI, or linked into the relavant integrated documentation. That will not be available until at least 3.2. I will commit a 3.1.0 style config, and those of you who haave followed the style discussion more closely might like to modify it. I suspect there are more options in the new version. I am on a steep learning curves with Checkstyle and the conventions, which I am planning to apply to alt.design before going any further. That learning curve is probably another reason to cast an eye over the config I create. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Eclipse Ant SerializeHyphPattern failure
I think so. Please remove them. On 19.06.2003 11:27:15 Peter B. West wrote: Done. The hyphenation works now. What's the story with the documentation targets now that we are using forrest? Can they be removed? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Eclipse checkstyle
Oh, I didn't realize that David has a new version of his excellent plug-in. He said he would drop me a note when the new version for checkstyle 3.x is out. Hmm. I'm downloading right now. Can you upload what you have already? On 20.06.2003 08:14:21 Peter B. West wrote: Jeremias, Joerg and other Eclipse users, I'm trying to apply Checkstyle 3.1.0 to fop-head via Eclipse 2.1, and am having a few problems. I cannot import the checkstyle.cfg file, so I have constructed a new one. I seem to have been much too restrictive in what I have tried, and am now working my way through deleting or detuning rules. I have since that paragraph was written received some info from David Schneider on the Eclipse-cs-developer list. It seems the checkstyle.cfg we have in fop-head is pre-version 3. Version 3.1.0 does not support the check for a header file, which is why it does not appear in the Preferences Checkstyle UI, or linked into the relavant integrated documentation. That will not be available until at least 3.2. I will commit a 3.1.0 style config, and those of you who haave followed the style discussion more closely might like to modify it. I suspect there are more options in the new version. I am on a steep learning curves with Checkstyle and the conventions, which I am planning to apply to alt.design before going any further. That learning curve is probably another reason to cast an eye over the config I create. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop checkstyle1.3.0-head
pbwest 2003/06/20 00:41:58 Added: .checkstyle1.3.0-head Log: Plugin config for Checkstyle 1.3.0 Revision ChangesPath 1.1 xml-fop/checkstyle1.3.0-head Index: checkstyle1.3.0-head === ?xml version=1.0 encoding=UTF-8? checkstyle-configurations file-format-version=1.0.0 check-configuration name=head rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocVariableCheck severity=warning comment=Protected scope config-properties config-property name=severity value=warning/ config-property name=scope value=protected/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocTypeCheck severity=warning comment=Protected scope config-properties config-property name=severity value=warning/ config-property name=tokens value=CLASS_DEF, INTERFACE_DEF/ config-property name=authorFormat value=/ config-property name=scope value=protected/ config-property name=versionFormat value=/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocMethodCheck severity=warning comment=Protected scope config-properties config-property name=allowThrowsTagsForSubclasses value=false/ config-property name=allowUndeclaredRTE value=false/ config-property name=severity value=warning/ config-property name=tokens value=METHOD_DEF, CTOR_DEF/ config-property name=allowMissingParamTags value=false/ config-property name=scope value=protected/ config-property name=allowMissingReturnTag value=false/ config-property name=allowMissingThrowsTags value=false/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.MemberNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z][a-zA-Z0-9]*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.LocalVariableNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z][a-zA-Z0-9]*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.LocalFinalVariableNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z][a-zA-Z0-9]*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.ConstantNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[A-Z](_?[A-Z0-9]+)*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.MethodNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z][a-zA-Z0-9]*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.PackageNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z]+(\.[a-zA-Z_][a-zA-Z0-9_]*)*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.ParameterNameCheck severity=warning config-properties config-property name=severity value=warning/ config-property name=format value=^[a-z][a-zA-Z0-9]*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.StaticVariableNameCheck severity=warning config-properties config-property name=severity
Re: Eclipse checkstyle
Done. It is currently notifying many, many style violations, so I am working my way through, but you will probably spot things faster. I think i many cases there is just no consistency because the issue has never been canvassed. The Import and Export of Plugin Configs works for me, but any attempt to Export Checkstyle Config fails for me - Eclipse 1.2 RH9 j2sdk1.4.1_03. I have to say that I am enjoying Eclipse enormously. Peter Jeremias Maerki wrote: Oh, I didn't realize that David has a new version of his excellent plug-in. He said he would drop me a note when the new version for checkstyle 3.x is out. Hmm. I'm downloading right now. Can you upload what you have already? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: startup refactoring
The current FOP is not fit for i18n, directions, area orientations and does not even support a dotted line. Renderes too. Design correct data objects in the first place instead of fancy control mechanisms. - what do pipelines look like? - are there really pipelines or are partial document fragments passed on? What's in memory at any time? main o initialize o parse XSL o layout pages o render x times initialize o process config output: global config objects o get platform info output: global platform objects parse XSL o process layout-master-sets, page-sequences output: internal page description objects o process flows - standardize properties (measurements, property synonyms) - resolve XSL inheritance to avoid tricky states, switches - calculate FO dimensions as far as possible and transform output content: to a suitable representation (my favorite: Graphics2D) output document stucture, areas: into FOTree with pointers to content output unique property/attribute maps: memory savers layout pages o apply page descriptions to flows o paginate: fill pages sequentially, split content objects o resolve references output: content objects supplemented with page coordinates on a device-independent way o baptize the result Area Tree render o process renderer configuration o output content objects in a device-dependent format Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/area CTM.java
pbwest 2003/06/20 03:06:17
Modified:src/java/org/apache/fop/area CTM.java
Log:
Changed positioning of '{' in nested blocks
Revision ChangesPath
1.2 +2 -4 xml-fop/src/java/org/apache/fop/area/CTM.java
Index: CTM.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/CTM.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CTM.java 11 Mar 2003 13:05:27 - 1.1
+++ CTM.java 20 Jun 2003 10:06:17 - 1.2
@@ -146,15 +146,13 @@
switch (wm) {
case WritingMode.LR_TB:
return new CTM(CTM_LRTB);
-case WritingMode.RL_TB:
-{
+case WritingMode.RL_TB: {
wmctm = new CTM(CTM_RLTB);
wmctm.e = ipd;
return wmctm;
}
//return CTM_RLTB.translate(ipd, 0);
-case WritingMode.TB_RL: // CJK
-{
+case WritingMode.TB_RL: { // CJK
wmctm = new CTM(CTM_TBRL);
wmctm.e = bpd;
return wmctm;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20943] New: - number-rows-spanned render spanned cell background.
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=20943. 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=20943 number-rows-spanned render spanned cell background. Summary: number-rows-spanned render spanned cell background. Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] example: fo:table fo:table-row fo:table-cell number-rows-spanned=2Spanned/fo:table-cell fo:table-cell#160;/fo:table-cell fo:table-cellFirst row/fo:table-cell /fo:table-row fo:table-row background-color=red fo:table-cell#160;/fo:table-cell fo:table-cellSecond row/fo:table-cell /fo:table-row /fo:table spanned cell be filled with background-color red. and if I set: fo:table-cell number-rows-spanned=2 border=2pt solid Spanned/fo:table-cell The cell border is only 1 cell height. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/servlet FopPrintServlet.java
pbwest 2003/06/20 03:15:41 Modified:src/java/org/apache/fop/servlet FopPrintServlet.java Log: Removed space before ';' Revision ChangesPath 1.5 +1 -1 xml-fop/src/java/org/apache/fop/servlet/FopPrintServlet.java Index: FopPrintServlet.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/servlet/FopPrintServlet.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- FopPrintServlet.java 17 Jun 2003 16:35:57 - 1.4 +++ FopPrintServlet.java 20 Jun 2003 10:15:41 - 1.5 @@ -246,7 +246,7 @@ super(null); this.printerJob = printerJob; -startNumber = 0 ; +startNumber = 0; endNumber = -1; printerJob.setPageable(this); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/render/ps PSRenderer.java
pbwest 2003/06/20 03:21:50
Modified:src/java/org/apache/fop/render/ps PSRenderer.java
Log:
Static method accessed in static manner.
Spaces before ';' removed.
Array specifiers moved.
Revision ChangesPath
1.4 +6 -6 xml-fop/src/java/org/apache/fop/render/ps/PSRenderer.java
Index: PSRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/ps/PSRenderer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- PSRenderer.java 17 Apr 2003 15:35:20 - 1.3
+++ PSRenderer.java 20 Jun 2003 10:21:50 - 1.4
@@ -464,7 +464,7 @@
for (int i = 0; i text.length(); i++) {
final char c = text.charAt(i);
final char mapped = font.mapChar(c);
-gen.escapeChar(mapped, sb);
+PSGenerator.escapeChar(mapped, sb);
}
sb.append() t);
writeln(sb.toString());
@@ -642,7 +642,7 @@
saveGraphicsState();
// multiply with current CTM
//writeln(CTMHelper.toPDFString(ctm) + cm\n);
-final double matrix[] = ctm.toArray();
+final double[] matrix = ctm.toArray();
concatMatrix(matrix);
// Set clip?
@@ -753,7 +753,7 @@
//saveGraphicsState();
}
-float bwidth = bps.width ;
+float bwidth = bps.width;
updateColor(bps.color, false, null);
writeln(bwidth + setlinewidth);
@@ -770,7 +770,7 @@
//saveGraphicsState();
}
-float bwidth = bps.width ;
+float bwidth = bps.width;
updateColor(bps.color, false, null);
writeln(bwidth + setlinewidth);
@@ -788,7 +788,7 @@
//saveGraphicsState();
}
-float bwidth = bps.width ;
+float bwidth = bps.width;
updateColor(bps.color, false, null);
writeln(bwidth + setlinewidth);
@@ -806,7 +806,7 @@
//saveGraphicsState();
}
-float bwidth = bps.width ;
+float bwidth = bps.width;
updateColor(bps.color, false, null);
writeln(bwidth + setlinewidth);
drawLine(sx - bwidth / 2, starty, sx - bwidth / 2, endy);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java
pbwest 2003/06/20 03:25:32
Modified:src/java/org/apache/fop/apps CommandLineOptions.java
Log:
Array brackets moved
Revision ChangesPath
1.5 +1 -1 xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java
Index: CommandLineOptions.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CommandLineOptions.java 17 Jun 2003 16:35:57 - 1.4
+++ CommandLineOptions.java 20 Jun 2003 10:25:31 - 1.5
@@ -158,7 +158,7 @@
* if processing should stop
* @exception FOPException if there was an error in the format of the options
*/
-private boolean parseOptions(String args[]) throws FOPException {
+private boolean parseOptions(String[] args) throws FOPException {
for (int i = 0; i args.length; i++) {
if (args[i].equals(-d) || args[i].equals(--full-error-dump)) {
log = new ConsoleLogger(ConsoleLogger.LEVEL_DEBUG);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/apps LayoutHandler.java
pbwest 2003/06/20 03:28:08
Modified:src/java/org/apache/fop/apps LayoutHandler.java
Log:
Java style array brackets
Revision ChangesPath
1.5 +1 -1 xml-fop/src/java/org/apache/fop/apps/LayoutHandler.java
Index: LayoutHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/LayoutHandler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- LayoutHandler.java6 May 2003 07:46:04 - 1.4
+++ LayoutHandler.java20 Jun 2003 10:28:07 - 1.5
@@ -489,7 +489,7 @@
/**
* @see org.apache.fop.apps.StructureHandler#characters(char[], int, int)
*/
-public void characters(char data[], int start, int length) {
+public void characters(char[] data, int start, int length) {
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: xml-fop checkstyle1.3.0-head
Shouldn't that be Checkstyle 3.1.0? On 20.06.2003 09:41:58 pbwest wrote: pbwest 2003/06/20 00:41:58 Added: .checkstyle1.3.0-head Log: Plugin config for Checkstyle 1.3.0 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20879] - [PATCH] Leader is broken in PS Renderer
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=20879. 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=20879 [PATCH] Leader is broken in PS Renderer [EMAIL PROTECTED] changed: What|Removed |Added Summary|Leader is broken in PS |[PATCH] Leader is broken in |Renderer|PS Renderer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/pdf PDFT1Stream.java
jeremias2003/06/20 05:25:02 Modified:src/org/apache/fop/pdf Tag: fop-0_20_2-maintain PDFT1Stream.java Log: Fix length entry in for embedded Type1 font (leads to errors in PDF viewers other than Acrobat Reader) Revision ChangesPath No revision No revision 1.2.2.5 +2 -2 xml-fop/src/org/apache/fop/pdf/Attic/PDFT1Stream.java Index: PDFT1Stream.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/Attic/PDFT1Stream.java,v retrieving revision 1.2.2.4 retrieving revision 1.2.2.5 diff -u -r1.2.2.4 -r1.2.2.5 --- PDFT1Stream.java 25 Feb 2003 14:29:38 - 1.2.2.4 +++ PDFT1Stream.java 20 Jun 2003 12:25:02 - 1.2.2.5 @@ -73,7 +73,7 @@ int length = 0; String filterEntry = applyFilters(); String preData = this.number + + this.generation -+ obj\n /Length + pfb.getLength() + ++ obj\n /Length + getDataLength() + + filterEntry + /Length1 + pfb.getLength1() + /Length2 + pfb.getLength2() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop CHANGES
jeremias2003/06/20 05:26:40 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Fix length entry in for embedded Type1 font (leads to errors in PDF viewers other than Acrobat Reader) Revision ChangesPath No revision No revision 1.10.2.63 +1 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.62 retrieving revision 1.10.2.63 diff -u -r1.10.2.62 -r1.10.2.63 --- CHANGES 6 Jun 2003 08:24:52 - 1.10.2.62 +++ CHANGES 20 Jun 2003 12:26:40 - 1.10.2.63 @@ -1,5 +1,6 @@ == Done since 0.20.4 release +- Fix for bug: Wrong length value for embedded Type1 font stream (JM) - Fix for bug #20506 (grayscale images in PS renderer) (JM) Submitted by: Zhong(George) Yi [EMAIL PROTECTED] - Fix for bad font encodings in the PS renderer (Fonts get reencoded as - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20950] New: - Wrong link generation in PDF renderer
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=20950. 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=20950 Wrong link generation in PDF renderer Summary: Wrong link generation in PDF renderer Product: Fop Version: 0.20.5 Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use fo structs as following below to descibe articels of an hypertext glossar. The glossar entries are linked with fo:basic-link. The resulting PDF-File is 3.5 MB huge and has thousands of links. But unfortunately some of them are wrong in the PDF while the fo-syntax seems to be correct. There are no error messages during generation. When you analyse the PDF-file with Acrobat there seem to be two types of linking errors. Type 1) The word where the link should be on is marked blue but the link rectangle is placed on a different location. May be this has to do with the keep-with-next=always. I think this because when there are a view links in one block the rectangles have all the same offset (all on the page before but the word are on the next page). Type 2) The rectangle of the link is in place over the blue marked word but the link has no target. I can provide the source code of the glossar to reproduce it but I can't publish it to public. So please contact me per email to get it. fo:table table-layout=fixed width=100% fo:table-column column-width=proportional-column-width(1)/ fo:table-bodyfo:table-row keep-with-next=always fo:table-cell fo:block id = ipcp font-size=12pt font-weight=bold space-before.optimum=12pt space-after.optimum=6pt IPCP /fo:block fo:blockfo:marker marker-class-name=tIPCP/fo:marker/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell fo:block space-after.optimum=6pt/fo:block fo:blockInternet Protocol Control Protocol#160;/fo:block fo:block space-after.optimum=6pt/fo:block fo:blockfo:basic-link color=blue internal-destination=ncpNetwork Control Protocol/fo:basic-link f#252;r fo:basic-link color=blue internal-destination=tcp_ipIP/fo:basic-link-Verbindungen #252;ber fo:basic-link color=blue internal-destination=pppPPP/fo:basic-link.#160;Definiert im fo:basic-link color=blue internal-destination=rfcRFC/fo:basic-link 1332.#160;/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/ps PSRenderer.java
jeremias2003/06/20 06:34:48
Modified:src/org/apache/fop/render/ps Tag: fop-0_20_2-maintain
PSRenderer.java
Log:
Fix for bug #20879 (leader broken, missing moveToCurrPosition)
Submitted by: Larry Moore [EMAIL PROTECTED]
Fix for bug #5674 (High memory usage in PS interpreter, FOP
procs were started for every page but not ended after the page)
Proc begins moved to end of Setup, so they only get executed once.
Improved DSC-conformance in %%Page comments.
Revision ChangesPath
No revision
No revision
1.15.2.20 +6 -4 xml-fop/src/org/apache/fop/render/ps/Attic/PSRenderer.java
Index: PSRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/ps/Attic/PSRenderer.java,v
retrieving revision 1.15.2.19
retrieving revision 1.15.2.20
diff -u -r1.15.2.19 -r1.15.2.20
--- PSRenderer.java 6 Jun 2003 08:21:50 - 1.15.2.19
+++ PSRenderer.java 20 Jun 2003 13:34:48 - 1.15.2.20
@@ -874,6 +874,7 @@
int bl = this.currentYPosition;
// method is identical to super method except next line
+movetoCurrPosition();
String fontWeight = area.getFontState().getFontWeight();
//comment(% --- LineArea begin font-weight=+fontWeight);
@@ -898,7 +899,7 @@
this.pagecount++;
this.idReferences = page.getIDReferences();
-write(%%Page: + page.getNumber() + + page.getNumber());
+write(%%Page: + page.getNumber() + + this.pagecount);
final long pagewidth = page.getWidth();
final long pageheight = page.getHeight();
@@ -921,8 +922,6 @@
}
write(%%BeginPageSetup);
-write(FOPprocs begin);
-write(FOPFonts begin);
if (rotate) {
write(Math.round(pspageheight) + 0 translate);
write(90 rotate);
@@ -1168,6 +1167,9 @@
write(b4_Inc_state restore);
write(} bind def);
write(%%EndResource);
+
+write(FOPprocs begin);
+write(FOPFonts begin);
write(%%EndSetup);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop CHANGES
jeremias2003/06/20 06:39:43 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Update changes Revision ChangesPath No revision No revision 1.10.2.64 +5 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.63 retrieving revision 1.10.2.64 diff -u -r1.10.2.63 -r1.10.2.64 --- CHANGES 20 Jun 2003 12:26:40 - 1.10.2.63 +++ CHANGES 20 Jun 2003 13:39:42 - 1.10.2.64 @@ -1,5 +1,10 @@ == Done since 0.20.4 release +- PS Renderer: Improved DSC-conformance in %%Page comments. +- Fix for bug #20879 (PS Renderer: leader broken, cursor positioning) (JM) + Submitted by: Larry Moore [EMAIL PROTECTED] +- Fix for bug #5674 (PS Renderer: High memory usage in PS interpreter, FOP + procs were started for every page but not ended after the page) (JM) - Fix for bug: Wrong length value for embedded Type1 font stream (JM) - Fix for bug #20506 (grayscale images in PS renderer) (JM) Submitted by: Zhong(George) Yi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5674] - postscript generated by FOP is missing end commands
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=5674. 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=5674 postscript generated by FOP is missing end commands [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:44 --- Fixed in CVS. I've fixed it in another way than you suggested. I moved the proc begins to the end of the Setup section so they are only executed once. Please reopen the entry here if it didn't work for you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20879] - [PATCH] Leader is broken in PS Renderer
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=20879. 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=20879 [PATCH] Leader is broken in PS Renderer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:44 --- Fixed in CVS. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/rtflib - New directory
bdelacretaz2003/06/20 08:54:44 xml-fop/src/java/org/apache/fop/rtf/rtflib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop build.xml
bdelacretaz2003/06/20 08:56:51
Modified:.build.xml
Log:
rtflib package is not compilable yet
Revision ChangesPath
1.82 +10 -0 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- build.xml 27 Apr 2003 18:19:48 - 1.81
+++ build.xml 20 Jun 2003 15:56:51 - 1.82
@@ -118,6 +118,12 @@
exclude name=org/apache/fop/pdf/PDFEncryptionJCE.java unless=jce.present/
/patternset
+ !-- jfor RTF library has been moved here but needs tweaking before it compiles
--
+ !-- remove this once the RTF library compiles --
+ patternset id=exclude-rtflib
+exclude name=org/apache/fop/rtf/rtflib/**/*.java/
+ /patternset
+
patternset id=base-sources
include name=**/*.java/
exclude name=**/*${ignore_this}/
@@ -432,6 +438,10 @@
patternset refid=exclude-jce-dependencies/
patternset refid=exclude-jai/
patternset refid=exclude-jimi/
+
+ !-- remove this once the RTF library compiles --
+ patternset refid=exclude-rtflib/
+
classpath refid=libs-build-classpath/
patternset refid=base-sources/
/javac
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/rtflib/exceptions - New directory
bdelacretaz2003/06/20 09:03:54 xml-fop/src/java/org/apache/fop/rtf/rtflib/exceptions - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc - New directory
bdelacretaz2003/06/20 09:04:04 xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/rtflib/testdocs - New directory
bdelacretaz2003/06/20 09:04:12 xml-fop/src/java/org/apache/fop/rtf/rtflib/testdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Hi Victor, I have committed the classes from the jfor RTF library under org.apache.fop.rtf.rtflib. They don't compile out of the box, so I disabled their compilation in build.xml for now, didn't have time to look further. The next step would be to get them to compile, have the RTFHandler use them and remove jfor.jar from the lib directory. You will probably find dependencies to other parts of jfor, let me know if you need more classes (but hopefully most of those dependencies are not needed). ...I don't want to mislead anyone into thinking I'm making a big commitment here -- it will probably be a little here and a little there... fine - we'll see what happens! ...Java source is Unicode, and I don't think the encoding would matter, but UTF-8 makes the most sense as most of the source is ASCII. And it could be that most tools don't care, but I know that JBuilder does... yes, idea for example uses a configurable file encoding. ...if there is some doc on the RTF libs, there is none ATM. ...t seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much. Feel free to ask if you have questions. There is also the testdocs package some parts of the RTF library. Does it make sense in the long run for the jfor libs to be a separate project? It seems like it should have wider appeal than just for FOP, although FOP is probably a good home for it for now. I think FOP is a good start. It would be easy to create a separate rtflib.jar if needed. By creating another project we would lose the FOP community, it is certainly better at this point to strengthen it by adding new features to FOP. What's sorely missing IMHO is a way to validate the generated RTF other than by crashing word processors. If you hear about an RTF validator or an RTF parser grammar it would be a welcome improvement. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RTF] Jfor integration
Bertrand Delacretaz wrote: I have committed the classes from the jfor RTF library under org.apache.fop.rtf.rtflib. Thanks. They don't compile out of the box, so I disabled their compilation in build.xml for now, didn't have time to look further. The next step would be to get them to compile, have the RTFHandler use them and remove jfor.jar from the lib directory. Sounds right. I'll work on that. ...if there is some doc on the RTF libs, there is none ATM. I will probably try to create some as I go. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Team page
On 6/2/2003 3:21 PM, Victor Mote wrote: Jeremias Maerki wrote: That'll go away next time the site is updated. See my change: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/conten t/xdocs/team.xml.diff?r1=1.5r2=1.6diff_format=h The mailto prefixes were missing and Forrest/Cocoon thought they were HTML pages. Oops. Thanks for fixing. Victor Mote I was going to ask (nag? -- btw, you don't need to add nag to my bio ;-p) about updates to the Team page. Then I noticed that nothing has been done to the Team Page since you added my and Glen's e-mail address (naginsert nagging comments to the following 'slackers' who haven't updated their Team Bio yet: Bertrand Delacrétaz, Christian Geisert, Karen Lease, Keiron Liddle, Jörg Pietschmann, Arved Sandstrom, Oleg Tkachenko, Peter B. West, Marcelo Jaccoud Amaral, Rhett Aultman, Glen Mazza, Anton Tagunov, Zhong (George) Yi/nag). I don't really care so much about my bio, but my guess is that Glen would like to have his e-mail address changed soon...(no really! I don't care! ;-p) http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/content/xdocs/team.xml ;-p -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Team page
Clay Leeds wrote: I was going to ask (nag? -- btw, you don't need to add nag to my bio ;-p) about updates to the Team page. Then I noticed that nothing has been done to the Team Page since you added my and Glen's e-mail address Sorry. I just took a look at the forrestbot log there are a handful of minor errors I need to fix before I should publish. I'll try to get that done tonight or tomorrow. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
--- Victor Mote [EMAIL PROTECTED] wrote: AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. Also, while currently it is true that the AreaTree creation is somewhat bound to the FOTree creation, that is one of the things that I think we are trying to change (I am anyway). currently it's: FOP - Driver --- FOTreeBuilder | | | | | | \/ | Structure Handler --- As in (1) FOP class determines if the render_type requires an area tree. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps FOTreeBuilder -- its Area Tree The only reason that I know of for the processing to be the way it is now is to facilitate eager processing. If we return control of that up to these Control/API classes, we get a clean separation of these tasks, add the option for patient processing as well, and add the possibility of pluggable layout. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 20:58:58 Glen Mazza wrote: --- Victor Mote [EMAIL PROTECTED] wrote: AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. Today, that is so. My idea is to move the font registry out of the renderers in to a font subsystem with multiple font sources. The involved renderers can be asked what font sources they support and so the available set of fonts will be restricted. We've talked about the difficulties of supporting multiple renderers in one processor run before (see archives). Making the font subsystem standalone would make it possible to use the same area tree for the PDF and PS renderers and also make the AT independant of the renderer (I think). Also, while currently it is true that the AreaTree creation is somewhat bound to the FOTree creation, that is one of the things that I think we are trying to change (I am anyway). currently it's: FOP - Driver --- FOTreeBuilder | | | | | | \/ | Structure Handler --- I think now it's: Driver--FOTreeBuilder--FOTree--StructureHandler LayoutEngine--AreaTree--Renderer As in (1) FOP class determines if the render_type requires an area tree. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. It's not directly SAX events but something similar. I wanted to move to: (1) Doc/Dri API/Apps FOTreeBuilder -- its Area Tree But then, where's the StructureHandler (output to MIF and RTF)? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Previous email was sent before I was done red face/, please ignore for this one: --- Victor Mote [EMAIL PROTECTED] wrote: AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. Also, while currently it is true that the AreaTree creation is somewhat bound to the FOTree creation, that is one of the things that I think we are trying to change (I am anyway). currently it's: FOP - Driver --- FOTreeBuilder | | | | | | | | | \/ | | AWT/Print\/ | Starter Structure Handler As in (1) FOP class determines if the render_type requires an area tree, if so goes to App.Driver, else App.AWT/Print Starter. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps FOTreeBuilder -- its Area Tree (1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo and the render_type, calls Run() (2) Based on the render_type FOTreeBuilder either creates an area tree of its choosing, or doesn't (AWT/Print). If it does, it determines *which* type of area tree to create (Structure or MIF or the other one)--based again on the render_type. The business logic for this would be in FOTreeBuilder. Regardless of area tree decision, it is responsible for generating the report via its Run() function. I.e., the area tree may just be a local variable of its run() rather than its current status as a member variable. Your idea is (non-graphical, I'm getting tired ;): document class foTree = foTreeBuilder.createFOTree(); areaTree = areaTree.createAreaTree(foTree); You are correct--this is *very* elegant--problem is, from Keiron's writing, we just can't separate the FOTree from the area tree because of an unacceptable performance hit. See: http://marc.theaimsgroup.com/?l=fop-devm=105270887501490w=2 [EMAIL PROTECTED] FOTree needs to encapsulate the AreaTree, I thought the next best solution would be to divorce your document from knowledge of the AreaTree, rather than have both classes point to it. Here's food for thought--if we rename FOTreeBuilder to XSLFOProcessor, perhaps you would have less concerns about feeding it the render type. We can make this centrally-located class the octopus of the application, rather than the left-side Document/API/APPs class. If we return control of that up to these Control/API classes, we get a clean separation of these tasks, add the option for patient processing as well, and add the possibility of pluggable layout. I agree--splitting the business logic between multiple classes tends to create spaghetti code. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:23:50 Glen Mazza wrote: (1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo and the render_type, calls Run() (2) Based on the render_type FOTreeBuilder either creates an area tree of its choosing, or doesn't (AWT/Print). Even with AWT/Print an Area Tree is generated. If it does, it determines *which* type of area tree to create (Structure or MIF or the other one)--based again on the render_type. The business logic for this would be in FOTreeBuilder. But no area tree is generated when a StructureHandler (RTF/MIF) is active. Regardless of area tree decision, it is responsible for generating the report via its Run() function. I.e., the area tree may just be a local variable of its run() rather than its current status as a member variable. Your idea is (non-graphical, I'm getting tired ;): document class foTree = foTreeBuilder.createFOTree(); areaTree = areaTree.createAreaTree(foTree); You are correct--this is *very* elegant--problem is, from Keiron's writing, we just can't separate the FOTree from the area tree because of an unacceptable performance hit. It doesn't need to be separated. But the building (!) of the FO tree is separated from other code like layout or RTF generation. See: http://marc.theaimsgroup.com/?l=fop-devm=105270887501490w=2 [EMAIL PROTECTED] FOTree needs to encapsulate the AreaTree, I thought the next best solution would be to divorce your document from knowledge of the AreaTree, rather than have both classes point to it. Here's food for thought--if we rename FOTreeBuilder to XSLFOProcessor, perhaps you would have less concerns about feeding it the render type. We can make this centrally-located class the octopus of the application, rather than the left-side Document/API/APPs class. YOU GET IT! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: I don't understand. The setOutputType() would be in the RenderType class, which is one of the four classes that Driver would be split into. So there might also be, for example, a setEncryptionKey() method to handle this. The whole point of creating the three extra classes is to make the granularity fine enough to properly control this kind of stuff. I'm sorry if I have missed your point. Could you outline your API ideas on the Wiki? I think we are in agreement here, except that it looks like you are thinking single Document, and I have added a mechanism (the Document class) that will allow multiple Documents to be queued up and/or multithreaded. I think processing multiple documents is a layer above processing a single source document. I assume you are talking about trunk here. If so, my reasoning for trying to get API resolved (or really Control, from my perspective) is so that I can continue with getting the layout cleanly separated and pluggable, Not a chance, pal. The interface between layout and rendering is much too complex, for example it includes the whole area tree mess. If it would be possible to plug the old layout into it, I would have done this a long time ago (rather: backporting the renderers to the maintenance branch). Don't forget that SVG plays a role too, and you can't have this feature broken because it's almost the only advantage we have over other FO processors now. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Glen Mazza wrote: foTree = foTreeBuilder.createFOTree(); areaTree = areaTree.createAreaTree(foTree); Check old FOP versions, like 0.19 or so... You are correct--this is *very* elegant--problem is, from Keiron's writing, we just can't separate the FOTree from the area tree because of an unacceptable performance hit. Memory problems, not performance in general. The area tree is usually *huge*. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:34:28 J.Pietschmann wrote: Could you outline your API ideas on the Wiki? Yes, please. I'm also in the process of writing down my ideas. That way it will be much easier to relate everyone's ideas to each other. At the moment I wish we could all sit together and figure it out by talking together and painting on a whiteboard. The Wiki will have to suffice I guess. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:38:02 Glen Mazza wrote: This seems to be another layer of indirection--quite useful still--but might the area tree *still* be renderer-dependent? (The involved renderers can be asked--It still has to know which renderers to ask, right? It may very well get different answers and work differently per renderer then.) If the Area Tree wants to know if Tribune New Roman is supported and PDF renderer says yes while PS says no, the area tree generated would be different for both, I think. Right in general. I think this cannot be as detailed as individual fonts. It should be like that: Renderer, do you support font sources X and Y? Font Source X could be a service providing PostScript Type1 fonts, Font Source Y could be a service providing fonts available to AWT. The whole thing will have to happen before processing starts because different Area Trees have to be generated if the requested set of renderers don't support the same font sources (AWT against PDF, for example). The problem is, as we already gathered in the earlier discussion, that I guess you wouldn't want to simply let FOP generate two different (!!!pagination!!!) ATs. You will get two different documents. But the main use case for multiple renderers is to have one doc for printing and one for the archive. And in this aspect, different output is not acceptable. Therefore and IMO, multiple output formats in the same processor run is not worth the pain. But the above concept is still worthwhile. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Even with AWT/Print an Area Tree is generated. But no area tree is generated when a StructureHandler (RTF/MIF) is active. Yes, I got confused between the two sets of weird render types: those that handle their processing with their own starters (which I would like to push past FOTreeBuilder/XSLFOProcessor, and have the latter class handle as well) and those that don't need an area tree because of no page numbering, etc. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop checkstyle1.3.0-head
Oops! Oh well, it can now be updated to 3.1.1, which has just been released. Back to the downloads. Peter Jeremias Maerki wrote: Shouldn't that be Checkstyle 3.1.0? On 20.06.2003 09:41:58 pbwest wrote: pbwest 2003/06/20 00:41:58 Added: .checkstyle1.3.0-head Log: Plugin config for Checkstyle 1.3.0 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
