Menu
▾
▴
[Gnuplot-bugs] gnuplot 4.0.0, PDFlib and term/pdf.tfm
|
From: Harald K. <ko...@sc...> - 2004-07-20 15:34:43
|
Hi gnuplot developers!
first, a big thank for that wonderful tool gnuplot !!!!
I'm using it for many many years now and I still prefere t
because of it's great and simple UI...
I've compiled gnuplot-4.0.0 on various plattforms including PDF support
using PDFlib-Lite-6.0.0, and I had to make a few changes in the sources
for portability (full patch see below).
finally I;ve added a "wish list" as RFC with some ideas below as (5) ...
1) PDFlib-6.0.0 is missing PDF_open_fp()
PDF_open_fp() is no longer supported, only PDF_open_file() is available.
see change in term/pdf.trm below.
for more PDF stuff, please see (4) and (5) below...
2) sequence of "png.trm" and "pdf.trm" in src/term.h:
on some Linux boxes compilation bombs because of the following code
in pngconf.h of my copy of libpng sources:
#ifdef PNG_SETJMP_SUPPORTED
/* This is an attempt to force a single setjmp behaviour on Linux. If
* the X config stuff didn't define _BSD_SOURCE we wouldn't need this.
*/
# ifdef __linux__
# ifdef _BSD_SOURCE
# define PNG_SAVE_BSD_SOURCE
# undef _BSD_SOURCE
# endif
# ifdef _SETJMP_H
==> __png.h__ already includes setjmp.h;
==> __dont__ include it again.;
# endif
# endif /* __linux__ */
changing the ordering in term.h (png before pdf) seems to be the
most portable solution to me (see src/term.h diff below).
3) "char" argument and pre-ANSI-C (K&R) functions without prototypes:
old-style K&R funtions don't really allow to have "char" arguments,
because without correct prototype "char" will be promoted to "int".
so mixing old-style functions and ANSI-C protypes can mess up code
on some plattforms, e.g. HP-UX 10.20:
cc: "../term/hpljii.trm", line 284: error 1711: Inconsistent parameter list declaration for "HPLJII_putc".
cc: "term.c", line 2025: error 1711: Inconsistent parameter list declaration for "do_enh_writec".
on other plattforms with gcc I get those warnuings:
../term/dumb.trm:556: warning: initialization from incompatible pointer type
../term/pdf.trm:1396: warning: initialization from incompatible pointer type
../term/x11.trm:1558: warning: initialization from incompatible pointer type
../term/x11.trm:1581: warning: initialization from incompatible pointer type
to get rid of the this problem I changed the "char" to "int" argument for do_enh_writec()
and in pm3d_plot() (see changes in src/pm3d.c, src/term.c and term/hpljii.trm)
maybe you really should clean up the K&R code and use ANSI-C style
functions and prototypes everywhere. maybe it's just to run
the tool "protoize" from (old?) gcc distributions ?!?
4) PDF output and acroread
maybe you can remember my mail
Subject: bugs/problems in gnuplot 3.8k (cvs)
Message-ID: <200...@tu...>
Date: Fri, 23 Jan 2004 18:36:22 +0100
From: Harald Koenig <ko...@sc...>
To: gnu...@li..., gnu...@li...
about landscape vs. portrait printing of gnuplot-PDF files with acroread ?
now with gnuplot-4.0.0 and PDFlib-Lite-6.0.0 or PDFlib-6.0.0 the situation
still was the same: acroread prints PDF files from gnuplot by default
on a portrait page with plenty white space above and below the
landscape-shaped plot.
first I tried to add that "/Rotate 90" entry in the /Page object,
but that didn't help at all:-( btw: you can add options to
the /Page object using
PDF_begin_page_ext(myPDF, xmax, ymax, "rotate=90");
^^^^ ^^^^^^^^^^^^^
but then, the plot region still was the same share/position
and only the plot content itself rotated clockwise. so I added
the following code after PDF_begin_page_ext()
PDF_rotate(myPDF, 90);
PDF_translate(myPDF, 0,-PDF_YMAX/PDF_RESOLUTION);
which undid the clockwise rotation, but now the printing problem
in acrobat was exactly the same as before :-(((
after plenty more PDF decoding and testing I realized, that acroread
uses some "automagic" behaviour:
if the PDF file/area size fits into the paper size, the plot is
printed "as is" without optimization to the page share, even if
"expand small pages to paper size" is selected. that's what happens
to PDF files from gnuplot, as they are 5x3 inch and fit on A4/letter paper.
if the PDF plot is larger (e.g. gnuplot PS output converted with gs to PDF
which gives ~DIN A4 plot), then acroread automagically rotates the plot
and prints landscape !!
now knowing this, I can print gnuplot PDF files nicely my explicitly selecting
"landscape" in the "File -> Page Setup" and I can get ugly prints with plenty
white space for gnuplot PS->PDF files by selection "portrait".
unfortuneately, this selection of landscape/portrait is not available in
the print menu, so usually one won't think about that important switch.
so I looked for a "automatic" solution and tried to enlarge the PDF plots from gnuplot.
unfortuneately the PDF driver uses lots of magic absolut sizes for many
properties like line widths, tick and symbol sizes etc. which don't scale
correctly if I try to increase PDF_XMAX and PDF_YMAX.
because of that I'm using the 2nd patch to pdf.trm below which scales
the plot size only in the PDF_begin_page() call and in the resolution
transformation in PDF_scale() afterwards.
additionally I changed the page size from 5x3 to 5x3.5 inch, resulting
in a plot of 10x7 inch which is more or less compatible with the
postscript driver output. the only drawback I've realizes so far is the
"wrong" font size for text which claims to be 6pt while being scaled
to 12pt (postscript driver defaults to 14 pt).
it would be great if eiher you change the pdf driver to genereate larger
plot sizes (10x7 in, compatible to postscript -- see (5) below) or
at least try to use XMAX or YMAX or some other scalig constant as unit
for other lenghts/widths/sizes so that it's easy to change the default
plot size. thanks!
(5) whish list:: PDF vs. postscript/X11 driver output "compatibility"
it would be great, if at least the X11, postscript and PDF drivers would
generate similar/compatible output for the same gnuplot command file
and try match the visual appearence. that is, they use
- same color sequuence for line types
- same symbol shape sequuence
- same line hashes
- same page/plot size
right now, only the first 5 colors are similar (not the same),
starting with color #6 things look different:
color # X11 postscript R G B PDF (web colors)
1 red 1 0 0 red 0xff, 0x00, 0x00 red
2 green 0 1 0 green 0x00, 0xc0, 0x00 dark green
3 blue 0 0 1 blue 0x00, 0x80, 0xff dark blue
4 magenta 1 0 1 magenta 0xc0, 0x00, 0xff dark magenta
5 cyan 0 1 1 cyan 0x00, 0xee, 0xee cyan
6 dsienna 1 1 0 yellow 0xc0, 0x40, 0x00 orange
7 orange 0 0 0 black 0xee, 0xee, 0x00 yellow
8 coral 1 .3 0 orange red 0x20, 0x20, 0xc0 royal blue
9 #1: red .5 .5 .5 gray 0xff, 0xc0, 0x20 goldenrod1
10 #2: green #1: red 0x00, 0x80, 0x40 SpringGreen4
11 ... ... ... ... ... ...
IMHO at least the first 16 colors for those (and other) drivers
should [try to] be the same. using the web_colors table like
the PDF driver looks like a goo idea to me (to start with ?)...
any comments to get some common behaviour into the gnuplot drivers ?
and here are my patches as explained above:
-------------------------------------------------------------------------------
diff -ur orig/gnuplot-4.0.0/src/pm3d.c gnuplot-4.0.0/src/pm3d.c
--- orig/gnuplot-4.0.0/src/pm3d.c Sat Apr 10 17:55:15 2004
+++ gnuplot-4.0.0/src/pm3d.c Fri May 14 13:19:58 2004
@@ -53,7 +53,7 @@
/* Internal prototypes for this module */
static double geomean4 __PROTO((double, double, double, double));
static double median4 __PROTO((double, double, double, double));
-static void pm3d_plot __PROTO((struct surface_points *, char));
+static void pm3d_plot __PROTO((struct surface_points *, int));
static void pm3d_option_at_error __PROTO((void));
static void pm3d_rearrange_part __PROTO((struct iso_curve *, const int, struct iso_curve ***, int *));
static void filled_color_contour_plot __PROTO((struct surface_points *, int));
@@ -304,7 +304,7 @@
static void
pm3d_plot(this_plot, at_which_z)
struct surface_points *this_plot;
- char at_which_z;
+ int at_which_z;
{
int j, i, i1, ii, ii1, from, curve, scan, up_to, up_to_minus, invert = 0;
int go_over_pts, max_pts;
diff -ur orig/gnuplot-4.0.0/src/term.c gnuplot-4.0.0/src/term.c
--- orig/gnuplot-4.0.0/src/term.c Tue Apr 13 19:24:02 2004
+++ gnuplot-4.0.0/src/term.c Fri May 14 13:23:17 2004
@@ -218,7 +218,7 @@
char *fontname, double fontsize, double base,
TBOOLEAN widthflag, TBOOLEAN showflag, int overprint));
static void enh_err_check __PROTO((const char *str));
-static void do_enh_writec __PROTO((char c));
+static void do_enh_writec __PROTO((int c));
#ifdef __ZTC__
char *ztc_init();
@@ -2024,7 +2024,7 @@
static void
do_enh_writec(c)
- char c;
+ int c;
{
*enhanced_cur_text++ = c;
}
diff -ur orig/gnuplot-4.0.0/src/term.h gnuplot-4.0.0/src/term.h
--- orig/gnuplot-4.0.0/src/term.h Tue Apr 13 19:24:02 2004
+++ gnuplot-4.0.0/src/term.h Fri Jul 2 16:58:25 2004
@@ -345,12 +345,6 @@
/* portable bit map */
#include "pbm.trm"
-/* Adobe Portable Document Format (PDF) */
-/* NOTE THAT PDF REQUIRES A SEPARATE LIBRARY : see term/pdf.trm */
-#ifdef HAVE_LIBPDF
-# include "pdf.trm"
-#endif
-
/* NOTE THAT PNG AND JPEG SUPPORT REQUIRE SEPARATE LIBRARIES */
/* There are 2 flavors of PNG support */
/* If you are using an old version of libgd in order to get true GIF support */
@@ -363,6 +357,12 @@
# else
# include "png.trm"
# endif
+#endif
+
+/* Adobe Portable Document Format (PDF) */
+/* NOTE THAT PDF REQUIRES A SEPARATE LIBRARY : see term/pdf.trm */
+#ifdef HAVE_LIBPDF
+# include "pdf.trm"
#endif
/* postscript */
diff -ur orig/gnuplot-4.0.0/term/hpljii.trm gnuplot-4.0.0/term/hpljii.trm
--- orig/gnuplot-4.0.0/term/hpljii.trm Tue Apr 13 19:24:33 2004
+++ gnuplot-4.0.0/term/hpljii.trm Fri May 14 13:24:03 2004
@@ -117,7 +117,7 @@
#define HPLJII_COURIER fputs("\033(0N\033(s0p10.0h12.0v0s0b3T\033&l6D",gpoutfile)
-static void HPLJII_putc __PROTO((unsigned int x, unsigned int y, char c, int ang));
+static void HPLJII_putc __PROTO((unsigned int x, unsigned int y, int c, int ang));
static int hplj_dpp = 4;
/* bm_pattern not appropriate for 300ppi graphics */
#ifndef GOT_300_PATTERN
@@ -284,7 +284,7 @@
static void
HPLJII_putc(x, y, c, ang)
unsigned int x, y;
- char c;
+ int c;
int ang;
{
HPLJII_POP_CURSOR;
diff -ur orig/gnuplot-4.0.0/term/pdf.trm gnuplot-4.0.0/term/pdf.trm
--- orig/gnuplot-4.0.0/term/pdf.trm Sat Apr 10 17:55:17 2004
+++ gnuplot-4.0.0/term/pdf.trm Tue Jul 20 15:26:30 2004
@@ -343,7 +343,7 @@
myPDF = PDF_new();
/*open new PDF file */
- if (PDF_open_fp(myPDF, gpoutfile) == -1)
+ if (PDF_open_file(myPDF, outstr) == -1)
int_error(NO_CARET, "Error:cannot open PDF file .\n");
#ifdef PDF_DONT_COMPRESS
diff -ur orig/gnuplot-4.0.0/term/pdf.trm gnuplot-4.0.0/term/pdf.trm
--- orig/gnuplot-4.0.0/term/pdf.trm Sat Apr 10 17:55:17 2004
+++ gnuplot-4.0.0/term/pdf.trm Tue Jul 20 15:26:30 2004
@@ -72,7 +72,7 @@
#define PDF_RESOLUTION (20) /* number of terminal pixels per pt */
#define PDF_XMAX (5*72*PDF_RESOLUTION) /* 5 inches, 72 pt/inch */
-#define PDF_YMAX (3*72*PDF_RESOLUTION) /* 3 inches, 72 pt/inch */
+#define PDF_YMAX (3.5*72*PDF_RESOLUTION) /* 3 inches, 72 pt/inch */
#endif /* TERM_PROTO */
@@ -395,9 +395,10 @@
term->xmax = PDF_XMAX * xsize;
term->ymax = PDF_YMAX * ysize;
- PDF_begin_page(myPDF, (double)term->xmax / PDF_RESOLUTION,
- (double)term->ymax / PDF_RESOLUTION);
- PDF_scale(myPDF, 1.0/PDF_RESOLUTION, 1.0/PDF_RESOLUTION);
+ PDF_begin_page(myPDF, 2.0 * (double)term->xmax / PDF_RESOLUTION,
+ 2.0 * (double)term->ymax / PDF_RESOLUTION);
+ PDF_scale(myPDF, 2.0/PDF_RESOLUTION, 2.0/PDF_RESOLUTION);
+
if (title.text && title.text[0])
/* a title has been set --> use it as the bookmark name, too */
PDF_add_bookmark(myPDF, title.text, 0, 1);
-------------------------------------------------------------------------------
Harald Koenig
--
"I hope to die ___ _____
before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig \/\/\/\/\/\/\/\/\/
science+computing ag // / \\ \
ko...@sc... ^^^^^ ^^^^^
|
