CONTACT MI
  Resellers
  Consultants
  MicroImages
  About MI
  Visiting
  Prices
  Send Email
  Reseller Resources

SHOWROOM
  Gallery
  Technical Guides
  New Features
  Testimonials
  Reviews
  World Languages

   View PDF Version (941 Kb)

Font Management.

Background.

Text can disappear or to be rendered in ugly substitute fonts in digitally published documents.  This happens when the original creator of the document has used attractive copyrighted fonts that have not been provided to you.  In this situation, automatic font substitution will take place and you may not even know it.  This is a particularly sensitive issue for cartographic and engineering materials converted to portable document formats, such as Adobe’s PDF and W3C’s SVG.  It can also occur in transferring documents that have been prepared in other programs such as Word, Illustrator, PageMaker, and many others.

When you are provided an electronic document, more specifically a map, from someone else, you would like it to appear identical to the original on your computer screen or printed copy. An official government map is subjected to many microscopic, quality control inspections after it is completed but before it is printed in 1000s of copies.  On the other hand, digitally published map products are not usually subjected to careful checking before distribution.  This can be a critical oversight in cartographic applications.  For example, suppose font substitution causes the annotated depth to an underwater hazard to be moved just a tiny amount.  As a result, the decimal point in the annotated depth of water at mean low tide is obscured and appears to be 11 meters rather than 1.1 meters. This is merely an example of how a font substitution can have serious impact on the use of a digital map.  Obviously, in this example it would be better to use some other form of expression such as 1¹ and 11⁰.

When you use a TNT product to layout a map or other plate, you have the fonts you use installed on that local system or network.  TNT products render your TrueType fonts into the X server using an open source FreeType library, which MicroImages has compiled for the Windows, Mac, Linux, and UNIX platforms.  Regardless of how you acquired your TrueType fonts, if they are available on your computer or local network, you can use them in all the software on that computer.  The problem occurs when you distribute digital products to someone else who may not be part of your local network.  In particular, this impacts on how fonts are managed when TNT layouts are converted to SVG and PDF files in particular.  It is important that the TNT products protect MicroImages and you from font substitution problems and accidentally distributing copyrighted fonts.  You may not consider this serious until you want to widely distribute your digital products freely around the world and in large numbers.

Legal Issues.

The way a font such as TrueType stores the shape of its glyphs (which means, how it is formatted) is what is controlled by its copyright.  But, the exact appearance of each glyph at any size is not covered by any copyright.  You can see why this dichotomy is necessary and has been clearly established in the courts.  If the exact appearance of a copyrighted font was covered by copyright law, then its accurate rendition on your printer would require permission of its owner, and you could be asked to pay a royalty for every character printed with that font.  But the appearance is not protected, so printing 1 or 1000 maps from copyrighted fonts is permitted.  What is not permitted is your transfer of a copyrighted font in its original format to another party without the permission of the copyright owner.  So, you can print all the maps, posters, plates, and so on you choose with PageMaker or the TNT products using the copyrighted fonts you possess.  However, the TNT products also provide you a means to publish your TNT map layouts in several portable digital formats such as PDF, SVG, Illustrator, and others.  This is not equivalent to the use of fonts in a printed map where the glyphs are converted from the digital format to dots on a page.  Providing legal access to fonts used in digital publications is an entirely different matter.

TNT Font Management.

At this point it should be clear that font copyrights have direct impact on the design of all page layout systems.  Font substitution and poor appearance of your layouts leads back to a legal dilemma.  Copyrighted fonts can not be distributed without permission and a royalty payment.  MicroImages can not give you copyrighted fonts, and you can not legally give copyrighted fonts to others without permission.  For map layouts created and used only in your TNT product, this is not a particular problem.  You acquire the TrueType fonts you want in your language, use them in your layout, and print the layout to a printer or a raster.  The problem occurs when a TNT layout is converted to some other digital layout, which also needs the same fonts for accurate rendering at its final point of use.

