From: Thomas J. D. <to...@fi...> - 2004-12-01 22:18:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here are a couple of fixes for postscript text problems in the ps.c driver (diffs below, revised file at http://aolab.phys.dal.ca/~tomduck/temp/ps.c): 1) When using postscript fonts and portrait orientation, the text was rotated incorrectly. 2) When using postscript fonts, brackets were not properly escaped for the SW postscript command, resulting in postscript errors. 3) Subscripts and superscripts should be printed with a smaller font size. I would like to recommend that DEF_WIDTH in ps.h be returned to its original value of 1 instead of the (relatively) new value of 3. This provides more flexibility in setting the line widths for postscript plots, which is otherwise too coarse. I'm not often able to read this list, so please copy any responses to my email address. Thanks. Sincerely, Tom - -- ps.c.original is the original ps.c from cvs I have used my initials, TJD, wherever I have inserted comments. - -- diff ps.c.original ps.c 666a667,670 > PLFLT scale; /* TJD: Font size scaling parameter */ > > int i=0; /* TJD: String index */ > 681c685,688 < angle = ((PLFLT)(ORIENTATION-1) - pls->diorot) * 90.; - --- > /* TJD: In the next line I changed the sign from - to + so that text > * prints out correctly when in portrait mode. > */ > angle = ((PLFLT)(ORIENTATION-1) + pls->diorot) * 90.; 817c824,837 < fprintf(OF, "%.3f (%s) SW\n", - args->just, str); - --- > /* TJD: Changed so that brackets are written as \( and \) */ > /* fprintf(OF, "%.3f (%s) SW\n", - args->just, str); */ > fprintf(OF, "%.3f (", - args->just); > while (str[i]!='\0') { > if (str[i]=='(') fprintf(OF,"\\("); > else { > if (str[i]==')') fprintf(OF,"\\)"); > else fprintf(OF,"%c",str[i]); > } > i++; > } > fprintf(OF,") SW\n"); > > 820a841,842 > scale = 1.; /* TJD: Default scaling parameter */ > 848a871 > scale = 0.8; /* TJD: Subscript scaling parameter */ 853a877 > scale = 0.8; /* TJD: Superscript scaling parameter */ 890,891d913 < /* set the font */ < 893c915,917 < fprintf(OF, "/%s %.1f SF\n", font, font_factor * ENLARGE * ft_ht); - --- > > /* TJD: Include font scaling for superscripts and subscripts */ > fprintf(OF, "/%s %.1f SF\n", font, font_factor * ENLARGE * ft_ht * scale); - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB Tier I CRC Chair in Atmospheric Science: http://www.atm.dal.ca/jobs/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrkIDndxDHhfZZdsRAnXrAJ9T6CvpW36WrritXMZQDXOAKOza8QCdHPSE cWatZlZgvpY56XZ0sXAGCwM= =I+t8 -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2004-12-03 18:12:05
|
On 2004-12-01 18:13-0400 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Here are a couple of fixes for postscript text problems in the > ps.c driver (diffs below, revised file at > http://aolab.phys.dal.ca/~tomduck/temp/ps.c): > > 1) When using postscript fonts and portrait orientation, the text was > rotated incorrectly. > > 2) When using postscript fonts, brackets were not properly escaped for the > SW postscript command, resulting in postscript errors. > > 3) Subscripts and superscripts should be printed with a smaller font size. All these fixes sound like they are well worth incorporating, but I have a more fundamental question first: How exactly are you specifying postscript fonts? If that is through pstex, could you repeat the cookbook you are using since pstex use is undocumented? If not pstex, that would be a most interesting breakthrough since I thought we were limited to just the Hershey fonts for the psc and ps devices. > > I would like to recommend that DEF_WIDTH in ps.h be returned to its > original value of 1 instead of the (relatively) new value of 3. This > provides more flexibility in setting the line widths for postscript plots, > which is otherwise too coarse. I tend to agree here. I believe the justification for the change at the time was it made it more consistent with other devices, but if postscript is capable of a finer-grained approach than the other devices, we should probably allow that. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-12-03 18:42:00
|
* Alan W. Irwin <ir...@be...> [2004-12-03 10:11]: > How exactly are you specifying postscript fonts? If that is through pstex, > could you repeat the cookbook you are using since pstex use is undocumented? > If not pstex, that would be a most interesting breakthrough since I thought > we were limited to just the Hershey fonts for the psc and ps devices. I am perhaps completely misunderstanding your question, but aren't PS fonts selected trivially like this: ./x01c -o out.ps -dev ps -drvopt text ? This feature has been around since ages. -- Rafael |
From: Thomas J. D. <to...@fi...> - 2004-12-03 20:29:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, Thanks for your email. On Fri, 3 Dec 2004, Alan W. Irwin wrote: > How exactly are you specifying postscript fonts? If that is through pstex, > could you repeat the cookbook you are using since pstex use is undocumented? > If not pstex, that would be a most interesting breakthrough since I thought > we were limited to just the Hershey fonts for the psc and ps devices. I am using postscript fonts by setting the driver options. For example, in python you would write plplot.plsetopt('drvopt','text=1') to invoke usage of postscript fonts (do this before plinit()). There are only four different fonts available in plplot, and their postscript equivalents are chosen as usual: e.g., plplot.plfont(1) for Helvetica, etc. The GD driver allows you to select anti-aliased fonts in the same way. In general, the driver options are undocumented, and I learned about them by reading through the code. We might consider adding an option to both drivers that would allow you to specify exactly what four fonts should be used. > > I would like to recommend that DEF_WIDTH in ps.h be returned to its > > original value of 1 instead of the (relatively) new value of 3. This > > provides more flexibility in setting the line widths for postscript plots, > > which is otherwise too coarse. > > I tend to agree here. I believe the justification for the change at the > time was it made it more consistent with other devices, but if postscript is > capable of a finer-grained approach than the other devices, we should > probably allow that. Alternatively, this could also be set as a driver option. Advantage: nobody would notice the change. Disadvantage: new users might overlook this functionality, and assume that finer-grained lines were not possible with the postscript driver. Cheers, Tom - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB Tier I CRC Chair in Atmospheric Science: http://www.atm.dal.ca/jobs/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBsMuVndxDHhfZZdsRAtF5AJsELpXOKfr661NzuLBjFCWo30Z4HwCffpdC KI9amwadTRK/ozsIyD0dWgU= =18iE -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2004-12-03 19:54:36
|
On 2004-12-03 19:41+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-12-03 10:11]: > >> How exactly are you specifying postscript fonts? If that is through pstex, >> could you repeat the cookbook you are using since pstex use is undocumented? >> If not pstex, that would be a most interesting breakthrough since I thought >> we were limited to just the Hershey fonts for the psc and ps devices. > > I am perhaps completely misunderstanding your question, but aren't PS fonts > selected trivially like this: > > ./x01c -o out.ps -dev ps -drvopt text > > ? > > This feature has been around since ages. Thanks, Rafael, for bringing my attention to this feature. I actually was never aware of this feature before, and I have wanted it for some time. (For example, this need motivated my recent questions about freetype support for ps.c.) Is "-dev psc -drvopt text" actually documented somewhere in our DocBook documentation? If not, we should do such documentation. I suspect my (previous) ignorance of this useful feature is pretty common. For example, if our developers and users were generally aware of this feature, somebody would have long since complained about the ubiquitous orientation bugs. Not only are such bugs present for the portrait mode that Thomas discussed but also for ordinary landscape mode (e.g., if you are doing a 3D plot), and I am surprised, Rafael, you haven't run into these bugs (unless you are simply aware of -drvopt text and never actually tried to use it). I will test Thomas's fixes to see if it solves all the orientation problems I have immediately encountered in my research plots with -drvopt text. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-12-03 20:47:22
|
On 2004-12-01 18:13-0400 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Here are a couple of fixes for postscript text problems in the > ps.c driver (diffs below, revised file at > http://aolab.phys.dal.ca/~tomduck/temp/ps.c): > > 1) When using postscript fonts and portrait orientation, the text was > rotated incorrectly. > > 2) When using postscript fonts, brackets were not properly escaped for the > SW postscript command, resulting in postscript errors. > > 3) Subscripts and superscripts should be printed with a smaller font size. Hi Thomas: Now that Rafael has reminded me about the -drvopt text option for -dev psc, I was able to try your patched version of ps.c, and as a result ./x07c -dev psc -portrait -o test.ps -drvopt text=1 looks good for the first time, and there were similar good results for x01c. So I am tempted just to stick your patch into cvs. However, before I do that, would you be willing to have a quick look at the remaining obvious orientation issues for example 11? Your patch now makes portrait mode look identical to -landscape mode (as far as orientation issues are concerned) for 3d plots, but both are wrong. Try the following to see this with the default landscape mode: ./x11c -dev psc -o test.ps -drvopt text=1 or ./x11c -dev psc -o test.ps -drvopt text=1 (Just drop the -drvopt text=1 option to see what the label orientation really should be like.) This problem (for landscape mode) is present regardless of whether your current patch is applied or not. I am sure this is just some issue like rotating the wrong way to generate the 3D perspective on the labels, and if you could sort out that issue as well, we would end up with postscript fonts that work in all circumstances which would be most helpful. Note, from the programme notes it looks like I tried to figure out the 3D orientation issue with a quick effort before but was not successful. If a similar quick effort from you doesn't pay off, then I am happy to accept "half a loaf" and update cvs with your present patch. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-12-03 21:06:21
|
On 2004-12-03 11:54-0800 Alan W. Irwin wrote: > Thanks, Rafael, for bringing my attention to this feature. I actually was > never aware of this feature before.... That statement is too strong. I just checked back through cvs logs, and indeed I once (two years ago) tried debugging orientation problems (for rotations other than 90 deg) with this feature. But I completely forgot about it again (probably because I use 3D a lot and so the remaining 3D orientation problems were a showstopper for me). Anyhow, if Thomas or anybody else can sort out the 3D orientation problems with this feature, I will be a happy camper. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <mj...@ga...> - 2004-12-04 01:40:27
|
Thomas J. Duck writes: > I would like to recommend that DEF_WIDTH in ps.h be returned to its > original value of 1 instead of the (relatively) new value of 3. This > provides more flexibility in setting the line widths for postscript plots, > which is otherwise too coarse. It was changed to 3 b/c that gave better results for printed output IMO, and I think it makes the most sense for the default setting to give good results. A pen width of 1 gave way too thin/faint of lines. But people should try this out for themselves. I'd be interested to hear if anyone thinks the width setting at 1 gives better results to paper on a laser printer. Since a pen width default of 3 in ps.c has been the default for 10 years or so, I'm skeptical of the need to change it now. You can always change it programmatically if something else (like 1) is more to your liking. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2004-12-04 01:52:55
|
On 2004-12-03 19:35-0600 mj...@ga... wrote: > Thomas J. Duck writes: > > I would like to recommend that DEF_WIDTH in ps.h be returned to its > > original value of 1 instead of the (relatively) new value of 3. This > > provides more flexibility in setting the line widths for postscript plots, > > which is otherwise too coarse. > > It was changed to 3 b/c that gave better results for printed output IMO, and I > think it makes the most sense for the default setting to give good results. A > pen width of 1 gave way too thin/faint of lines. But people should try this > out for themselves. I'd be interested to hear if anyone thinks the width > setting at 1 gives better results to paper on a laser printer. > > Since a pen width default of 3 in ps.c has been the default for 10 years or > so, I'm skeptical of the need to change it now. You can always change it > programmatically if something else (like 1) is more to your liking. The present default width is fine, but the commit message, "Make the PostScript linewidth a multiple of DEF_WIDTH" occurred relatively recently (on 2004/01/28). If I am interpreting this message correctly (I am too tired/busy to look at code like I should), then in terms of the old width we only have 3,6,9, etc. available to us now which I think is too coarse. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <mj...@ga...> - 2004-12-04 02:30:14
|
Alan W. Irwin writes: > On 2004-12-03 19:35-0600 mj...@ga... wrote: > > > Thomas J. Duck writes: > > > I would like to recommend that DEF_WIDTH in ps.h be returned to its > > > original value of 1 instead of the (relatively) new value of 3. This > > > provides more flexibility in setting the line widths for postscript plots, > > > which is otherwise too coarse. > > > > It was changed to 3 b/c that gave better results for printed output IMO, and I > > think it makes the most sense for the default setting to give good results. A > > pen width of 1 gave way too thin/faint of lines. But people should try this > > out for themselves. I'd be interested to hear if anyone thinks the width > > setting at 1 gives better results to paper on a laser printer. > > > > Since a pen width default of 3 in ps.c has been the default for 10 years or > > so, I'm skeptical of the need to change it now. You can always change it > > programmatically if something else (like 1) is more to your liking. > > The present default width is fine, but the commit message, > > "Make the PostScript linewidth a multiple of DEF_WIDTH" > > occurred relatively recently (on 2004/01/28). If I am interpreting this > message correctly (I am too tired/busy to look at code like I should), then > in terms of the old width we only have 3,6,9, etc. available to us now which > I think is too coarse. Oh ok.. I see the problem -- int width = (pls->width < MIN_WIDTH) ? DEF_WIDTH : (pls->width > MAX_WIDTH) ? MAX_WIDTH : DEF_WIDTH * pls->width; Ouch. Agreed, this has to go. -- Maurice LeBrun mj...@ga... |
From: Rafael L. <rla...@us...> - 2004-12-04 11:58:09
|
* mj...@ga... <mj...@ga...> [2004-12-03 20:25]: > Alan W. Irwin writes: > > The present default width is fine, but the commit message, > > > > "Make the PostScript linewidth a multiple of DEF_WIDTH" > > > > occurred relatively recently (on 2004/01/28). If I am interpreting this > > message correctly (I am too tired/busy to look at code like I should), then > > in terms of the old width we only have 3,6,9, etc. available to us now > > which I think is too coarse. > > Oh ok.. I see the problem -- > > int width = > (pls->width < MIN_WIDTH) ? DEF_WIDTH : > (pls->width > MAX_WIDTH) ? MAX_WIDTH : DEF_WIDTH * pls->width; > > Ouch. Agreed, this has to go. I did this change because the result of the ps driver was visually incoherent with those of the other drivers. The most blatant example of this occurs with x02.c. However, I agree that a resolution of 3 pt for line widths is way too coarse for the ps driver. The problem is: how could we revert my change above and keep coherent visual results across all drivers? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-12-04 18:41:35
|
On 2004-12-04 12:58+0100 Rafael Laboissiere wrote: > * mj...@ga... <mj...@ga...> [2004-12-03 20:25]: > >> Alan W. Irwin writes: >>> The present default width is fine, but the commit message, >>> >>> "Make the PostScript linewidth a multiple of DEF_WIDTH" >>> >>> occurred relatively recently (on 2004/01/28). If I am interpreting this >>> message correctly (I am too tired/busy to look at code like I should), then >>> in terms of the old width we only have 3,6,9, etc. available to us now >>> which I think is too coarse. >> >> Oh ok.. I see the problem -- >> >> int width = >> (pls->width < MIN_WIDTH) ? DEF_WIDTH : >> (pls->width > MAX_WIDTH) ? MAX_WIDTH : DEF_WIDTH * pls->width; >> >> Ouch. Agreed, this has to go. > > I did this change because the result of the ps driver was visually > incoherent with those of the other drivers. The most blatant example of > this occurs with x02.c. However, I agree that a resolution of 3 pt for line > widths is way too coarse for the ps driver. The problem is: how could we > revert my change above and keep coherent visual results across all drivers? I haven't waded through the code to confirm this, and my attempts to figure out what was going on by looking at results were inconclusive. Nevertheless, I believe a reasonable mental model of what is going on is that plwid normally just specifies the line width to each device driver in that device's natural coordinates (probably pixels). Rafael's attempt to get consistency between e.g., the png device width and ps device width seems to be consistent with that model since the png and xwin devices by default have much less resolution (a factor of three less?) than the postscript device. However, this procedure is unlikely to give consistent widths if you use non-default resolutions (specified with the -geometry option). Furthermore, as we have seen, demanding such consistency gives too much coarseness to the choice of widths for the higher-resolution devices such as ps. Here is what I suggest to resolve all this assuming the above mental model is correct. * Revert Rafael's change to ps.c. plwid user's already expect differences between devices in any case since for a long time now the documentation has stated "The interpretation of positive width values is also device dependent." * With the above change, users always have the option if they want width consistency between two devices to put some device-dependent logic in their scripts to choose the correct plwid for each of the devices they are using. * However, if somebody really feels strongly about width consistency, they can make a plwidmm (or whatever you want to call it) function for PLplot that accepts a PLFLT line width in mm. Internally, that function would translate that width into the appropriate integer for a call to the low-level plwid that specifies the width in the natural coordinates (probably pixels) for each device. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-12-04 18:55:11
|
* Alan W. Irwin <ir...@be...> [2004-12-04 10:40]: > Here is what I suggest to resolve all this assuming the above mental model > is correct. > > * Revert Rafael's change to ps.c. plwid user's already expect differences > between devices in any case since for a long time now the documentation > has stated "The interpretation of positive width values is also device > dependent." > > * With the above change, users always have the option if they want width > consistency between two devices to put some device-dependent logic > in their scripts to choose the correct plwid for each of the devices they > are using. > > * However, if somebody really feels strongly about width consistency, they > can make a plwidmm (or whatever you want to call it) function for PLplot > that accepts a PLFLT line width in mm. Internally, that function would > translate that width into the appropriate integer for a call to the > low-level plwid that specifies the width in the natural coordinates > (probably pixels) for each device. I like your plan, even if the third point is highly hypothetical. Go ahead and revert my change. I do not really care about it. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-12-06 07:30:33
|
mj...@ga... wrote: > > Thomas J. Duck writes: > > I would like to recommend that DEF_WIDTH in ps.h be returned to its > > original value of 1 instead of the (relatively) new value of 3. This > > provides more flexibility in setting the line widths for postscript plots, > > which is otherwise too coarse. > > It was changed to 3 b/c that gave better results for printed output IMO, and I > think it makes the most sense for the default setting to give good results. A > pen width of 1 gave way too thin/faint of lines. But people should try this > out for themselves. I'd be interested to hear if anyone thinks the width > setting at 1 gives better results to paper on a laser printer. > > Since a pen width default of 3 in ps.c has been the default for 10 years or > so, I'm skeptical of the need to change it now. You can always change it > programmatically if something else (like 1) is more to your liking. > The change surprised me a bit when I updated my program. However, as the program explicitly sets the pen width anyway it was a small matter to adjust it - I had never noticed anything wrong with the default width :) Regards, Arjen |