R.P. Churchill.com

Today’s goal was to come up with a reasonably automated way to specify formatting for the numeric values associated with the major tickmarks on each axis. I chose to implement settings for decimal places, overall precision width, and whether or not trailing zeros would be stripped. If the formatted string with decimal places is used unless it is longer than the formatted string at the specified precision, in which case the latter is used. Trailing zeroes are then stripped from each string.

This may result in different strings having different formats. First there’s always that one string that has fewer decimal places than all the others because it happens to end in a zero. Alternatively, some strings might be in fixed decimal while others may be in scientific notation. I therefore made a second pass that involved assigning consistent formatting based on the “worst” format of the bunch. If any value was in scientific notation I applied the toPrecision function to all values. If that didn’t apply, I applied the toFixed function so they all matched the value with the most decimal places. That could be annoying when a floating point operation leaves one string with a value like 12.0000001, as sometimes happen, but the extraneous digit would probably be to the right of whatever place the used specified to begin with. If all values were successfully stripped to the decimal point, the values are all displayed as whole numbers.

The first sieve, applied to individual values, is fairly quick. Remember that for the time being these functions are object methods. Once I get everything working I’ll clean it all up to hide the elements that should be private.

The next bit of code does the same thing to either the y- or the y-axis. It cycles through the values to generate a formatted string, then determines whether any string uses scientific notation using by search for the letter ‘e’, or whether any string includes trailing decimals by searching for the ‘.’ character. The latter search term is formatted as it is because the search function actually takes a regular expression as its parameter and the decimal point has a special meaning in regular expressions. Again, a second pass is made to apply the “worst” format consistently. The pixel with of each string is then calculated based on the prevailing font (which should be set just prior to this call) along with a value for the widest string in the group.

I experimented with the graphing tools in Excel to see how it formatted axis values under different combinations of conditions and found that, without going into an extreme amount of coding, it produces similar results in most cases. There is always more one could do, but this first pass is reasonably quick and effective. It often takes human intervention to get decent-looking labels anyway, this this approach seems good enough for now.

If you look carefully at the second block of code you might notice that it’s missing its ending brace. Tomorrow I’ll describe how the information I calculated today, along with the height and angle information, are used to figure out how much space is needed to draw all of the values.

Picking up from last week I’ve finished turning the JavaScript graphing widget into an object, the results of which are shown below. There is a long list of TODOs included in the code that is not close to being exhaustive; I’ll be working those off over the course of the next few posts.

The fun part for me was leveraging a functional parameter. I’d done that somewhere in the mists of time but it was nice to implement it here per my reading and have it work on the first try. See lines 374 and 379 below.

The current form of the graph is meant to support a single type of plot, which is the single curve in segmented colors as shown. I’ve set the object up so it plots the y-value at every pixel along the x-axis and draws lines from point to point after the initial moveTo call. The vagaries of the way pixels work on canvases and the fact that lines and characters are antialiased this technique yields a fairly thick plotted line.

I’ve broken the original functions down so the calculation of the pixel location on the graph is separated from the calculation of the effective value to plot, and that is separated from the function used to repeatedly call for the next point to be plotted. A package like Microsoft Excel plots only from a discrete set of values calculated in cells, and there is usually a fair amount of distance between plotted points on the x-axis. I’ve stubbed in a plotting call that draws specific figures at a specified point (a ‘+’ and an ‘X’ to start) but have not yet implemented anything that plots successive such values from a list. That functionality will definitely be included as I describe how I did the individual sections of curve fit and show the resulting function along with discrete control (x,y values from the steam tables used to derive the actual curve fit) and test (x,y values from the steam tables in the same range of x values but not used to derive the actual curve fit) points.

Today I’ll describe the sizing of characters so the graph object knows exactly how to place them. I hacked together a tool that prints out letters in a specified font and then draws horizontal lines at various offsets from the baseline. A section of that output is shown below:

Looking at the output in a magnifying glass shows how the different characters are laid out. If you were to draw a single character using the fillText function and set the x and y coordinates with left alignment, you’d get output like that shown below. The light green pixel shows the base X and y locations you specified and the values shown in the margin are offsets from that base point.

The base row of pixels for each character is mostly drawn one pixel up from the location specified (the green row). The red line is drawn one row of pixels above the top of each character. The blue line of pixels is drawn one row of pixels below the bottom of the descenders.

Rerunning that exercise for Arial fonts from 4px to 30px allowed me to build the following table.

