SVG terminal incorrectly leading text
Grant Edwards
4.2), the leading of text seems to be incorrect when viewed in
Opera or Firefox. If you use a smaller than default fontsize,
multiline labels start to overlap themselves. The x axis tick
labes also start to overlap with the x axis.
Here's an example:
set out "bug.svg"
set term svg size 800,600 fsize 5
set label "this shows\nhow a\multiline label\nis incorrectly\nleaded" at 4,0.5
set title "Demo of SVG fontsize bug"
plot sin(x)
set out
http://grante.homeip.net/svg/bug.xhtml
http://grante.homeip.net/svg/bug.svg
If you view the SVG file with Inkscape, it seems to be OK, so I
guess it may be Opera's and Firefox's fault. I suspect that
Opera and Firefox aren't seeing the fontsize info somehow. But,
if Gnuplot's SVG output can't be viewed in a web broser it's of
little value (at least to me).
--
Grant Edwards grante Yow! Did an Italian CRANE
at OPERATOR just experience
visi.com uninhibited sensations in
a MALIBU HOT TUB?
Ethan Merritt
Grant Edwards <gra...@visi.com> wrote:
>If you use a non-default fontsize in the SVG terminal (gnuplto
>4.2), the leading of text seems to be incorrect when viewed in
>Opera or Firefox. If you use a smaller than default fontsize,
>multiline labels start to overlap themselves. The x axis tick
>labes also start to overlap with the x axis.
All known SVG viewers are poor. The best one I have found so far
is the ksvg plugin used by the KDE components, but it has plenty
of faults as well. The firefox implementation is not one of the
better ones at the moment.
The biggest failing with regard to text positioning is that
virtually none of the current viewers implement the character-based
coordinate systems (em and en relative placement). Unfortunately,
this is the mechanism used by gnuplot's enhanced text layer.
Re-writing the enhanced text layer just because svg viewers fail
to fully implement the standard is not likely to happen.
I am just hoping that as time passes and svg becomes more common,
the viewers will improve.
>Here's an example:
>
>set out "bug.svg"
>set term svg size 800,600 fsize 5
>set label "this shows\nhow a\multiline label\nis incorrectly\nleaded" at 4,0.5
>set title "Demo of SVG fontsize bug"
>plot sin(x)
>set out
>
>http://grante.homeip.net/svg/bug.xhtml
>http://grante.homeip.net/svg/bug.svg
>
>If you view the SVG file with Inkscape, it seems to be OK, so I
>guess it may be Opera's and Firefox's fault. I suspect that
>Opera and Firefox aren't seeing the fontsize info somehow. But,
>if Gnuplot's SVG output can't be viewed in a web broser it's of
>little value (at least to me).
>
>--
>Grant Edwards grante Yow! Did an Italian CRANE
> at OPERATOR just experience
> visi.com uninhibited sensations in
> a MALIBU HOT TUB?
--
Ethan A Merritt
Grant Edwards
>>If you use a non-default fontsize in the SVG terminal (gnuplto
>>4.2), the leading of text seems to be incorrect when viewed in
>>Opera or Firefox. If you use a smaller than default fontsize,
>>multiline labels start to overlap themselves. The x axis tick
>>labes also start to overlap with the x axis.
>
> All known SVG viewers are poor. The best one I have found so far
> is the ksvg plugin used by the KDE components, but it has plenty
> of faults as well. The firefox implementation is not one of the
> better ones at the moment.
That's too bad, since vector graphics for the web is the only
common application for SVG that I've seen.
> The biggest failing with regard to text positioning is that
> virtually none of the current viewers implement the character-based
> coordinate systems (em and en relative placement).
Actually it looks like the web browsers are reducing the
leading in proportion to the font size. But the rendered size
of the text doesn't change.
> Unfortunately, this is the mechanism used by gnuplot's
> enhanced text layer. Re-writing the enhanced text layer just
> because svg viewers fail to fully implement the standard is
> not likely to happen. I am just hoping that as time passes and
> svg becomes more common, the viewers will improve.
I guess I'll just rearrange my plots so that the default font
sizes will work. It'll be ugly, but I've got little choice: I
can't get pdflib to build under Windows, so I can't use the pdf
terminal (which would be my first choice).
Is there some way to produce an easily viewable/printable[1]
plot on windows that I don't know about? Raster formats are
not acceptible because they never print well.
[1] in a file format that you can expect most randomly chosen
Win32 boxes to understand (e.g. PDF, RTF, HTML, XHTML).
--
Grant Edwards grante Yow! I Know A Joke!!
at
visi.com
Ethan Merritt
Grant Edwards <gra...@visi.com> wrote:
>On 2007-05-17, Ethan Merritt <mer...@u.washington.edu> wrote:
>
>> All known SVG viewers are poor. The best one I have found so far
>> is the ksvg plugin used by the KDE components, but it has plenty
>> of faults as well. The firefox implementation is not one of the
>> better ones at the moment.
>
>That's too bad, since vector graphics for the web is the only
>common application for SVG that I've seen.
Your test plots look just fine in the KDE web browser, konqueror,
although you have set the default font size very small (Arial 5).
I would go with 15 rather than 5.
>> The biggest failing with regard to text positioning is that
>> virtually none of the current viewers implement the character-based
>> coordinate systems (em and en relative placement).
>
>Actually it looks like the web browsers are reducing the
>leading in proportion to the font size. But the rendered size
>of the text doesn't change.
That may be a different problem. Maybe your system is not
configured to provide the font "arial" to the web browser?
For me the text sizing works fine in firefox; it's only the
spacing that it gets wrong.
>Is there some way to produce an easily viewable/printable[1]
>plot on windows that I don't know about? Raster formats are
>not acceptible because they never print well.
My recommendation for Windows is to use cgm or emf. These are
native metafile formats, and I think that most if not all
Microsoft programs can handle them. Not all of gnuplot's
features are supported in these terminal types, but emf does
pretty well overall.
Or you could make *.eps files and convert them with ps2pdf.
--
Ethan A Merritt
Grant Edwards
>>> All known SVG viewers are poor. The best one I have found so
>>> far is the ksvg plugin used by the KDE components, but it has
>>> plenty of faults as well. The firefox implementation is not
>>> one of the better ones at the moment.
>>
>>That's too bad, since vector graphics for the web is the only
>>common application for SVG that I've seen.
>
> Your test plots look just fine in the KDE web browser,
> konqueror, although you have set the default font size very
> small (Arial 5). I would go with 15 rather than 5.
I'm going to have enough trouble fitting labels on the plots
using 12, there's no way 15 will work.
>>> The biggest failing with regard to text positioning is that
>>> virtually none of the current viewers implement the
>>> character-based coordinate systems (em and en relative
>>> placement).
>>
>>Actually it looks like the web browsers are reducing the
>>leading in proportion to the font size. But the rendered size
>>of the text doesn't change.
>
> That may be a different problem. Maybe your system is not
> configured to provide the font "arial" to the web browser?
It's one of the options that the browser's preferences dialog
shows for "default fonts", and when you select it, it seems to
work. Here's what those plots look like in my broswer with 5pt
and 10pt:
http://grante.homeip.net/svg/bug-Arial10pt.png
http://grante.homeip.net/svg/bug-Arial5pt.png
Notice that only the spacing changes: the font size doesn't.
I get similar results using helvetica, times, veranda, etc. The
rendered typeface is changing to what I specify, but the size
never changes, it's always rendered at the default size.
> For me the text sizing works fine in firefox; it's only the
> spacing that it gets wrong.
It sure doesn't work for me using Firefox 2.0.0.3, or Opera 9.
I get exactly the same results in both: leading changes,
rendered font size doesn't.
>>Is there some way to produce an easily viewable/printable[1]
>>plot on windows that I don't know about? Raster formats are
>>not acceptible because they never print well.
>
> My recommendation for Windows is to use cgm or emf. These are
> native metafile formats, and I think that most if not all
> Microsoft programs can handle them.
The files aren't for use by programs. They're for use by
people. IOW, when somebody double-clicks on the file they
expect to see the plot and be able to print it.
> Not all of gnuplot's features are supported in these terminal
> types, but emf does pretty well overall.
None of the three Windows machines I tried could display either
.emf or .cgm files. One displayed both in a text editor. The
other two attempted to open .emf files with "Windows Picture
and Fax Viewer" which then displayed nothing, and they didn't
know what to do with .cgm files.
> Or you could make *.eps files and convert them with ps2pdf.
That's fine when running on Linux (though I tend to just use
the pdf terminal), but Windows machines almost never have
ps2pdf. The program needs to run on Windows and produce files
that a Windows user can look at.
Oh, how I hate MS Windows.
--
Grant Edwards grante Yow! Now I understand the
at meaning of "THE MOD SQUAD"!
visi.com
Grant Edwards
>> My recommendation for Windows is to use cgm or emf. These are
>> native metafile formats, and I think that most if not all
>> Microsoft programs can handle them.
>
> The files aren't for use by programs. They're for use by
> people. IOW, when somebody double-clicks on the file they
> expect to see the plot and be able to print it.
[...]
> None of the three Windows machines I tried could display either
> .emf or .cgm files.
Next on the list of things to try (I think I'm probably up to
about plan H by now): programmatically create an RTF document
containing the data from the .emf file created by gnuplot. It
looks like most/all of the Windows machines I care about know
how to view/print RTF files.
--
Grant Edwards grante Yow! The Korean War must
at have been fun.
visi.com