You have probably already experienced a situation where you obtain a document or page layout whose originator used a font that was not available on your system.  This is particularly common in nations where limited fonts are available in their alphabet.  When it happens, you either have to obtain the font or allow a substitution, which is not desirable in precise cartographic applications.  A font can be missing because it was assumed to be present on every system, not included by accident or choice, the data format has no way to transfer or even identify the font, or the font is copyrighted and belongs to the document’s originator and can not be legally provided.

You can buy the rights to use a copyrighted font or you can obtain it with a software package whose developer has secured the legal rights to distribute that font. If you have secured legal possession of a copyrighted font you can convert it to some other format from which it can then be identically rendered.  In TNT map layouts you can use any TrueType font you have available.  It is up to you to make sure that the party using the converted portable version of this map has access to all these fonts when using the attractive map products you provide.

PDF Font Management.

Adobe has extensive copyrighted and non-copyrighted font libraries and is also the owner of the ubiquitous Portable Document Format (PDF). Every TrueType font contains a code that identifies it as copyrighted or not.  Adobe’s strategy is to block the user of their Acrobat product from embedding any copyrighted font in the PDF file it creates.  If you choose to use an embedded font when creating a PDF, you will be notified that the copyrighted font has been omitted.  That copyrighted TrueType font is then automatically linked in the PDF file.  If the end user of that PDF document (for example, you if you download it) does not have that linked font, a font substitution will be made every time that document is used until that font is secured and installed.  In creating a PDF document, you also have the option to have all the fonts linked only as this will reduce the size of the PDF document.  Usually this all-linked strategy is chosen if you use only the 14 standard Adobe fonts installed automatically by Adobe Reader and any additional fonts you know to be standard with Microsoft Windows in your language.

Polygon Characters.

MicroImages original conversion to PDF was designed as a compromise to overcome the font substitution issue.  An approach is used that ensures your TNT produced PDF maps do not require substitution regardless of the language used and will render accurately at the scale for which they are designed for printing or viewing.  During conversion, every character used is converted to polygons in the PDF file.  Since every original character used in the PDF file is converted to a new format (a polygon), it makes no difference if the font used was copyrighted or not.  Furthermore, since every character is embedded, it can not be lost and preserves the exact shape of the glyph regardless of language.  This approach has worked well as long as the PDF file was used at or close to the scale for which it was originally designed and as long as small fonts (less than 12 points) were not needed at that scale.  When you zoom or print this PDF at a much bigger scale, the shape of the glyphs deteriorates.  Small fonts used for map grid tick marks and fine legend printing appear blocky or aliased as this glyph-to-polygon approach bypasses all the tricks used in font rendering to overcome this effect, such as hinting, anti aliasing, and so on.  Also this method may enlarge the PDF file if a substantial  amount of text is included in the layout.

Embedded Fonts (a post V6.70 prototype feature).

Recently, there have been some complaints about how small characters are rendered in a TNT layout “print to” PDF conversion. The polygon glyph method used in V6.70 and earlier has valuable characteristics when employed for the situation for which it was designed.  This “print to PDF” process will continue to be available as an option.  However, a new TNT to PDF layout conversion is about to be released that follows the Adobe font management model. It embeds any non-copyrighted 1-byte or 2-byte Unicode TrueType fonts you have used in your TNT layout in any language into the PDF document.  If the font used is copyrighted, then it will not be embedded and will be linked only. You decide if you wish to use copyrighted fonts and, if you do, then how you or the user of the PDF equivalent of your TNT layout acquires these linked fonts. 

Please be aware that there are some subtle font expressions you could use now in a V6.70 TNT layout that are preserved in the polygon character method but are not rendered from embedded fonts in a PDF file.  An example would be the new V6.70 font setting that lets you enter a specific percentage to render something like bold or outline, or an angle for italic text, such as 23 degrees.  PDF provides no means of storing this angle for a text character(s), and it will simply become the standard angle for italics in that font.  Another example is that PDF will not define a weight for boldness (glyph stroke width), and this will simply become that font’s standard boldness.  If the target format for your distribution, in this case PDF, does not store advanced font controls, then do not use them in your layout.

