Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1177 Wrong bounding box of QT menu-driven PDF/SVG export

closed-fixed
nobody
5
2012-10-20
2012-10-02
No

When using the menu-driven PDF export in the QT terminal, the page size is chosen as a portrait A4, which does not look like the gnuplot window at all. In addition, the actual plot graphics is then located on the upper half of this A4 page.

When using the menu-driven SVG export in the QT terminal, the resulting SVG file has a landscape format, but not of the same aspect ratio as the gnuplot window, and there is too much white space on the right hand side of the plot graphics content, and also too much whitespace below.

When using the menu-driven PNG export it looks correct.

I'm using Gnuplot 4.6 from Debian Sid:

ii gnuplot 4.6.0-8
ii gnuplot-qt 4.6.0-8

Discussion

  • Ethan Merritt
    Ethan Merritt
    2012-10-05

    • status: open --> open-works-for-me
     
  • Ethan Merritt
    Ethan Merritt
    2012-10-05

    I cannot reproduce this problem. For me the SVG output starts with a line:
    <svg width="225.778mm" height="169.333mm"
    where the width and height are taken from the current Qt plot window size.

    Similarly the PDF output contains
    /MediaBox [0 0 640 480]

    In both cases the output is produce by a call to the Qt library rather than any explicit output from gnuplot. Perhaps your Qt library is messing up somehow (old version? bad configuration? I really don't know). I tested with libqt 4.6.3.

    In the case of PDF output, it is possible that your PDF viewer is ignoring the bounding box in favor of displaying a full page by default. Viewers usually allow you to toggle between full page / full width / bounding box only / etc.

    Actually, the same might be true for SVG. For instance, if I open the gnuplot output in inkscape it shows me a whole page by default. But if I click "resize to content" then it reverts to the bounding box size.

     
  • This problem was solved in CVS on 2012-04-01

     
  • Ethan Merritt
    Ethan Merritt
    2012-10-05

    Ah, OK. Good.
    Then the reason I couldn't reproduce it is that both the current release (4.6.1) and the development version (4.7) contain a fix.

     
  • I updated to 4.6.1. Now PDF output is correct, with page size 226mm x 169mm, and the graphics is correctly placed on the page in that case (by visual inspection).

    However, SVG output is still not correct. While the page size is 226mm x 169mm, the graphics content is not correctly placed on the page.

    This can be confirmed by opening the SVG in Inkscape and checking the Document properties. The page size is 226mm x 169mm while the graphics is misplaced, so Inkscape does not introduce its own arbitrary page size when opening the SVG.

    Subsequent use of "Resize to content" in Inkscape then changes to the smallest possible page around the graphics, but this is not related to the bounding box value of the original SVG. The resulting page size will be much smaller, in my case 142mm x 92mm, but it depends on the graphics. So I don't think this is related to the Gnuplot-QT/SVG problem.

    The graphics is also shown to be misplaced in the SVG when viewed in Geeqie. As noted before, too much whitespace on the left and below, and too little at the top. The graphics is also possibly too small on the page, when compared with the Gnuplot window and PDF output.

    Gnuplot 4.6.1
    QT 4.8.2
    Inkscape 0.48.3.1

    Best regards
    Torquil Sørensen

     
  • Ethan Merritt
    Ethan Merritt
    2012-10-11

    • status: open-works-for-me --> open-fixed
     
  • Ethan Merritt
    Ethan Merritt
    2012-10-11

    I think I have this working now. The fix is in CVS for both 4.6 and 4.7.
    However, this is an empirical fix. It makes sense, but I can't find any relevant documentation that confirms it is correct.

     
  • Ethan Merritt
    Ethan Merritt
    2012-10-20

    • status: open-fixed --> closed-fixed