Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2012-10-11 20:08:58
Attachments:
svgtest.png
|
I'm comparing the output of gnuplot's svg and pngcairo drivers, with a thought of making greater use of SVG. But there seems to be a slight problem with the placement of key text in the SVG output. Here's a little test script set term svg font "Sans,8" size 680,400 set output 'test.svg' set key left top plot sin(x) title "PRIME" w l, \ cos(x) title "UNEMP" w l set term pngcairo font "Sans,8" size 680,400 set output 'test.png' replot In the PNG version the key is just fine, but in SVG the "U" of "UNEMP" gets tangled up with the y-axis (more or less, depending on the magnification). I'm looking at the SVG using librsvg, and also via the Adobe NPSVG3 library. To show what I'm talking about, I'm attaching the SVG output as converted to PNG by rsvg-convert (at 96dpi). -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: Ethan A M. <sf...@us...> - 2012-10-11 23:16:01
|
On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
> I'm comparing the output of gnuplot's svg and pngcairo
> drivers, with a thought of making greater use of SVG. But
> there seems to be a slight problem with the placement of key
> text in the SVG output. Here's a little test script
>
> set term svg font "Sans,8" size 680,400
> set output 'test.svg'
> set key left top
> plot sin(x) title "PRIME" w l, \
> cos(x) title "UNEMP" w l
> set term pngcairo font "Sans,8" size 680,400
> set output 'test.png'
> replot
>
> In the PNG version the key is just fine, but in SVG the "U" of
> "UNEMP" gets tangled up with the y-axis (more or less,
> depending on the magnification).
The underlying issue is that for SVG, like PostScript, gnuplot has
to guess at the font properties for a font that will not actually
be selected until the file is later viewed in another program.
Here is the relevant code snippet from svg.trm:
/* since we cannot interrogate SVG about text properties and according
* to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the
* "line-height" of the 'text' element is defined to be equal to the
* 'font-size' (!), we have to to define font properties in a less
* than optimal way */
SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE);
SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE);
Apparently for the font your viewer is choosing in response to a
request for "Sans", the average character width is greater than
70% of the nominal font size. It would be easy enough to bump
SVG_fontAvWidth up to 0.8 or something, but I imagine that in
turn might be too wide for other viewer+font+text combinations.
Contributing to the problem in your particular example is that fact that
the title is in all caps, and capital letters are wider than the "average"
letter in most proportionally-spaced fonts. We might be able to address
this part of the problem by modifying gnuplot's string width estimator
to bump up the estimate if there are many capital letters in the string.
Ethan
> I'm looking at the SVG using
> librsvg, and also via the Adobe NPSVG3 library. To show what
> I'm talking about, I'm attaching the SVG output as converted
> to PNG by rsvg-convert (at 96dpi).
>
>
|
|
From: Ethan A M. <sf...@us...> - 2012-10-11 23:32:24
|
On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: > On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: > > I'm comparing the output of gnuplot's svg and pngcairo > > drivers, with a thought of making greater use of SVG. But > > there seems to be a slight problem with the placement of key > > text in the SVG output. Here's a little test script > > > > set term svg font "Sans,8" size 680,400 > > set output 'test.svg' > > set key left top > > plot sin(x) title "PRIME" w l, \ > > cos(x) title "UNEMP" w l > > set term pngcairo font "Sans,8" size 680,400 > > set output 'test.png' > > replot > > > > In the PNG version the key is just fine, but in SVG the "U" of > > "UNEMP" gets tangled up with the y-axis (more or less, > > depending on the magnification). > > The underlying issue is that for SVG, like PostScript, gnuplot has > to guess at the font properties for a font that will not actually > be selected until the file is later viewed in another program. By the way, if you turn on the "box" attribute of the key you can see that the key box itself is properly placed. The problem is that in your case the width of the box is too small because the size of the text was underestimated. As a work-around, you could use "set key left Left". That anchors the left end of the text rather than the right end, so it is not at risk of overwriting the left plot border. Instead the right end of the text might run into the line sample ;-) Ethan > Here is the relevant code snippet from svg.trm: > > /* since we cannot interrogate SVG about text properties and according > * to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the > * "line-height" of the 'text' element is defined to be equal to the > * 'font-size' (!), we have to to define font properties in a less > * than optimal way */ > SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE); > SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE); > SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE); > SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE); > > Apparently for the font your viewer is choosing in response to a > request for "Sans", the average character width is greater than > 70% of the nominal font size. It would be easy enough to bump > SVG_fontAvWidth up to 0.8 or something, but I imagine that in > turn might be too wide for other viewer+font+text combinations. > > Contributing to the problem in your particular example is that fact that > the title is in all caps, and capital letters are wider than the "average" > letter in most proportionally-spaced fonts. We might be able to address > this part of the problem by modifying gnuplot's string width estimator > to bump up the estimate if there are many capital letters in the string. > > Ethan > > > > > > > I'm looking at the SVG using > > librsvg, and also via the Adobe NPSVG3 library. To show what > > I'm talking about, I'm attaching the SVG output as converted > > to PNG by rsvg-convert (at 96dpi). > > > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Daniel J S. <dan...@ie...> - 2012-10-11 23:38:52
|
On 10/11/2012 06:31 PM, Ethan A Merritt wrote: > On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>> I'm comparing the output of gnuplot's svg and pngcairo >>> drivers, with a thought of making greater use of SVG. But >>> there seems to be a slight problem with the placement of key >>> text in the SVG output. Here's a little test script >>> >>> set term svg font "Sans,8" size 680,400 >>> set output 'test.svg' >>> set key left top >>> plot sin(x) title "PRIME" w l, \ >>> cos(x) title "UNEMP" w l >>> set term pngcairo font "Sans,8" size 680,400 >>> set output 'test.png' >>> replot >>> >>> In the PNG version the key is just fine, but in SVG the "U" of >>> "UNEMP" gets tangled up with the y-axis (more or less, >>> depending on the magnification). >> >> The underlying issue is that for SVG, like PostScript, gnuplot has >> to guess at the font properties for a font that will not actually >> be selected until the file is later viewed in another program. > > By the way, if you turn on the "box" attribute of the key you can > see that the key box itself is properly placed. The problem is that in > your case the width of the box is too small because the size of the text > was underestimated. > > As a work-around, you could use "set key left Left". > That anchors the left end of the text rather than the right end, > so it is not at risk of overwriting the left plot border. > Instead the right end of the text might run into the line sample ;-) One might be able to put a space at the front or end of the text to compensate for that as well. (And there might even be some parameters associated with key text that can be adjusted.) The easiest alternative is probably to look for a font that both gnuplot can use for width information and that the SVG driver can use for display. Dan > > Ethan > > > > >> Here is the relevant code snippet from svg.trm: >> >> /* since we cannot interrogate SVG about text properties and according >> * to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the >> * "line-height" of the 'text' element is defined to be equal to the >> * 'font-size' (!), we have to to define font properties in a less >> * than optimal way */ >> SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE); >> SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE); >> SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE); >> SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE); >> >> Apparently for the font your viewer is choosing in response to a >> request for "Sans", the average character width is greater than >> 70% of the nominal font size. It would be easy enough to bump >> SVG_fontAvWidth up to 0.8 or something, but I imagine that in >> turn might be too wide for other viewer+font+text combinations. >> >> Contributing to the problem in your particular example is that fact that >> the title is in all caps, and capital letters are wider than the "average" >> letter in most proportionally-spaced fonts. We might be able to address >> this part of the problem by modifying gnuplot's string width estimator >> to bump up the estimate if there are many capital letters in the string. >> >> Ethan >> >> >> >> >> >>> I'm looking at the SVG using >>> librsvg, and also via the Adobe NPSVG3 library. To show what >>> I'm talking about, I'm attaching the SVG output as converted >>> to PNG by rsvg-convert (at 96dpi). >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> gnuplot-beta mailing list >> gnu...@li... >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta >> > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
|
From: Allin C. <cot...@wf...> - 2012-10-11 23:43:12
|
On Thu, 11 Oct 2012, Ethan A Merritt wrote: > On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>> I'm comparing the output of gnuplot's svg and pngcairo >>> drivers, with a thought of making greater use of SVG. But >>> there seems to be a slight problem with the placement of key >>> text in the SVG output. Here's a little test script >>> >>> set term svg font "Sans,8" size 680,400 >>> set output 'test.svg' >>> set key left top >>> plot sin(x) title "PRIME" w l, \ >>> cos(x) title "UNEMP" w l >>> set term pngcairo font "Sans,8" size 680,400 >>> set output 'test.png' >>> replot >>> >>> In the PNG version the key is just fine, but in SVG the "U" of >>> "UNEMP" gets tangled up with the y-axis (more or less, >>> depending on the magnification). >> >> The underlying issue is that for SVG, like PostScript, gnuplot has >> to guess at the font properties for a font that will not actually >> be selected until the file is later viewed in another program. > > By the way, if you turn on the "box" attribute of the key you can > see that the key box itself is properly placed. The problem is that in > your case the width of the box is too small because the size of the text > was underestimated. > > As a work-around, you could use "set key left Left". > That anchors the left end of the text rather than the right end, > so it is not at risk of overwriting the left plot border. > Instead the right end of the text might run into the line sample ;-) Ah, that's a nice suggestion. I can manipulate the key placement so as to try to avoid colliding with the plot lines, just so long as I'm reasonably confident it won't collide with the axes. But on the more general point, does this mean I might have better luck if a specified the font more precisely than just "Sans"? Allin Cottrell |
|
From: <pl...@pi...> - 2012-10-12 06:24:26
|
On 10/12/12 01:43, Allin Cottrell wrote: > On Thu, 11 Oct 2012, Ethan A Merritt wrote: > >> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>>> I'm comparing the output of gnuplot's svg and pngcairo >>>> drivers, with a thought of making greater use of SVG. But >>>> there seems to be a slight problem with the placement of key >>>> text in the SVG output. Here's a little test script >>>> >>>> set term svg font "Sans,8" size 680,400 >>>> set output 'test.svg' >>>> set key left top >>>> plot sin(x) title "PRIME" w l, \ >>>> cos(x) title "UNEMP" w l >>>> set term pngcairo font "Sans,8" size 680,400 >>>> set output 'test.png' >>>> replot >>>> The nice thing about SVG is the ability to zoom in to get more detail. Doing this on Allin's example , comparing Firefox to Opera on linux, the U of UNEMP is basically outside the plot with the second upright on the y-axis. With Opera is it perfectly coincident this the y axis, on FF it is just inside the graph with a very fine amount of white separating it from the axis. A more exacting test case could provide some useful metrics on the problem. Peter. |
|
From: <pl...@pi...> - 2012-10-12 07:21:58
|
On 10/12/12 01:43, Allin Cottrell wrote: > On Thu, 11 Oct 2012, Ethan A Merritt wrote: > >> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>>> I'm comparing the output of gnuplot's svg and pngcairo >>>> drivers, with a thought of making greater use of SVG. But >>>> there seems to be a slight problem with the placement of key >>>> text in the SVG output. Here's a little test script >>>> >>>> set term svg font "Sans,8" size 680,400 >>>> set output 'test.svg' >>>> set key left top >>>> plot sin(x) title "PRIME" w l, \ >>>> cos(x) title "UNEMP" w l >>>> set term pngcairo font "Sans,8" size 680,400 >>>> set output 'test.png' >>>> replot >>>> >>>> In the PNG version the key is just fine, but in SVG the "U" of >>>> "UNEMP" gets tangled up with the y-axis (more or less, >>>> depending on the magnification). >>> >>> The underlying issue is that for SVG, like PostScript, gnuplot has >>> to guess at the font properties for a font that will not actually >>> be selected until the file is later viewed in another program. >> >> By the way, if you turn on the "box" attribute of the key you can >> see that the key box itself is properly placed. The problem is that in >> your case the width of the box is too small because the size of the text >> was underestimated. >> >> As a work-around, you could use "set key left Left". >> That anchors the left end of the text rather than the right end, >> so it is not at risk of overwriting the left plot border. >> Instead the right end of the text might run into the line sample ;-) > > Ah, that's a nice suggestion. I can manipulate the key placement so > as to try to avoid colliding with the plot lines, just so long as > I'm reasonably confident it won't collide with the axes. > > But on the more general point, does this mean I might have better > luck if a specified the font more precisely than just "Sans"? > > Allin Cottrell > Yes, I have taken to specifying the font size and name explicitly and using spaces to avoid this kind of over-run as Daniel suggested. It really would be good if some improvement could be made in this area. With longer key titles, the errors can be substantial. It is a bit of a guessing game but it seems that the guesses are always(?) rather poor. Counting capitals would be a good first step. Since this is a once per plot overhead, some detailed accounting would not have any noticeable performance hit. Clearly text content can not be counted on to average out on such short samples, 'emmission spectrum" with not have the same average letter width as " illiterate infallibility" Perhaps some quantitative study of real examples of which fonts render poorly on which renderers would permit better guesses to be build into gnuplot. Clearly there are thousands of fonts but maybe certain families are consistently wider / narrower so more knowledge would help improve built-in guesses and also help users avoid fonts that can't be estimated reliably. There may well be some platform dependency in all this as well. That would be harder to fix but probably needs assessing. Are fonts consistently rendering different widths on linux / Mac / Win. ? Perhaps Ethan (who probably knows better than most how to manifest the differences) could produce a test script an we could return screenshots of various renderings on different platforms and software. regards, Peter. |
|
From: Daniel J S. <dan...@ie...> - 2012-10-12 08:03:24
|
On 10/12/2012 01:08 AM, pl...@pi... wrote: > On 10/12/12 01:43, Allin Cottrell wrote: >> On Thu, 11 Oct 2012, Ethan A Merritt wrote: >> >>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>>>> I'm comparing the output of gnuplot's svg and pngcairo >>>>> drivers, with a thought of making greater use of SVG. But >>>>> there seems to be a slight problem with the placement of key >>>>> text in the SVG output. Here's a little test script >>>>> >>>>> set term svg font "Sans,8" size 680,400 >>>>> set output 'test.svg' >>>>> set key left top >>>>> plot sin(x) title "PRIME" w l, \ >>>>> cos(x) title "UNEMP" w l >>>>> set term pngcairo font "Sans,8" size 680,400 >>>>> set output 'test.png' >>>>> replot >>>>> >>>>> In the PNG version the key is just fine, but in SVG the "U" of >>>>> "UNEMP" gets tangled up with the y-axis (more or less, >>>>> depending on the magnification). >>>> >>>> The underlying issue is that for SVG, like PostScript, gnuplot has >>>> to guess at the font properties for a font that will not actually >>>> be selected until the file is later viewed in another program. >>> >>> By the way, if you turn on the "box" attribute of the key you can >>> see that the key box itself is properly placed. The problem is that in >>> your case the width of the box is too small because the size of the text >>> was underestimated. >>> >>> As a work-around, you could use "set key left Left". >>> That anchors the left end of the text rather than the right end, >>> so it is not at risk of overwriting the left plot border. >>> Instead the right end of the text might run into the line sample ;-) >> >> Ah, that's a nice suggestion. I can manipulate the key placement so >> as to try to avoid colliding with the plot lines, just so long as >> I'm reasonably confident it won't collide with the axes. >> >> But on the more general point, does this mean I might have better >> luck if a specified the font more precisely than just "Sans"? >> >> Allin Cottrell >> > > Yes, I have taken to specifying the font size and name explicitly and > using spaces to avoid this kind of over-run as Daniel suggested. > > It really would be good if some improvement could be made in this area. > With longer key titles, the errors can be substantial. > > It is a bit of a guessing game but it seems that the guesses are > always(?) rather poor. It's awful. Working with fonts has historically been a headache. Save tweaking font position for the last touch up on graphs. > Counting capitals would be a good first step. Since this is a once per > plot overhead, some detailed accounting would not have any noticeable > performance hit. Counting capitals goes along the lines one doesn't want to go. The proper way of doing this is either to have scalable fonts, or for the library to have a convenient function by which the programmer can provide the font type/size and an ASCII string of the text to be placed and the routine returns the size when rendered. Font substitution is a get-what-you-get sort of thing. > Clearly text content can not be counted on to average out on such short > samples, 'emmission spectrum" with not have the same average letter > width as " illiterate infallibility" > > Perhaps some quantitative study of real examples of which fonts render > poorly on which renderers would permit better guesses to be build into > gnuplot. > > Clearly there are thousands of fonts but maybe certain families are > consistently wider / narrower so more knowledge would help improve > built-in guesses and also help users avoid fonts that can't be estimated > reliably. > > There may well be some platform dependency in all this as well. That > would be harder to fix but probably needs assessing. Are fonts > consistently rendering different widths on linux / Mac / Win. ? That should be factored into the routine that indicates rendered widths, if one existed. Dan |
|
From: <pl...@pi...> - 2012-10-12 15:54:20
|
On 10/12/12 10:03, Daniel J Sebald wrote: > On 10/12/2012 01:08 AM, pl...@pi... wrote: >> On 10/12/12 01:43, Allin Cottrell wrote: >>> On Thu, 11 Oct 2012, Ethan A Merritt wrote: >>> >>>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote: >>>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >>>>>> I'm comparing the output of gnuplot's svg and pngcairo >>>>>> drivers, with a thought of making greater use of SVG. But >>>>>> there seems to be a slight problem with the placement of key >>>>>> text in the SVG output. Here's a little test script >>>>>> >>>>>> set term svg font "Sans,8" size 680,400 >>>>>> set output 'test.svg' >>>>>> set key left top >>>>>> plot sin(x) title "PRIME" w l, \ >>>>>> cos(x) title "UNEMP" w l >>>>>> set term pngcairo font "Sans,8" size 680,400 >>>>>> set output 'test.png' >>>>>> replot >>>>>> >>>>>> In the PNG version the key is just fine, but in SVG the "U" of >>>>>> "UNEMP" gets tangled up with the y-axis (more or less, >>>>>> depending on the magnification). >>>>> >>>>> The underlying issue is that for SVG, like PostScript, gnuplot has >>>>> to guess at the font properties for a font that will not actually >>>>> be selected until the file is later viewed in another program. >>>> >>>> By the way, if you turn on the "box" attribute of the key you can >>>> see that the key box itself is properly placed. The problem is that in >>>> your case the width of the box is too small because the size of the >>>> text >>>> was underestimated. >>>> >>>> As a work-around, you could use "set key left Left". >>>> That anchors the left end of the text rather than the right end, >>>> so it is not at risk of overwriting the left plot border. >>>> Instead the right end of the text might run into the line sample ;-) >>> >>> Ah, that's a nice suggestion. I can manipulate the key placement so >>> as to try to avoid colliding with the plot lines, just so long as >>> I'm reasonably confident it won't collide with the axes. >>> >>> But on the more general point, does this mean I might have better >>> luck if a specified the font more precisely than just "Sans"? >>> >>> Allin Cottrell >>> >> >> Yes, I have taken to specifying the font size and name explicitly and >> using spaces to avoid this kind of over-run as Daniel suggested. >> >> It really would be good if some improvement could be made in this area. >> With longer key titles, the errors can be substantial. >> >> It is a bit of a guessing game but it seems that the guesses are >> always(?) rather poor. > > It's awful. Working with fonts has historically been a headache. Save > tweaking font position for the last touch up on graphs. > > >> Counting capitals would be a good first step. Since this is a once per >> plot overhead, some detailed accounting would not have any noticeable >> performance hit. > > Counting capitals goes along the lines one doesn't want to go. The > proper way of doing this is either to have scalable fonts, or for the > library to have a convenient function by which the programmer can > provide the font type/size and an ASCII string of the text to be placed > and the routine returns the size when rendered. Font substitution is a > get-what-you-get sort of thing. > > >> Clearly text content can not be counted on to average out on such short >> samples, 'emmission spectrum" with not have the same average letter >> width as " illiterate infallibility" >> >> Perhaps some quantitative study of real examples of which fonts render >> poorly on which renderers would permit better guesses to be build into >> gnuplot. >> >> Clearly there are thousands of fonts but maybe certain families are >> consistently wider / narrower so more knowledge would help improve >> built-in guesses and also help users avoid fonts that can't be estimated >> reliably. >> >> There may well be some platform dependency in all this as well. That >> would be harder to fix but probably needs assessing. Are fonts >> consistently rendering different widths on linux / Mac / Win. ? > > That should be factored into the routine that indicates rendered widths, > if one existed. > > Dan > What you are suggesting would mean a active, self-modifying document. That is probably possible with SVG though I doubt whether it could be applied to PS. I would imagine that kind of solution opening up a lot of possibilities for bugs , though in some ways seeing what you get given at render time is the only definitive way to get the text size spot on. As I recall previous comments for Ethan on this problem have stated that absence of any call back mechanism in certain terminals is why gnuplot does not use this strategy in any terminal. Maybe those than can, should when that can be determined at plotting time. Even aside from the render time problems I find significant differences between live output in wxt and rendering to png , for example. Sometimes I end up doing a screenshot of the wxt rendition and saving it as png :( I think some worthwhile improvements could be made without going to the lengths involved in documents self-modifying at display time. regards, Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-12 15:40:54
|
On Friday, 12 October 2012, Daniel J Sebald wrote: > > Counting capitals would be a good first step. Since this is a once per > > plot overhead, some detailed accounting would not have any noticeable > > performance hit. > > Counting capitals goes along the lines one doesn't want to go. The > proper way of doing this is either to have scalable fonts, or for the > library to have a convenient function by which the programmer can > provide the font type/size and an ASCII string of the text to be placed > and the routine returns the size when rendered. Font substitution is a > get-what-you-get sort of thing. The fonts are scalable. That's not the problem. There are routines that return font metrics, but in order for it to make any sense they must be called by (or at least in the same context as) the program that is displaying the result. Calling such a library from inside gnuplot would at best only an approximation based on rendering some other font in some other environment. pl...@pi... wrote> > The nice thing about SVG is the ability to zoom in to get more detail. > Doing this on Allin's example , comparing Firefox to Opera on linux, > the U of UNEMP is basically outside the plot with the second upright on > the y-axis. > > With Opera is it perfectly coincident this the y axis, on FF it is just > inside the graph with a very fine amount of white separating it from the > axis. > > A more exacting test case could provide some useful metrics on the problem. But how would that help? Aren't you illustrating that the _same file_ produces different results when displayed by different viewing programs? I have found one ray of hope, however. There is a project called @font-face <http://www.font-face.com/> that attempts to define a mechanism for achieving cross-browser consistency in font display. I haven't had time to look into it seriously, but at first glance it seems like it might be a way to upgrade gnuplot's text handling for web display via the canvas terminal. I don't know whether it is relevant to SVG, however. If someone wants to look into it more deeply, that would be great. Ethan |
|
From: <pl...@pi...> - 2012-10-12 21:53:52
|
On 10/12/12 17:40, sfeam (Ethan Merritt) wrote: > pl...@pi... wrote> >> >The nice thing about SVG is the ability to zoom in to get more detail. >> >Doing this on Allin's example , comparing Firefox to Opera on linux, >> >the U of UNEMP is basically outside the plot with the second upright on >> >the y-axis. >> > >> >With Opera is it perfectly coincident this the y axis, on FF it is just >> >inside the graph with a very fine amount of white separating it from the >> >axis. >> > >> >A more exacting test case could provide some useful metrics on the problem. > But how would that help? Aren't you illustrating that the_same file_ > produces different results when displayed by different viewing programs? Exactly. What I found out by testing was that even on the same platform there are fond rendering differences. That is one thing I wanted to know. I also established that on the face of it , it's so damn small, you need to blow up to x20 to see it. What I was suggesting is that quantifying the problem like this is probably an essential first step to fixing it in the most effective way with a minimum of trial and error loops. I think you have a much better understanding that I do of where the weaknesses lie but I'd expect a test case to have long key titles, be tested with several different types of font and include varying amounts of capitals, and letters like i,l,t against m,a,c,w,o Comparison should probably be made between (wxt, qt ) and pngcairo et al and svg/postscript. This in a matrix with lin/mac/win on the other vector. Hopefully this would find some areas that work fine and determine worst cases aberrations. best regards, Peter. |
|
From: Ethan A M. <sf...@us...> - 2012-10-12 17:35:25
|
On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: > I'm comparing the output of gnuplot's svg and pngcairo > drivers, with a thought of making greater use of SVG. But > there seems to be a slight problem with the placement of key > text in the SVG output. Here's a little test script > > set term svg font "Sans,8" size 680,400 > set output 'test.svg' > set key left top > plot sin(x) title "PRIME" w l, cos(x) title "UNEMP" w l > > In the PNG version the key is just fine, but in SVG the "U" of > "UNEMP" gets tangled up with the y-axis (more or less, > depending on the magnification). I'm looking at the SVG using > librsvg, and also via the Adobe NPSVG3 library. To show what > I'm talking about, > I'm attaching the SVG output as converted to PNG by rsvg-convert > (at 96dpi). ^^^^^^^^^^ That dpi setting turns out to be relevant. I went back to the SVG spec and learned the following: - you can specify font-size in either absolute or relative units - font-size="8pt" requests an 8 point font regardless of the display resolution or current scaling. That's what gnuplot does. In theory, if you view an SVG document in a viewer that allows you to rescale the figure, the font should display as the same size even after rescaling the plot. That is, if you shrink the figure the font does _not_ shrink with it. - font-size="8" or font-size="8px" requests a font size relative to the current display units. It will scale up or down as the figure is re-sized. - For a 95dpi display, 8pt is translated to 10px. That is, it is displayed 25% larger than gnuplot was expecting. This is probably at the heart of the problem. - You can confirm this by opening the output of your test command in inkscape and then saving it to a new *.svg file. The original gnuplot output contains text marked "font-size:8pt" but inkscape converts this to "font-size:10" (no units). I don't know what is the best thing to do here. Being able to specify an absolute font size makes sense in many cases, but not in all cases. Perhaps we need a gnuplot terminal option that controls whether gnuplot writes out absolute or relative units for the font size. I suppose the code that estimates text length would have to be aware of this also. Ethan |
|
From: <pl...@pi...> - 2012-10-12 19:03:54
|
On 10/12/12 19:34, Ethan A Merritt wrote: > On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote: >> I'm comparing the output of gnuplot's svg and pngcairo >> drivers, with a thought of making greater use of SVG. But >> there seems to be a slight problem with the placement of key >> text in the SVG output. Here's a little test script >> >> set term svg font "Sans,8" size 680,400 >> set output 'test.svg' >> set key left top >> plot sin(x) title "PRIME" w l, cos(x) title "UNEMP" w l >> >> In the PNG version the key is just fine, but in SVG the "U" of >> "UNEMP" gets tangled up with the y-axis (more or less, >> depending on the magnification). I'm looking at the SVG using >> librsvg, and also via the Adobe NPSVG3 library. To show what >> I'm talking about, > >> I'm attaching the SVG output as converted to PNG by rsvg-convert >> (at 96dpi). > ^^^^^^^^^^ > > That dpi setting turns out to be relevant. > I went back to the SVG spec and learned the following: > > - you can specify font-size in either absolute or relative units > > - font-size="8pt" requests an 8 point font regardless of the > display resolution or current scaling. That's what gnuplot does. > In theory, if you view an SVG document in a viewer that allows > you to rescale the figure, the font should display as the same > size even after rescaling the plot. That is, if you shrink the > figure the font does _not_ shrink with it. Not what I am finding in practise. I have a gnuplot graph in svg which contains text formatted as follows: <g transform="translate(41.3,43.7)" style="stroke:none; fill:black; font-family:verdana; font-size:9.00pt; text-anchor:end"> Both Opera and FF zoom both the text and graph lines with the zoom feature (if that is what you were referring to by rescale). Frankly , that is what I would expect. Like if I zoom an html document, the main reason would be to increase the rendition of the font size. Maybe I misunderstood "rescale". /Peter. > > - font-size="8" or font-size="8px" requests a font size relative to > the current display units. It will scale up or down as the figure > is re-sized. > > - For a 95dpi display, 8pt is translated to 10px. That is, it is > displayed 25% larger than gnuplot was expecting. This is probably > at the heart of the problem. > > - You can confirm this by opening the output of your test command in > inkscape and then saving it to a new *.svg file. The original gnuplot > output contains text marked "font-size:8pt" but inkscape converts this > to "font-size:10" (no units). > > I don't know what is the best thing to do here. > Being able to specify an absolute font size makes sense in many > cases, but not in all cases. Perhaps we need a gnuplot terminal option > that controls whether gnuplot writes out absolute or relative units for > the font size. I suppose the code that estimates text length would have > to be aware of this also. > > Ethan > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan A M. <sf...@us...> - 2012-10-12 20:38:39
|
On Friday, October 12, 2012 11:27:20 am pl...@pi... wrote: > > - font-size="8pt" requests an 8 point font regardless of the > > display resolution or current scaling. That's what gnuplot does. > > In theory, if you view an SVG document in a viewer that allows > > you to rescale the figure, the font should display as the same > > size even after rescaling the plot. That is, if you shrink the > > figure the font does not shrink with it. > > Not what I am finding in practise. Right. Me neither. So theory and practice diverge once again. Nevertheless, writing the same SVG text element twice, once with font-size="10pt" and once with font-size="10" is quite informative about the substantial difference between the two descriptions. I think I will change the svg terminal to omit units from the font-size attribute, bringing it into line with what inkscape does. I am left rather confused about the level of device dependence, but at least on typical terminal screens (90-100dpi) this makes gnuplot's string width estimates much more accurate. If this causes problems for someone's use case (probably when embedding into a larger XML document) then we can consider how to make the font-size units a driver configuration option. Ethan |
|
From: Allin C. <cot...@wf...> - 2012-10-13 00:09:26
|
On Fri, 12 Oct 2012, Ethan A Merritt wrote: > On Friday, October 12, 2012 11:27:20 am pl...@pi... wrote: >>> - font-size="8pt" requests an 8 point font regardless of the >>> display resolution or current scaling. That's what gnuplot does. >>> In theory, if you view an SVG document in a viewer that allows >>> you to rescale the figure, the font should display as the same >>> size even after rescaling the plot. That is, if you shrink the >>> figure the font does not shrink with it. >> >> Not what I am finding in practise. > > Right. Me neither. So theory and practice diverge once again. > Nevertheless, writing the same SVG text element twice, > once with font-size="10pt" and once with font-size="10" is > quite informative about the substantial difference between the > two descriptions. > > I think I will change the svg terminal to omit units from the > font-size attribute, bringing it into line with what inkscape > does. I am left rather confused about the level of device > dependence, but at least on typical terminal screens (90-100dpi) > this makes gnuplot's string width estimates much more accurate. This sounds promising. One further thought: what about using a temporary pango layout to size the text, with the same font name/size specification? This won't necessarily work well in all cases, but I guess that in many cases the visual rendering of an SVG file will in the end depend on cairo and pango, so laying out the text via pango, in RAM, would give a reasonable approximation to the size as actually seen. Even if not always right, surely better than the current vague guess? I haven't checked yet, but I presume this is what the pngcairo and pdfcairo drivers do at present, and their text placement is fine. Allin Cottrell |