Remembering that the numbers 0 through 9 don’t have descenders, we see that the 12px Arial digits are drawn between vertical pixels -1 and -9 inclusive, so the actual characters are 9 pixels high. A full-height character would span from 1 to -9 inclusive, which would be 11 pixels high in total, or 13 if the bounding box is included. There isn’t a one-to-one correspondence between specified pixel size for a font and its actual pixel size, though it’s close. The differences are biggest for the smaller specified sizes and decrease as the fonts get larger. It may be that the pixel height of the bounding box is always equal to the specified pixel size for fonts sized 24px and up.

In the course of my research I noticed a discussion of assigning character heights by point size instead of pixel size (e.g., 12pt vs. 12px), where someone stated that points are more accurate. I’d have to repeat this analysis to see, but that’s not going to happen today.

The next item in the queue is to determine the effective height and width of rotated text. That process begins once we know the size of the bounding box for said text.

The process for rotating elements on a canvas is a bit backwards from how I originally learned how to do it. I am used to translating the individual element to the origin (or whatever point I actually want it to rotate around), performing the rotation, and then translating the element back to its original location. The mathematical operations are performed on a copy of the object based on its native dimensions in “model” space. How the object is drawn on screen is a translation from model space to screen space.

In order to rotate items on a canvas object you apparently save the context, do a translation (with values that seem to have the opposite sign of what I would expect, though I’m sure the designers did this to make the operations more approachable for those who don’t know what’s going on behind the scenes), perform the desired rotation on the entire canvas, draw the desired element around what is now considered coordinate 0,0, then restore the original context. It may be that the code isn’t actually doing anything with the information on the canvas while things are being rotated, but doing this way feels impossibly weird and wasteful. Nonetheless if you follow the steps as shown you get the results you want.

In the figure below I’ve worked out the code to draw three bits of text, with their bounding boxes, each normally and then rotated counter-clockwise by 45 degrees. The top example is left justified, the next example is centered, and the bottom example is right justified. The green point (actually the upper left pixel of it) shows the coordinate that defined the base location of the textFill operation and also the point about which the text was rotated. You can adjust things up or down by a few pixels to do the rotation around a point in the middle of the text with respect to its height.

OK, now that we know how to draw the box rotate it, we need to be able to figure out how much space it’s going to take up on the unrotated screen. With that information we can calculate the margins between the edges of the graph area (and axes and tick marks) and the edges of the canvas itself. Then we can work out any minor adjustments.

The x dimensions as shown are the width or height of the bounding rectangle multiplied by the cosine of the angle of rotation. The y dimensions as shown are the height or width of the bounding rectangle multiplied by the sine of the angle of rotation. The sum of x1 and x2 is the total number of pixels covered across the width, and y1 plus y2 is the total number of pixels covered across the height of the text. Once you know that you can make the slight adjustments to any tick marks and so on. If you’re always going to rotate by the same amount you can calculate the sine and cosine values once each and then apply them where needed. If the only rotation you’ll allow is 45 degrees as shown then you can use the constant value (0.7071067812) for both the sine and cosine.

Note that the dimensions only consider the bounding box. The methods described don’t consider whether the characters drawn will set pixels near any particular corner but I don’t think it matters and it would be madness to try. Indeed, you will get more consistent results by not worrying about that detail and placing all of your items in the same way.

Note also that you don’t have to go through the hassle of drawing out the bounding boxes. I only drew those to illustrate the process. You get the base width of the text from the measureText function, the height from the table (or some other method), and the angle from your own definitions. I’m guessing that in most cases you’ll want to right-justify your text and place your items just to the left of or just below the tick marks on the x- and y-axes, possibly with a minimal offset.

I’ve created a jsfiddle here to demonstrate the scripting code in action. It includes the code used to draw the font detail above and the rotation examples. It isn’t the cleanest, but it works.

Finally, I think it would be a good idea to back up and actually implement the basic graph as an object rather than try to account for every possible option up front, so that’s what I’ll present on Monday.

In drawing a graph I’ve created variables for all sorts of coordinates (where do the axes begin and end?) and characteristics (how many tickmarks per interval, how long are they, and what color?). However, rather than define the locations directly they should be calculated indirectly based on the presence and size of other items associated with the graph.

Let’s begin with the top of the graph with respect to the canvas upon which it’s drawn. We have to leave a certain amount of buffer space to make it look nice, we may have to leave space for half the text of half the label at the top of the y-axis (in the left margin as shown), and we may have to leave room for the title of the graph, if one is specified. Given that the origin of the coordinate system is defined to be the upper left corner of the canvas and positive values increase going right and down, we need to allow pixels as follows:

