Date: Mon Apr 04 2011 - 22:01:32 MDT
On Apr 1, 2011, at 12:22 PM, Daniel Adriaansen wrote:
> Hello NCL-Team and users,
>
> I am working on creating an automated plotting package to generate
> images to be viewed on the web. There are multiple times, vertical
> levels, and variables that the user can choose from, so visual
> consistency among all images is extremely important.
>
> In putting these together, I noticed two quirks that I could not
> figure
> out, which are leading to visual inconsistencies among the plots. I
> have attached an example script that can be executed to demonstrate
> the
> problem. Please note the comments in the script for the three
> resources
> causing the issues, and that you can change the replicate the problem.
>
> My Information:
> ncl V6.0.0-beta, Debian Linux
>
> My Problem(s):
> 1. As you can see from the script, the gsnLeftString and
> gsnRightString
> appear to have different vertical positions. This is a result of one
> string having characters that extend below the "line", meaning those
> such as j, g, p, q, etc... and the other one not having any of these
> characters. I did some digging into the gsn_csm.ncl code inside
> $NCARG_LIB/ncarg/nclscripts/csm. The best I could do was on line
> 1893 I
> located a line that said:
>
> "amJust" : "bottom"+just(i)
>
> which for the gsnLeftString justifies the string as "bottomleft". I
> tried changing this to:
>
> "amJust" : "top"+just(i)
>
> but it did not solve the problem. Suggestions?
Hi Daniel,
This has been an issue since day one of NCL, and I'm afraid there's no
easy way to fix it. There's no way to align text according to the
baseline of a text string, rather than the bottom of the text string.
The kludgy way of getting around this easily is to try to make sure
that your strings all consistently either have characters that go
below the baseline, or else *none* of them do (i.e. make the strings
uppercase). See the attached figures
for what I mean by baseline versus bottom of a string.
The hard way to do this is to examine each string, determine whether
it has characters that will make it align differently than the other
strings, and then adjust that string accordingly with the appropriate
gsnXXXStringOrthogonalPosF resource. This is very awkward, IMHO,
because I don't know of an easy to examine your strings and determine
what kind of characters they have. We've had a ticket open on this for
awhile (NCL-243), but it has been low priority because I think it's a
pretty major feature to implement.
>
> 2. When adding a label bar to the plot, I have the vpWidthF set to
> 1.0.
> I also set the pmLabelBarWidthF to 1.0, to match the vpWidthF. The
> problem was some label bars exceeded the map boundary which was an
> undesired result. So to combat this problem I reduced the
> pmLabelBarWidthF to 0.95, however the overall size of the plot area
> changed. You can replicate this by changing pmLabelBarWidthF in the
> sample script. Is there a reason that the plot area becomes larger
> when
> I reduce the label bar width (but leaving vpWidthF at 1.0)? Any info
> would be great. Thanks in advance for the help.
I think Dave is going to have to help you with this part. I've never
understood how the size of the labelbar is controlled, as it depends
on some internal factors, like the size of your plot, whether you have
tickmarks, whether you've set a number of other labelbar resources,
etc. However, you might get some understanding with example 13 at:
http://www.ncl.ucar.edu/Applications/labelbar.shtml
The resource that might help you is lbBoxMinorExtent.
--Mary
>
> -Dan
> <test_titles.ncl>_______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
