Re: Problem: incompatible handling of svg files

[Petr M. <mi...@ph...>]

>> I've just tried after your latest patch, it works with UTF-8 and 'set
>> enco default', but not for latin2. Try this:
>>
>> Write b.gp in UTF-8:
>>
>> set encoding iso_8859_2
>> set term svg
>> set out 'b.svg'
>> set title "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> set xlabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> set ylabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> plot x
>>
>> recode utf8..latin2 b.gp
>> gnuplot b.gp
>>
>>
>> =3D> the file is rendered incorrectly; the text appears as:
>>
>> <text>P&#xf8;&#xed;li&#xb9; &#xbe;lu&#xbb;ou&#xe8;k&#xfd;
>> k&#xf9;&#xf2; &#xfa;p&#xec;l &#xef;&#xe1;belsk&#xe9; &#xf3;dy.</text>
>
> But that is what it was doing already, *before* my utf-8 patch.

Thus, it looks to me a "feature" of svg -- the following

 =09<?xml version=3D"1.0" encoding=3D"iso-8859-2"  standalone=3D"no"?>
 =09...
 =09<text>--=F8-- --&#xf8;--</text>

does not print =F8 twice even though F8 is its code in iso-8859-2. Cannot i=
t=20
be that &#nnnn; are always interpreted as UTF-8 chars, whatever header says=
?

In that case, in non-"set encoding default", gnuplot cannot do=20
transformation of 8bit chars into hex string, as the string will get all=20
wrong! (All =3D=3D without iso latin 1, which is a subset of utf-8, by desi=
gn.)

> The change to write non-ascii characters in the form &#xbb;
> was due to this patch:
>
> 2006-10-03  Hans-Bernhard Broeker  <br...@ph...>
>
>        * term/svg.trm: Change sprintf() and fprintf() to strcpy and
>        fputs, all over the place.
>        (SVG_put_text): Fix handling of XML reserved characters in
>        non-enhanced text output.
>
> That patch broke things for me, also, which is what started me
> on the path to reworking the code so that at least it works in
> my utf-8 environment.
>
> So I think we have a problem here.
> Apparently Hans-Bernhard's svg viewer does not like the inline
> non-ascii characters, whereas your viewers and mine require them
> in order to process the encoding correctly.

Yes, then it is a bug of that particular svg viewer.

Without Hans-Bernhard's patch, SVG output is correct for both UTF-8 and=20
8859-2. I propose to remove this patch (and don't do &#nnnn; et all).

---
PM