[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: finishing output translating stream
Shiro Kawai <shiro@xxxxxxxx> 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