Re: [PATCH] TXTRenderer output encoding
Oleg Tkachenko wrote: Well, encoding-related code looks fine for me, but I cannot build fop in cvs due to Hashtable/HashMap changes: Oops, didn't clean the build directory before the test build. It should be fixed now. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] TXTRenderer output encoding
Oleg Tkachenko wrote: As Torsten Straube pointed out that would be nice to have a possibility to set TXTRenderer output encoding. I like the idea and here is my proposed patch. Ok, commited to the maintenance branch. I added usage info and moved the check for a valid encoding somewhere else and provided a warning in case the encoding is invalid. PPlease test. I canät commit it to the head as the TXTRenderer seems to be in a major overhaul there. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] TXTRenderer output encoding
Hello!
As Torsten Straube pointed out that would be nice to have a possibility
to set TXTRenderer output encoding. I like the idea and here is my
proposed patch. I have added new TXTRenderer option txt.encoding,
which could be set either from command line:
fop.bat d:\table.fo -txt d:\table.txt -d -txt.encoding Windows-1251
or from java code using TXTRenderer's setOptions(Hashtable) method.
In the case of unsupported encoding TXTStream escapes back to UTF-8.
--
Oleg Tkachenko
Multiconn International, Israel
Index: fop-cvs/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.14.2.4
diff -u -r1.14.2.4 CommandLineOptions.java
--- fop-cvs/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java 6 Jul 2002
16:43:45 - 1.14.2.4
+++ fop-cvs/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java 13 Jul 2002
+20:36:29 -
@@ -16,6 +16,7 @@
import org.apache.fop.configuration.Configuration;
import org.apache.fop.apps.FOPException;
import org.apache.fop.messaging.MessageHandler;
+import org.apache.fop.render.txt.TXTRenderer;
// Avalon
import org.apache.avalon.framework.logger.ConsoleLogger;
@@ -252,6 +253,14 @@
outfile = new File(args[i + 1]);
i++;
}
+ } else if (args[i].equals(- + TXTRenderer.encodingOptionName)) {
+if ((i + 1 == args.length)
+|| (args[i + 1].charAt(0) == '-')) {
+throw new FOPException(you must specify text renderer encoding);
+} else {
+rendererOptions.put(TXTRenderer.encodingOptionName, args[i + 1]);
+i++;
+}
} else {
printUsage();
return false;
@@ -587,6 +596,8 @@
case TXT_OUTPUT:
log.debug(txt);
log.debug(output file: + outfile.toString());
+if (rendererOptions.containsKey(TXTRenderer.encodingOptionName))
+log.debug(output encoding: +
+rendererOptions.get(TXTRenderer.encodingOptionName));
break;
case SVG_OUTPUT:
log.debug(svg);
Index: fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTRenderer.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/txt/TXTRenderer.java,v
retrieving revision 1.12.2.2
diff -u -r1.12.2.2 TXTRenderer.java
--- fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTRenderer.java 23 Apr 2002
22:33:40 - 1.12.2.2
+++ fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTRenderer.java 13 Jul 2002
+20:36:41 -
@@ -46,6 +46,7 @@
* the current stream to add Text commands to
*/
TXTStream currentStream;
+public static final String encodingOptionName = txt.encoding;
private int pageHeight = 7920;
@@ -1605,8 +1606,6 @@
if (debug)
System.out.println(TXTRenderer.renderPage() page.getHeight() =
+ page.getHeight());
-BodyAreaContainer body;
-AreaContainer before, after, start, end;
maxX = (int)(textCPI * page.getWidth() / 72000 + 1);
maxY = (int)(textLPI * page.getHeight() / 72000 + 1);
@@ -1626,29 +1625,11 @@
+ yFactor= + yFactor + paperHeight=
+ pageHeight);
-body = page.getBody();
-before = page.getBefore();
-after = page.getAfter();
-start = page.getStart();
-end = page.getEnd();
-
this.currentFontName = ;
this.currentFontSize = 0;
// currentStream.add(BT\n);
-renderBodyAreaContainer(body);
-
-if (before != null)
-renderAreaContainer(before);
-
-if (after != null)
-renderAreaContainer(after);
-
-if (start != null)
-renderAreaContainer(start);
-
-if (end != null)
-renderAreaContainer(end);
+renderRegions(page);
// Write out the buffers.
for (int row = 0; row = maxY; row++) {
@@ -1719,6 +1700,7 @@
throws IOException {
log.info(rendering areas to TEXT);
currentStream = new TXTStream(outputStream);
+currentStream.setEncoding((String)options.get(encodingOptionName));
firstPage=true;
}
Index: fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTStream.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/txt/TXTStream.java,v
retrieving revision 1.1
diff -u -r1.1 TXTStream.java
--- fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTStream.java31 Jan 2002
18:14:42 - 1.1
+++ fop-cvs/xml-fop/src/org/apache/fop/render/txt/TXTStream.java
Character Encoding in TXTRenderer
Hi all.
I am using fop-0.20.4 to create PDF and text files from
XML files encoded in ISO-8859-1.
While the PDF files are ok, the text files are always UTF-8 encoded.
By looking at the TXTRenderers sources I found the reason for this
behaviour:
The TXTRenderer uses the TXTStream class to write to an OutputStram
and this TXTStream assumes a UTF-8 encoding:
public void add(String str) {
if (!doOutput)
return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
I don't want to simply change this to another fixed encoding,
even though I always - at least thats what I know now - will
use this encoding.
My FO files always contain an encoding attribute in the XML declaration
so I thought the ContentHandler might instruct the renderer which encoding
to use but the SAXContentHandler does not get this information.
I would like to fix this, but I am not sure how to do it.
Is there any preferable way to tell the renderer which encoding to use?
thanks
Torsten
--
_
Torsten Straube * picturesafe media/data/bank GmbH
Lüerstr. 3 * D-30175 Hannover * phone: 0511/85620-53
fax: 0511/85620-10 * mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
FOP TXTRenderer example?
I have been trying to get the FOP TXTRenderer working to produce some simple ASCII reports but have been singularily unable to get any kind of decent result. I am trying to use FOP TXTRenderer (as opposed to just XSLT text output) because I have to wrap some relatively long descriptions and I have to right justify some columns. I have not been able to find much help in doing either from within XSLT. I get results (fop is working fine) but no matter how I vary the parameters I always get lots of extra whitespace between the words. Is there some reasonable set of font, margins, etc. that will produce a more-or-less non-justified plain text paragraph? Does anyone have any simple examples? = ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=only page-height=99in page-width=8.5in margin-top=0in margin-bottom=0in margin-left=0in margin-right=0in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=only fo:flow flow-name=xsl-region-body fo:block font-size=10pt font-family=Courier text-align=start white-space-collapse=false !-- space-treatment=ignore not implimented yet -- This is my block of text that goes accross multiple lines, etc. /fo:block /fo:flow /fo:page-sequence /fo:root = This is my block of text that goes accrossmultiplelines, etc. = Thank R.Parr Temporal Arts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
I will try to commit this sometime in the next few days.
I have not looked at the code yet, should this be the main branch or the
maintenance branch?
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 8:36 PM
To: [EMAIL PROTECTED]
Subject: Re: i18n in TXTRenderer
Hi, Art.
I attach the most simplest changes to this mail.
I created a new org.apache.fop.render.txt.TXTStream class and
modified the TXTRenderer class.
A difference of behavior with an existing code is that a
generated text is written by UTF-8 encoding (not ISO-8859-1).
It maybe more better that users can specify a charset encoding
at anywhere. However I also think that most users will not need
a function more than current TXTRenderer. So I think that this
changes are enough to view the text.
By the way, a generated text is very dirty :)
---
Satoshi Ishigami VIC TOKAI CORPORATION
On Mon, 28 Jan 2002 12:01:54 -0500 , Art Welch wrote:
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would
handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components)
to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
I have added this to fop-0_20_2-maintain. Looks things are a bit different
in the main branch. Without doing a bit of research, I do not see at the
moment how that works. Of course it is possible that at the moment, it does
not work.
Art
-Original Message-
From: Art Welch
Sent: Thursday, January 31, 2002 12:06 PM
To: '[EMAIL PROTECTED]'
Subject: RE: i18n in TXTRenderer
I will try to commit this sometime in the next few days.
I have not looked at the code yet, should this be the main branch or the
maintenance branch?
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 8:36 PM
To: [EMAIL PROTECTED]
Subject: Re: i18n in TXTRenderer
Hi, Art.
I attach the most simplest changes to this mail.
I created a new org.apache.fop.render.txt.TXTStream class and
modified the TXTRenderer class.
A difference of behavior with an existing code is that a
generated text is written by UTF-8 encoding (not ISO-8859-1).
It maybe more better that users can specify a charset encoding
at anywhere. However I also think that most users will not need
a function more than current TXTRenderer. So I think that this
changes are enough to view the text.
By the way, a generated text is very dirty :)
---
Satoshi Ishigami VIC TOKAI CORPORATION
On Mon, 28 Jan 2002 12:01:54 -0500 , Art Welch wrote:
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would
handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components)
to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
I think everything like this, maintenance branch.
Arved
-Original Message-
From: Art Welch [mailto:[EMAIL PROTECTED]]
Sent: January 31, 2002 1:06 PM
To: '[EMAIL PROTECTED]'
Subject: RE: i18n in TXTRenderer
I will try to commit this sometime in the next few days.
I have not looked at the code yet, should this be the main branch or the
maintenance branch?
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 8:36 PM
To: [EMAIL PROTECTED]
Subject: Re: i18n in TXTRenderer
Hi, Art.
I attach the most simplest changes to this mail.
I created a new org.apache.fop.render.txt.TXTStream class and
modified the TXTRenderer class.
A difference of behavior with an existing code is that a
generated text is written by UTF-8 encoding (not ISO-8859-1).
It maybe more better that users can specify a charset encoding
at anywhere. However I also think that most users will not need
a function more than current TXTRenderer. So I think that this
changes are enough to view the text.
By the way, a generated text is very dirty :)
---
Satoshi Ishigami VIC TOKAI CORPORATION
On Mon, 28 Jan 2002 12:01:54 -0500 , Art Welch wrote:
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would
handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components)
to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components) to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: TXTRenderer
Brian: We just started using it. Although it is a bit _ugly_ and the letter spacing is a bit off, our pages are OK. As we get more into TXT output, I'll let you know if I we see this. -Lou Brian T. Wolf [EMAIL PROTECTED] on 10/11/2001 07:51:49 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: TXTRenderer Is anyone else using the TXTRenderer? It seems that when I try it my pages all appear twice as wide as they are supposed to and the letter spacing is all funky. Is that already documented? If not, does anyone have any workarounds or ways to fix this? Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TXTRenderer
You didn't provide many other details, so if assuming your using a stylesheet of some kind, have you tried xsl:stylesheet xsl:output method="text" indent="yes[or no]"/ ...the rest of the stylsheet... /xsl:stylesheet? You'd have more control over the output. Hope this helps, Matthew L. AvizinisGleim Publications, Inc.4201 NW 95th Blvd.Gainesville, FL 32606(352)-375-0772 ext. 101www.gleim.com -Original Message-From: Brian T. Wolf [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 11, 2001 7:52 PMTo: [EMAIL PROTECTED]Subject: TXTRenderer Is anyone else using the TXTRenderer? It seems that when I try it my pages all appear twice as wide as they are supposed to and the letter spacing is all funky. Is that already documented? If not, does anyone have any workarounds or ways to fix this? Thanks, Brian
RE: TXTRenderer
What I meant was have you tried the following in place of using the fop text renderer option. If text output is what you want, then you really wouldn't need fop at all; your XSLT engine would produce the output you want. You didn't provide many other details, so if assuming your using a stylesheet of some kind, have you tried xsl:stylesheet xsl:output method="text" indent="yes[or no]"/ ...the rest of the stylsheet... /xsl:stylesheet? You'd have more control over the output. Hope this helps, Matthew L. AvizinisGleim Publications, Inc.4201 NW 95th Blvd.Gainesville, FL 32606(352)-375-0772 ext. 101www.gleim.com -Original Message-From: Brian T. Wolf [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 11, 2001 7:52 PMTo: [EMAIL PROTECTED]Subject: TXTRenderer Is anyone else using the TXTRenderer? It seems that when I try it my pages all appear twice as wide as they are supposed to and the letter spacing is all funky. Is that already documented? If not, does anyone have any workarounds or ways to fix this? Thanks, Brian
TXTRenderer
Is anyone else using the TXTRenderer? It seems that when I try it my pages all appear twice as wide as they are supposed to and the letter spacing is all funky. Is that already documented? If not, does anyone have any workarounds or ways to fix this? Thanks, Brian