Another minor improvement is that circles defined in a TNT layout as a geometric element are no longer converted to polygons in the PDF file.  They are now also geometrically defined in the PDF file and will scale up and down properly.

Linked Fonts (a post V6.70 prototype feature).

As an option you can now also specify that all fonts used in the conversion to PDF are to be linked only.  This will minimize the size of your PDF document.  You would use this option if you confine your use of fonts in your TNT map layout to operating system fonts, supply all the linked fonts separately from the PDF file, or are satisfied with automatic font substitution when it is used.

* Scalable Vector Graphics (SVG)  (a prototype process).

What is it?

Scalable Vector Graphics (SVG) is the newly adopted official World Wide Web Consortium (W3C) open format for the storage, modification, and transmission of “smart” documents ranging from page layouts to very complex map layouts. The complete documentation (over 600 pages) entitled Scalable Vector Graphics (SVG) 1.0 Specification: W3C Recommendation 4 September 2001 can be found at http://www.w3.org.  German, Polish, and Japanese translations of these specifications are also linked at this URL. 

The following are some of the organizations whose product development and/or W3C committee activities have contributed to and/or use SVG:  Adobe, Apple, AutoDesk, BitFlash, Corel, HP, IBM, ILOG, INSO, Kodak, Macromedia, Microsoft, Netscape, Oasis, Open Text, Oxford University, Quark, RAL, Sun, and Xerox.  Obviously this is a well thought out format that will become widely used as it moves into all types of products, not just web products.  

SVG has been optimized for web use so layouts stored in an SVG file are more compact than when converted into PostScript, EPS, or PDF formats.  This compactness is created in part by employing smaller, relative coordinates, rather than the larger, absolute coordinates used is these other formats.  Compactness is a primary consideration for a layout format designed specifically for web use.  However, since its general concept and utility parallel that of PostScript and PDF, it has many immediate and useful applications when used “off the web” because it has a much simpler structure than PostScript, and its contents are open and accessible for other use, while PDF is not.

The SVG file is structured in Extensible Markup Language (XML) where all line information is stored in coordinate form, not as graphical descriptions.  Since it is a markup language extension of HTML, it is easily edited or modified by other software, even a text editor.  Also XML is digitally “smart” so its components can be found and used by other processes.  For example, a line can be selected in an SVG layout as a mouse-over, on-click, on-key press or other event to show a DataTip, a URL, … when viewed in a web browser.  In other words, individual SVG graphic elements can behave in exactly the same way as traditional HTML elements.

SVG can embed rasters internally in the XML structure  (which means, as modified PNG files), thus keeping the entire layout compacted into a single file.  It can also link to other raster formats stored externally where they can be more easily altered, substituted, or modified by other software.  PNG is currently the most common raster format used with SVG as it supports transparency, is an open format, and is compressed.

Since SVG might be viewed as second generation PostScript, smart printers could be developed that interpret and print it directly.  This is less likely to happen today than 20 years ago with PostScript printers.  Now more and more printers, except those of lowest cost, are network aware and use network resources [Internet Printing Protocol (IPP)] to convert (which means, RIP) the document’s format into that printer’s internal format.

SVG is also being called the “new flash,” as it provides animation in web applications that compete with Macromedia’s Flash. At present, just as with Flash, you must secure a plug-in from www.adobe.com for your browser to make it SVG aware.  Many web sites also coerce you into accepting these plug-ins so your web browser may already be Flash and/or SVG aware. It is highly likely that the next significant release of Internet Explorer and Netscape’s browser will include the capability to interpret SVG files.  Once a browser is SVG aware and can display SVG content, it can print it to any printer supported by that browser.  Photoshop, PageMaker, Illustrator and other commercial products either come with, or have plug-ins to use, modify, and print SVG files.  A list of standalone SVG viewers can be obtained at www.w3.org. A news site for keeping tuned to SVG developments is www.oasis-open.org.  If you want to delve into SVG in a physical book, try the new February 2002 O’Reilly book titled SVG Essentials by J. David Eisenberg (see a description at www.oreilly.com).

