Re: Problem: incompatible handling of svg files

[Ethan M. <merritt@u.washington.edu>]

On Monday 16 October 2006 02:49 pm, Ethan Merritt wrote:
> Petr Mikulik wrote>
> >
> > Without Hans-Bernhard's patch, SVG output is correct for both UTF-8
> > and 8859-2. I propose to remove this patch (and don't do &#nnnn; et
> > all).
>
> That works for me, after some struggles to change the default font
> paths.  But I think we need to know more about what exactly was the
> problem that Hans-Bernhard's patch was originally trying to fix.

In order to facilitate testing of various combinations of character
escaping and svg viewers, I have posted two variants of the svg.trm
driver to SourceForge. (These are complete files, not patches).

Both add a new terminal option
	set term svg {raw|escaped}

Variant 1 treats all encodings the same: if the "escaped" option
is selected, then non-ascii character are replaced one byte at a
time by the corresponding sequence &#xNN;

Variant 2 behaves exactly the same if an explicit encoding is set.
However, if no encoding is set then it is assumed to be UTF-8.
In this case non-ascii sequences are re-encoded by conversion from
UTF-8 to Unicode code points, rather than byte-by-byte.

Yes, we should probably have a specific S_ENC_UTF8 that can be
selected by "set encoding utf8".  But we can deal with that as a
separate issue if it turns out that we need the UTF-8 specific
code.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA