Creating your own map template, or using the generic ones, you have the ability to print text elements with ArcGIS for Server layouts. But how much text can you store and print properly without it being truncated or running off the printed page?

What’s in a name?

The generic print templates have custom “Title” and “Author” text boxes and these properties are exposed in the layoutOption object so you can change the text in your application. But just because the property says “Title” and “Author” doesn’t mean you can only use them for that specific purpose. You can store any text, as long as it fits in the limited text box. If creating your own MXD template, you have much more control over this. You can make the Title/Author text boxes much larger (fixed width, multi-line, etc), or you can even add more custom text boxes to the layout as you aren’t limited to just Title/Author when building your own.

How long is a piece of string?

When we print text elements with ArcGIS for Server, you should probably determine how much text you can truly include - this will help the end users, the application, and the printouts! But how long is a piece of string (sic)?! If you assume all characters of text are the same length, you will quickly find out the text boxes don’t agree with you. For example, a “W” character uses much more space than the “i” character. But how much more? Naturally, it depends.

To determine length, a much better approach than counting letters or words, is to count pixels. Assuming you are trying to avoid a custom python print task and using straight forward MXDs, the pixel width of the text box is constant since all the font properties have already been set in your Map Document. Just type some text into your text box until it’s full, then calculate the pixel length from that text and you will have your maximum size. Next, add some code to your application to determine the user input length and make sure it doesn’t exceed the maximum. Easier said than done? Keep reading.

Pixel Magic

How do you calculate pixel length, is it some crazy equation showcased in the movie ‘Goodwill Hunting’, or from your favourite String Theory textbook? Not even close, and not even complicated! Here is an example when working with the ‘Title’ text, although will work with any custom text too:

  1. Open your custom MXD template (or Esri generic) and type random text into the title text box until full of text. Copy that text to  your web app and remove from text box (doesn’t need to be saved in the MXD). This text is your maximum length placeholder.
  2. In your web app, create 2 text boxes: One for the user to enter text dynamically (id=‘txtTitle’), a second one with your dummy text from step #1 included as it’s text (id=‘txtTitleLength’).
  3. Both text boxes: Set identical font, font-size, font-type (important to compare pixel length)
  4. txtTitleMaxLength: remove all width styling and make ‘inline-block’. Note: you can hide this text box later so users don’t see it. For now, just keep it while testing.
  5. Calculate the length of the txtTitleLength text box using the following code (assuming jquery in this example): $(“txtTitleLength”).width();

    • Swap the user text from txtTitle into txtTitleLength, and get the width again.

Phew, we have the pixel length of our max dummy text, and the user text. The outputs from step #5 are the number of pixels we have to work with.  I recommend keeping the txtTitleLength textbox and dummy text as part of a JavaScript calculation so you can always determine the max length available based on user browser settings. Just hide txtTitleLength from the interface.

Help users help themselves

We now know the maximum number of pixels, and the user text pixels. As long as the width the user text less than the dummy text, you are good! Now when printing Custom Text Elements with ArcGIS for Server you can feel more confident that the text provided by the user will fit the layout. This also works with large text boxes with fixed size and multi-line text.