Use in Geopublishing.

TNTmips, TNTedit, and TNTview now provide the capability to convert a TNT map layout into an SVG file.  In TNT terminology, this means you can now “print to” an SVG file just as you have been able to “print to” PDF, Illustrator, EPS, and TIFF formats.  Each of these converted layouts will contain subtle differences in the map that results.  During this development, MicroImages has converted many available complex test map layouts to SVG.  The resulting maps were compared to those rendered in TNTmips from the original layout to identify and resolve the handling of special TNT cartographic features that you might incorporate into your TNT map layouts. 

Content and Size.

The proof is in the results.  You can download the following comparative sample layouts from www.microimages.com/documentation/SVG.htm.  You will find that each is posted there as a TNT layout with all its linked RVC Project File(s), its conversion to a layout in a PDF file, and its conversion to a layout in an SVG file.  Additional sample layout comparisons will be posted to this web page from time to time and upgraded as changes are made to TNT layout conversion processes, such as the new font handling for PDF files.  At the present time, these SVG files range from 1/6 to 1/15 of the size of the corresponding TNT layouts and associated data and PDF files.  Part of this is because SVG has been carefully crafted to be as compact as possible using the worldwide experience of its many architects, some of whom have been working 25 to 30 years on page layout designs. Some of this size difference is also due to the embedded polygon characters still used in these TNT and PDF layouts.

Sample Geologic Map.

The complex geologic map layout illustrated on the color plate entitled Geologic Map of the Granite Gulch Study Area, Inyo County, California uses many complex map layout features.  For example, it uses CartoScript line rendering and CartoScript legends as well as other new legend features.  These TNT map legend features are being released for the first time in V6.70 and yet they are accurately converted to SVG in V6.70.  This layout and the objects needed to build it are available from microimages.com, all fit in the free TNTlite, and can be used as an exercise to learn how to layout a geologic map and then convert it into a compact W3C compliant SVG file.  This set of sample map layouts can be used to compare for yourself this TNT geologic map layout (7056 Kb), its conversion to an SVG file (353 Kb) and to a PDF file (2785 Kb).  Use your TNTmips, browser, Adobe Acrobat Reader, and/or Illustrator to view these layouts and compare them.  Also note that at this time the SVG file is 1/8 the size of the PDF file and 1/20 the size of the TNT layout and associated data.

Sample Engineering Plate.

The 11" by 17" sample engineering plate illustration in the attached color plate entitled Introduction to Scalable Vector Graphics (SVG) contains several unusual layout components.  For example, the database tables it uses for legends contain symbol fields that were captured just as shown in a geospatial analysis process as CAD objects, which were then simply positioned in this map layout.  These tables convert very accurately to PDF and SVG. This set of sample layouts can be used to compare this TNT engineering plate layout (2576 Kb), its conversion to an SVG file (76 Kb) and to a PDF file (653 Kb).  Use your TNTmips to print the plate at 11" by 17" and your browser to print the SVG and PDF files to the same scale and compare the results for yourself.  At this time the SVG file is 1/9 to 1/35 the size of the other layouts.  If your browser has the Adobe SVG plug-in installed, you can very quickly view this 76 Kb color plate in SVG format directly from www.microimages.com/documentation/SVG.htm illustrating the value of its compactness in web applications.

Sample 7.5' Topographic Map.

The topographic map layout explained in the new V6.70 booklet entitled Making Topographic Maps was assembled into a map layout from USGS digital line graph files.  It can also be viewed in the attached color plate entitled SVG Capabilities.  Its area and scale were selected so that all the objects included with this booklet can be used in the free TNTlite to layout this map.  This layout can be printed in color on 8.5" by 11" paper in TNTlite at a scale of 1:36,000 to provide a very close approximation of a subportion of the original USGS 7.5' printed map.

This layout contains almost every element you would expect in a typical topographic map of any nation.  The attached color plate entitled Layouts Converted to SVG and PDF compare a small portion of this map rendered directly from the TNT layout and from a browser using its conversion to PDF and SVG layouts.  While these results are similar at first glance, a few small differences in the cartographic details are present.  MicroImages is continuing to work with conversion to PDF and SVG to remove these differences created during conversion from the original TNT map layout.

This set of files can be used to compare this TNT topographic map layout (6076 Kb), its conversion to an SVG file (275 Kb) and to a PDF file (4684 Kb).  Use your TNTmips to print the plate at 8.5" by 11" and your browser to print the SVG and PDF files to the same scale and compare the results for yourself.  At this time the SVG file is 1/15 the size of the PDF layout and 1/20 the size of the TNT layout.

Georeferencing.

Conversion to SVG in V6.70 follows the W3C 1.0 Specification of 4 September 2001.  The proposed Scalable Vector Graphics (SVG) 1.1 Specification: W3C Candidate Recommendation  30 April 2002 located at www.w3.org covers the incorporation of georeference information within the SVG file. Thus, V6.70 does not convert the TNT georeference into the SVG file.  Since the SVG file is open and will eventually include georeference information as text, it will be very easy to extract, alter, or use it in any program.  However, an exhaustive list of map projection and datum parameters must be referenced in using the information in the georeference.  In the V1.1 Candidate Recommendation the W3C recommends the following approach be adopted in the final V1.1 Recommendation.

“In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, SVG encourages the use of a common metadata definition for describing the coordinate system used to generate SVG documents.

“Such metadata should be added under the ‘metadata’ element of the topmost ‘svg’ element describing the map. They consist of an RDF description of the Coordinate Reference System definition used to generate the SVG map.

“The definition should be conformant to the XML grammar described in the OpenGIS Recommendation on the Definition of Coordinate Reference Systems [OpenGIS Coordinate Systems].  In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS.  The first axis of the described CRS maps the SVG x-axis and the second axis maps the SVG y-axis. Optionally, an additional affine transformation is applied during this mapping, this additional transformation is described by an SVG transform attribute that can be added to the OpenGIS ‘CoordinateReferenceSystem’ element.”

At present the TNT products can not use an SVG file in any process, so georeferencing is not needed in V6.70.  Georeference information could be added temporarily at any time by creating an ArcWorld type file such as *.svw containing this information.  However, it is doubtful that at this time there is any other application using SVG that employs an SVW georeference file.  If you obtain or develop an SVG application requiring a georeferenced SVW file before V1.1 is adopted, this approach can be easily implemented for you.  The first obvious application of georeferencing would be in geographically cataloging, merging, or mosaicking SVG files.

Editing.

The non-raster portion of your SVG file produced from a TNT layout is simply text.  While viewing any of the sample SVG layouts at www.microimages.com/documentation/SVG.htm in your browser, use the right button menu and select View Source.  A new window will open showing all the source text describing this SVG layout to your browser.  Note that another choice on this menu is Save SVG As… to copy this SVG from within your browser into a file on your hard drive. 

However you obtain an SVG file, it can be viewed as simple “marked up” text and modified in any simple text editor such as VIM or in Microsoft Word. The attached color plate entitled Editing SVG illustrates some SVG text.  Like any markup language, it can be confusing to view it as simple text.  Since it is XML, it can be logically organized, presented, and edited by free or shareware XML editors.

If you wish to interactively add and edit graphic and text components into an SVG file, then the Jasc WebDraw editor just introduced this year can be purchased for this purpose.  It permits interaction with the graphical components of a view of the SVG file while presenting the corresponding editable XML text in another view.  Jasc WebDraw can be downloaded for trial use or purchased for US$179 from www.jasc.com.

Adobe Illustrator 10 directly creates, uses, and edits the SVG layouts produced from a TNT map layout as illustrated in the attached color plate entitled Editing SVG.  So now you have 2 paths into Adobe Illustrator from a TNT map layout.  Convert to the Illustrator format if you are going to stay within and make the final prints in Illustrator or some other product using that same format.  Or, convert to SVG if you want to modify the SVG format and move it on to a browser or some other web oriented application.

Using JavaScripts.

Concept.

JavaScripts can be embedded in an SVG file. It will then be interpreted by the program reading the SVG file, such as your browser, to provide display, control, and analysis functionality to your SVG map.  For example, every label on the map can be set up to link to a different URL. This is called “event-based scripting” and is illustrated by the JavaScript described below that is inserted into your TNT to SVG layout conversion to provide layer control.  You can insert and edit your JavaScripts in your SVG file in your text editor or other tools.  However, products like Jasc WebDraw make it much easier to create, insert, and test your event-based and other JavaScripts as they are inserted into an SVG file.

Direct Layer Control Example.

Standard Adobe Script.

The Adobe SVG plug-in for your browser adds its standard event-based JavaScript to any SVG file viewed in it.  When your browser is showing an SVG source, pressing the right button of your mouse (control and mouse button on a Mac) on the view is an event that will run this JavaScript to pop in a right mouse button menu.  If you want to see how this works use your browser to view the small SVG file (48 Kb) containing the MicroImages logo at www.microimages.com/svg/logo.svgz. This appended JavaScript allows you to select from several event-based options on the right-mouse button menu.  Simply use your left button to select an optional operation on the SVG logo file, which is now temporarily resident on your local machine but confined within the browser’s sandbox. 

The redisplay options this JavaScript provides for selection from the right mouse button menu are Zoom In, Zoom Out, Original View, Higher Quality, Pause, Mute, Find…, Find Again.  It also provides options that operate on the temporary SVG file: Copy SVG, View SVG, View Source, Save SVG As …  As noted earlier, View Source permits you to directly view all the XML text making up this SVG file, including all of this JavaScript.  The Save SVG As … option permits you to save the temporary file as an SVG file on your system.  In this fashion you can capture the SVG file and the JavaScript it contains.  This file can then be used later in the browser or some other program that understands SVG, such as Adobe Illustrator or the WebDraw editor.

Customizing the Adobe Script.

The original Adobe JavaScript was added to the temporary SVG file in the browser and saved in the local SVG file. You can now extract it in any text editor and modify or expand it.  If this modified JavaScript is substituted for the Adobe standard script in the SVG file, it will redefine the right mouse button menu selections for the left button in your browser or other program. 

To illustrate how to customize an SVG file, MicroImages’ conversion from a TNT map layout to SVG file incorporates a modified JavaScript for the right button.  If you view any of the 3 sample SVG maps introduced above from www.microimages.com/documentation/SVG.htm, you can try these new options added to the right mouse button menu.  The modified selection panel for the sample engineering plate is illustrated in the attached color plate entitled Introduction to Scalable Vector Graphics (SVG).  Note that all the standard Adobe options are retained and the following options are added:  Layer Visibility, Save Current View, Change Color, and MicroImages Home. The added MicroImages Home option simply opens a new browser window at microimages.com. The other options illustrate how the JavaScript you deliver with your SVG file (in other words, you add in) can add interactive geospatial functionality to your SVG map layouts.

Layer Selection Option.

Your original TNT map layout may use many groups, each with one or more layers (for example, the Quake Hazard map has 35 layers distributed in 26 groups).  These are preserved in the XML structure in the SVG file.  The custom Layer Visibility option exposes a new menu with a check off box in front of the name of each layer in the original TNT layout.  This Layer Selection menu for the sample engineering plate is illustrated in the attached color plate entitled Introduction to Scalable Vector Graphics (SVG).  By default all layers are initially checked to display (turned on) so everyone automatically views your complete map.  Using the left mouse button you can toggle any layer to not display (turned off) and your browser will immediately redisplay the SVG file without showing this layer. The added Save Current View option on the menu saves the SVG file with the “off” layers marked so they are turned off if the SVG is redisplayed in the browser.  However, all the turned off layers are still in the SVG file.

Change Color Option.

When you use the right button to show the modified Adobe right mouse button menu, the modified script stores that screen position of the mouse cursor.  The Change Color option then allows you to change the color of the nearest line or surrounding filled polygon to blue, red, or yellow (uses the same original line or polygon element as in TNT map layout).  In other words, you can select a line or filled polygon as you open the right mouse button menu, and then use this menu option to change its color.  

Map Applications to Go.

A complete TNT geospatial analysis product is required to import, analyze, and layout the extensive variety of geodata sources and layout options available for use in a complex map meeting rigorous cartographic standards.  However, once it is assembled and converted into an SVG format, it has many other subsequent uses by other software or software that you develop.  For example, after trying the modified simple event-based right button JavaScript options added by MicroImages to your SVG file, it will become apparent to those inclined to do some scripting that other higher level interactive applications can be added relatively easily into an SVG file for interpretation in your browser or some other application.  The following provide good tutorials and sample source scripts (always obtainable via your right mouse button) on how to add interactive, cartographically oriented features to your SVG map file for use via a browser or other program: www.carto.net and www.kevlindev.com.

Hatch Patterns.

Hatch pattern fills for polygons can be used in a TNT map layout. They can not be transferred as scalable line descriptions for use in formats such as SVG, Illustrator, or PDF line/coordinate oriented layouts.  TNT products render hatch patterns by converting each into a raster as a color bitmap at the scale desired for the resolution of the printer selected.  This bitmap is then clipped into the polygon that contains it as the print file is created.  This has been an adequate approach when used within the TNT products since pen plotters, which can only draw hatch lines, are no longer used, and print files are matched to the designated printer.  However, it is not a suitable basis for conversion to line and coordinate oriented layout formats such as Adobe Illustrator and SVG, which require graphical descriptions of the hatch lines and how they should be clipped.  The current TNT method of hatching also causes complications in managing and retaining hatch patterns originally specified in national cartographic symbols sets as line descriptions.  Line descriptions should be preserved in TNT products as styles and passed on as compact line descriptions to other layouts.

Rasters as PNG.

When a TNT layout is converted to SVG you have the option to embed the Portable Network Graphics (PNG) files into the SVG file or create them as standard PNG files linked to the SVG file.  Tools created by others to use SVG files will usually use these PNG rasters provided via either method.  If you have no intentions to alter the PNG files once they are in SVG format, then embed them as this secures all the components of that layout in a single file.  If you wish to alter the image contents of your layout, then keep the rasters as separate linked PNG files.  An example of the use of this second approach would be to substitute the PNG file used in an SVG map layout created only as a framework for a series of image maps or to use the SVG file as a framework for even more dynamic image feeds (for example, weather radar images).

SVG Font Management.

W3C has an even bigger font issue than PDF, as SVG files ranging from tiny animations to large maps will zip around the world by the many millions each day.  PDF is generally used for complete documents whereas SVG is designed to move around or gather up many XML components for a single view.  Thus font copyright, availability, and substitution issues that vary by nation are of particular importance.  For example, it would be desirable to produce multiple translations with an SVG map, and let the browser choose the language to render it in.  This is entirely possible in the SVG XML structure where the font and language could be obtained as needed from some server on the web or multiple label layers in different languages embedded in the XML for the map and selected by the user.  To accomplish this, the fonts used must be in the international public domain and available to anyone, anywhere.  Heading toward this, SVG has its own open, public font description, and programs and libraries to convert fonts to this format are being created.

It is not yet clear to MicroImages how this conversion from TrueType to SVG font should be made.  TrueType has features that are difficult to accommodate in SVG, and Microsoft is introducing an even more complex ClearType font and text rendering strategy.  Therefore at this time during a conversion, all the fonts you used in your TNT layout will be linked, not embedded, in your SVG file.  As a result, all the considerations in the sections above regarding the use of linked fonts with PDF files also apply here to SVG files (for example, automatic substitution, copyright considerations, and so on).

Controlled as a Printing Feature.

