Re: New branch ready for review.

[John Darrington]

     As I read "Recode strings when writing system files." it occurred
     to me that a sensible way to deal with recoding on system file
     read and write would be to write a dict_recode function that both
     sys-file-reader and sys-file-writer could use.  Then neither file
     would have to worry about recoding much; they could just call
     this function.  Does that make sense?


sys-file-writer converts all its strings as they are written. Whereas
sys-file-reader reads its strings and then converts them in a post
processing function.  I'd really like to avoid the post-processing,
but unfortuately that's not possible, because (typically) the encoding
isn't known until after all the strings have been read.

     At a high level, it bothers me how much allocation and
     deallocation and copying this adds to simple operations.
     I guess that it's probably not worth worrying about without
     profiler output showing that it's significant, though.

The use of data_out_pool mitigates this problem to some extent;
and in many cases, although an extra memcpy is introduced inside
data_out, one is avoided immediately afterwards.  I can see a few
more opportunities for optimization, but these would come at the 
expense of adding extra arguments to  data_in/out, makeing everything
less readable.

Anyway,  I've attended to all of the issues execept the one above,
and  merged with master.
     
As an experiment, I also merged with the output branch (but I didn't commit), 
and confirmed
that strings originating from system  files with non UTF8 encoding,
are displayed properly in the cairo output, which was the primary 
motivation for this exercise.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature