RE: i18n in TXTRenderer
Yes. I looked a bit at the renderers in the main branch and it looks like
they have been gutted. Seeing this I am a bit concerned that it may be
longer than I thought before the redesigned FOP is functional. But I did not
look at very many things, so maybe it is what I happened to look at. I also
do not recall seeing many commit messages for a while, so maybe someone has
all kinds of cool stuff that they are working on locally.
Art
-Original Message-
From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 5:48 PM
To: [EMAIL PROTECTED]
Subject: 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: [EMAI
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
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 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
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]
>
>
patch.tar.gz
Description: Binary data
-
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]
