finishing output translating stream Shiro Kawai (25 May 2005 00:05 UTC)
Re: finishing output translating stream Michael Sperber (06 Jun 2005 15:15 UTC)
Re: finishing output translating stream Shiro Kawai (07 Jun 2005 10:41 UTC)
Re: finishing output translating stream bear (07 Jun 2005 16:12 UTC)
Re: finishing output translating stream Michael Sperber (08 Jun 2005 07:19 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 07:37 UTC)
Re: finishing output translating stream Michael Sperber (08 Jun 2005 07:52 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 09:08 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 09:10 UTC)
Re: finishing output translating stream bear (08 Jun 2005 18:10 UTC)
Re: finishing output translating stream bear (09 Jun 2005 02:16 UTC)
Re: finishing output translating stream Michael Sperber (09 Jun 2005 05:51 UTC)
Re: finishing output translating stream Shiro Kawai (21 Jun 2005 00:00 UTC)
Re: finishing output translating stream Michael Sperber (22 Jun 2005 07:56 UTC)

Re: finishing output translating stream Michael Sperber 09 Jun 2005 05:51 UTC

Shiro Kawai <xxxxxx@lava.net> writes:

> If the translate-proc doesn't know about flush-output-stream,
> and a log message happen to end with a non-ascii character,
> it won't write out the closing escape sequence ESC '(' 'B'
> at the end of log message, for it doesn't know if more non-ascii
> character is coming or not.   If the application crashes then,
> the log file remains in the non-ascii state.  Subsequent run
> of the applicaion starts adding messages, assuming the file begins
> with ascii state---resulting that the first ascii portion of
> the new message becomes illegible.
>
> I admit this is just a bad design.  Still, the character encoding
> stuff is so complicated that I appreciate anything that adds
> more certainty and control.

OK, I think I understand now.  (Many thanks for all the explanation,
BTW---it's extremely helpful to me.)

Now, this flushing business makes me a little concerned: What you're
proposing means my output data is different depending on when I call
flush.  However, I always thought of this invariant as pretty
fundamental to what flush does---that it does not change the data.

It seems what you really should do to solve your problem is send a
message to the translator to insert the closing escape sequence into
the output stream, and have the *translator* flush after it has
encountered the message and written the closing sequence.  You could
just use U+0003 (END OF TEXT) or something for that purpose.  Would
this be reasonable?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla