RE: i18n in TXTRenderer

[Art Welch <ar...@EASTPOINT.COM>]

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:Arved_37@chebucto.ns.ca]
Sent: Thursday, January 31, 2002 5:48 PM
To: fop-dev@xml.apache.org
Subject: RE: i18n in TXTRenderer


I think everything like this, maintenance branch.

Arved

-----Original Message-----
From: Art Welch [mailto:art_w@EASTPOINT.COM]
Sent: January 31, 2002 1:06 PM
To: 'fop-dev@xml.apache.org'
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:ishigami@victokai.co.jp]
Sent: Wednesday, January 30, 2002 8:36 PM
To: fop-dev@xml.apache.org
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:ishigami@victokai.co.jp]
> Sent: Sunday, January 27, 2002 6:35 PM
> To: fop-dev@xml.apache.org
> 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: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org