Just as with “print to” TIFF, “print to” PDF, “print to” Illustrator and others, some control is exercised over how “print to” SVG operates depending upon whether or not you have purchased the optional P15 large format printer support for your TNTmips, TNTedit, or TNTview. If you have P15 support, the conversion preserves the full resolution of the coordinates and images in your XML component objects in the SVG file.  This will permit enlarging (for example, scaling up) your subsequent application of the SVG file to any level commensurate with the coordinate accuracy of the original geodata imported into the TNT products. 

You can print your map layouts to an SVG file(s) even if you do not have the P15 large format printing option. This SVG file will have reduced coordinate values, which have been rescaled to preserve only that accuracy needed to print to 11" by 17" size at 300 dpi.  Also, just as in other “print to” formats, the rasters in the TNT layout will be scaled to fit into their positions in the layout at the 300 dpi resolution. 

Export.

A vector object can be exported to SVG files with attributes.  A matching raster object exported separately as a PNG file can be linked to an SVG file by editing its XML source.  This produces a single SVG file with a raster and vector overlay for use in a browser or other SVG aware products.  SVG can also be linked to other raster formats such as JPEG and GIF and used in some application, such as an Adobe modified browser. 

Spatial Manipulation Language (SML).

Complex SML scripts have and continue to be written to automate large production processes, interactive applications, and visualizations.  These are considered proprietary property by their owners who create them for some competitive advantage.  As a result they are not available to MicroImages or any other.  Also they are often created and used in the context of the problems and objectives of a specific user and thus are not of generic interest or use.

The following is a verbal description of a script written to rotate a complex 3D visualization of a section of a potential tunnel bore.

Please find attached a zipped RVC with a 3D simulation.  These 3D vectors are the result of several SMLs and show a section of the subway in [a city].  It might be quite difficult to understand, but our geologists here like this result very much.  The SMLs facilitate the:

a) preparation of reference layers for the geologist’s interpretation, which is the drawing and attributising of strata lines along cross sections, which means,  in 2D.

b) converting these various cross section lines into 3D-lines (the thicker lines) and eventually

c) interpolating those 3D-lines into surfaces, from which those wire mesh vectors are produced.

All attributes are created and attached automatically, as well as display parameters.

So it is highly automated and corrections can be carried out easily, even though direct editing in the 3D model would be much more comfortable.

Reliability Testing.

MicroImages does not deliberately make changes to SML that would change or alter the operation of any possible existing scripts.  If expanded capabilities are needed, they are added via new, not revised functions and components.  However, improvements and adjustments are made daily to our TNTsdk library functions/classes that are the basis for recompiling the SML/X and SML/W functions/classes.  These can cause changes that cause problems in earlier SML components and, thus, in your scripts.  It is simply not possible for MicroImages to continually check these thousands of SML components.

To help pinpoint these errors and inadvertent changes in SML, an automatic testing procedure was initiated several months ago.  It is rather simplistic at this time and only a fewtest scripts are available to be evaluated in it.  It simply runs the sample scripts we have every day with the latest daily build of SML/W and SML/X.  If the script does not complete and produces errors, the reasons for this are investigated and errors corrected until the script runs again.  This procedure works well for a first effort but is quite limited in scope due to the limited kind and complexity of the available test scripts.

Unfortunately, due to the proprietary nature of your SML scripts, few complex scripts are available to exercise and test the functions/classes in SML.  Furthermore, only batch oriented SML scripts can be used at this time, since any user input required to run the script to completion is not available in this test.  Any proprietary batch SML scripts you would care to supply would be kept confidential and used only for this testing purpose.  For example, the visualization script described above does not require any input.  Alternately, you can contribute test batch scripts that continually test features in SML that you consider fragile and of paramount importance to your efforts. If any of this is of interest, MicroImages can arrange a means for you to email or FTP your test scripts to be used with this test set.  

View PDF Version (941 Kb)

Go to Next Section

 

©MicroImages, Inc. 2008 Published in the United States of America
11th Floor - Sharp Tower, 206 South 13th Street, Lincoln NE 68508-2010   USA
Business & Sales: (402)477-9554  Support: (402)477-9562  Fax: (402)477-9559
Business info@microimages.com  Support support@microimages.com  Web webmaster@microimages.com

---