• margin between top of graph area and top of next feature up, either the title or the top of the canvas
• height of the title text, if it is present
• margin between the top of the title text and the top of the canvas
• height of any y-axis label text that extends beyond the top of the y-axis itself
• margin between top of topmost y-axis label and top of canvas, if the top of the label text represents the topmost element to be drawn

We might decide to package up the specification, location, and drawing of axes but the same values will have to be considered. Also, the top label on the y-axis may not be drawn at the top of the axis itself; there may be offsets. It may also be possible for label text to be drawn at an angle.

If there are any other elements added to the upper margin of the graph they would have to be taken into account as well. Similarly, if text for a title is present but is not located in the upper margin (as opposed to being located in the graph area itself), then that would also have to be considered.

Even more interestingly it may be possible to define an axis aligned to the top of the graph, in which case we’d have to account for the length of the longest tick marks, the height of tick labels and an additional axis title, and additional margins as needed. Secondary y-axes are commonly drawn on the the right side of graphs (and more than one can be placed on either the right or left side), but it is uncommon to encounter even one, much less more than one, placed along the top of the graphing area. Nonetheless in order to be completely flexible we’ll go ahead and plan for such an occurrence. (It’s also possible to draw axes in the middle of a graph, as in cases where an origin would be in the middle of the graph area.)

However we ultimately decide to structure things, we’ll need to know the height of the label text we plan to draw before we formally draw it. There are two aspects to this. The first is the height and width of the text itself and the second has to do with the angle at which the text is drawn. The width is easily calculated as shown:

The fillText function itself can take an optional fourth parameter, that specifies the maximum width in pixels. This doesn’t define where line or word wraps take place, it defines the width the text will take (in pixels) after the text is stretched or compressed to the desired width. If the maximum width in pixels is defined, that value overrides the textWidth value calculated above.

Now it gets trickier. There is no function to calculate the height of the text you plan to draw so there are a few ways to approach it.

• Do some outside experimentation with a particular font and size so you know how it will behave–and then stick to using that font and that size. Pay attention to the number of vertical pixels in capital letters and descenders. Note that numerical digits have the same height as capital letters and also have no descenders. This method has the virtues of being completely accurate and completely automated once you’ve done the work up front.
• Perform the experiments described above on numerous fonts and numerous sizes and build a table of height values you can reference.
• Make the height a default or even a user-supplied parameter. This method can generate undesired or unexpected results or can place some of the burden on the user to adjust things, and in a way that may not always be understandable.
• Use one of the other automated or semi-automated methods described at links like this.

You can see from the third option, which actually subsumes the first two, that this is a tricky problem that I’ll discuss in detail tomorrow. I also have a discussion of determining the effective width and height of rotated text in the queue. The two concepts work together, as you’ll see, so I’ll address them both at the same time.

Sometimes it is simple enough to build an object from the ground up in a slow, methodical, organized fashion. By contrast, one may also choose to hack something together to get it to work, play with it, and then refine it. In the particular case of the graphing widget I threw together last week I am clearly taking the latter tack. This is a problem I have solved before but for novel problems it’s often a good idea to work through various trials and prototypes, object-oriented or not. It’s also good to write out the code you want to be able to generate automatically, or at least some examples of it. This ensures that you aren’t trying to debug the resultant code at the same time you’re trying to figure out how to generate it.

Those observations aside, creating a graph on a web page–at least the way I’ve done it–relies on the HTML5 canvas object. There are a couple of ways to proceed that I’ll discuss today. The graph object must be associated with a canvas, but the canvas object itself can be created either as part of the original HTML for a page, which can them be referred to by the graph object, or created as part of the graph object’s constructor and added to an existing page. In either case it is important to remember that the native dimensions of the canvas itself have to be specified at the time of its creation and insertion into the page. Applying style properties that attempt to modify the dimensions of the canvas after it is created and added to the page have unexpected effects, which I’ll describe.

The normal way to define a canvas element in a page is by using the following HTML statement like that shown below. An id must be included so the object can be uniquely referenced, and the dimensions need to be specified as the object is created. If dimensions are not specified the canvas assumes default dimensions of 300 pixels wide and 150 pixels high (in browsers that support the canvas element).

If you want to create the canvas on the fly in JavaScript you must specify its dimensions before you add it to the page as follows: