Basemap layers and map services use a high-performance drawing engine to achieve better performance and drawing quality. This drawing engine provides excellent performance for all supported symbol types.
Because this drawing engine is different from the drawing engine used in ArcMap, you should be aware of some important differences in the appearance of a map drawn in the map service. The Prepare window provides warnings that inform you of many of these differences.
The following sections describe some of these differences in drawing and why they occur.
Text and character marker antialiasing
In ArcMap, text and character marker antialiasing is controlled by the font smoothing settings that are configured in the machine's display settings. These settings are set per user and are not configured as part of the map service.
In the map service, these settings are configured per service and stored as part of the service definition (.sd) file. These text antialiasing settings are set on the Parameters tab of the Service Editor.
Text drawn in a basemap layer is always drawn with the Force option. Note that labels in a basemap layer are always drawn using the display in ArcMap and respect the machine settings mentioned above.
Because the basemap layer and map service drawing engine use a different method of enabling text and character antialiasing, and the algorithms used to execute this antialiasing are different, the rendering of text and character markers may exhibit some differences when compared with the ArcMap display.
Coordinate rounding differences
In ArcMap, elements of the on-screen display are specified with integer coordinates. If the real coordinate of a feature (for instance, a line or a marker) does not lie exactly on that integer coordinate, it will be rounded up or down. This can result in some inaccuracies, particularly in the case of very thin lines or lines with very thin elements such as cased lines. Lines whose sizes are less than one pixel at a given zoom level or display extent are rounded up to one pixel.
In basemap layers and map services, the drawing engine can use subpixel coordinates to place and draw features on the map. This results in greater accuracy of feature placement and symbology.
However, if the map's symbology was originally designed in ArcMap, the appearance may be different in a basemap layer or map service. This is especially evident in line symbology.
See Line aliasing in map services for more information on these issues and how to design line symbols for a given target resolution. In most cases, this issue doesn't occur in basemap layers, since basemap layers automatically correct this problem.
Simple symbols in basemap layers and map services
Simple symbols (simple line symbol, simple fill symbol, and simple marker symbol) as provided in ArcMap are displayed in a manner that can sometimes be inconsistent. Because of these inconsistencies in simple symbols, they may sometimes be drawn differently in a basemap layer or map service. You might be informed of some of these differences by one of the analyzers in the Prepare window.
For instance, simple line symbols using a dash or dash dot pattern do not honor a map's reference scale and are drawn with different spacing depending on the dpi requested. In a basemap layer or map service, these symbols honor the map's reference scale and do not change with the requested dpi.
For simple fill symbols, the Style property is actually not available on the ArcMap user interface, but many developer samples and other third-party code snippets might create these symbols in a map. Styles other than esriSFSSolid are not supported in a basemap layer or map service and result in an error when analyzed.
For simple marker symbols, the behavior of the simple markers changes depending on the size at which they are displayed, causing some variations in their size and shape.
Basemap layers and map services always display marker symbols at the requested size. In ArcMap, when a simple marker symbol's size is below a certain threshold, it will not be drawn any smaller. This means that when this threshold is reached, the basemap layer or map service continues to display these symbols at an accurate size, whereas ArcMap does not, resulting in an apparent mismatch.
Line decorations in basemap layers and map services
For line symbols containing line decorations in ArcMap, such as line arrowhead, the decoration isn't drawn when the decoration is larger than the line length of the feature being decorated. The drawing engine used by basemap layers and map services always draws line decorations regardless of the size of the line. At some scales, this can lead to a more cluttered appearance than in ArcMap, but line decorations are drawn consistently and predictably.
Color in basemap layers and map services
The drawing engine used by basemap layers and map services uses a color management engine. Because of this, some colors may not exactly match the appearance of the ArcMap display.
ArcMap does not utilize color management. In particular, you may notice differences in color when using the following:
- Colors defined in color spaces other than RGB (for instance, colors defined in HSV, CMYK, or grayscale)
- Algorithmic color ramps using HSV, CIELab, or LABLch algorithms
Viewing a basemap layer in ArcMap or the Preview window, opened from the Service Editor, allows you to evaluate the appearance of the map and determine whether the colors and symbology are acceptable.
One thing that can be done to minimize the color differences in a map service is to change the monitor settings within ArcMap. This can be useful when authoring a map for use in a map service.
To access the monitor settings, on any Symbol Properties dialog box, click the drop-down menu on the color swatch and choose More Colors.
On the Color Selector dialog box, click the arrow button in the upper right corner and choose Monitor Setup.
On the Monitor Setup dialog box, change the Gamma setting to 2.2 and click OK to close the dialog box.
This instructs ArcMap to use a gamma value that more closely matches the color profile used by the drawing engine of basemap layers and map services.
Font handling differences in basemap layers and map services
Fonts are handled slightly differently in a basemap layer or map service when compared with ArcMap. There are two main differences:
- Basemap layers and map services do not draw faux italic or faux bold styles. This case triggers a warning when the map document is analyzed.
- Basemap layers and map services do not provide font fallback in cases where a specific character set or typeface is not available.
Faux italic or faux bold refers to situations where a font is not available in the bold or italic styles, or the combination of properties does not have a corresponding font installed. For instance, a user might have Verdana Bold and Verdana Italic but be missing Verdana Bold Italic.
In these cases, ArcMap attempts to simulate these properties by graphically skewing (italic) or thickening (bold) the original font.
This does not often correspond visually to the actual bold or italic version of the typeface. Indeed, for some fonts (such as the Esri fonts designed for use as marker symbols), it does not make sense to display them in bold or italic styles. Basemap layers and map services are displayed with only those fonts and font styles that are available on the system.
Always verify that your text renders as you expect using the Preview window. If you do not see bold or italic properties in your text, check to be sure that you have that particular typeface style available on your system.
Font linking and font fallback
Fonts contain definitions for specific characters (the Latin letter A, Chinese glyph 
[qian], and so forth) in different character sets (such as Western Europe or Cyrillic) as determined by their creators. Font fallback and font linking are methods of displaying characters that do not actually exist in the requested font by drawing them in another similar font that does contain them. These methods are commonly used to display Latin characters with a font that only contains East Asian characters, or vice versa.
In cases like these, the ArcMap display uses Windows GDI (graphics device interface, a graphics system built into Windows) to attempt to link to another font that contains the missing glyphs so the text string can be displayed despite the missing characters. In many cases, this results in an odd appearance or behavior due to mismatches in kerning or other characteristics, in addition to other differences between the original font and the linked fallback font (see image below).
Due to these issues, relying on font fallback to render the proper glyphs is not a recommended practice for any map. In a basemap layer or map service, glyphs that are not present in the requested font are not rendered. Preview your basemap layer in ArcMap or your map service in the Preview window to determine cases in which this occurs.
In general, the best practice is to utilize a font that contains glyphs for the character set you are attempting to use. In the example above, the selected font Arial Unicode MS is missing the Thaana character set. To ensure that the text renders correctly, use inline text formatting tags to switch to a font containing Thaana characters, such as MV Boli.
One way to determine whether a font is falling back is to copy and paste the text into WordPad. Then select the text that you suspect may be using font fallback. If the font name changes relative to the placement of the cursor in the string, this font can be used instead of the font specified in ArcMap.
Font substitution
A similar technology, font substitution, is a method of displaying text in a different font when the requested font is not present on the system. For instance, if a map contains text that uses the font Helvetica but Helvetica is not installed on the machine, the text appears in Arial instead.
Basemap layers and map services can utilize font substitution just like ArcMap can. However, in general, it is a good practice to ensure that the fonts used in the map are available on the machine that will use the map.