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]
