External Mapping Files

While setting up the Export or Import variables, the external mapping files are initially tested for validation. At the top of each file is a check line indicating the external package to which the file is related. The check line must be of the form:

AVEVA TargetPackage

For example:

AVEVA FrameWorks

The target package name must be as it appears in the data list, !!SDNFExtProgList (refer to Customise SDNF for further information). The list is picked up automatically by the Export and Import forms.

Note:
Tab characters are not permitted in the mapping files, as they interfere with the field separation.

Comments may be included in the mapping files. They are indicated by a hash (#) character as the first non-blank character on the line.

Blank lines are also permitted.

Error and Log File Messages

Data Fields in Profile Mapping Files

Because AVEVA element names cannot contain spaces, space-separated mapping files receive special treatment to allow spaces in external Profile names, but not in AVEVA names. A description of the individual fields in the Profile Mapping Files is given after this section.

The file format has four or five fields per line, four fields are used for old format mapping files where the AVEVA profile name is either the Catalogue or the Specification name. Five fields are for either the newer format (version 2) or the Block format mapping files. These include both the AVEVA Catalog and the Specification name. Version 2 files are differentiated from the Block format files by having a different header line which includes a single version number, rather than a description of the column widths. The Block format file is recommended.

The fields are read in the order given.

1. The first, and possibly the second, fields are the AVEVA profile names (with no leading, trailing or embedded spaces).

2. The rightmost field is the Profile type (with no leading, trailing or embedded spaces).

3. The penultimate field is the Steel Standard (with no leading, trailing or embedded spaces).

4. The remaining (second or third) field is the external profile name, once the leading and trailing spaces have been removed.

You can specify which separator the interface uses to discriminate between fields. Refer to Customise SDNF for further information.

CSV Format for Profile Mapping Files

You can also use Comma Separated Variable (CSV) format for the Profile mapping. In CSV format, the fields are separated by commas rather than by spaces. The names of profiles must not contain commas, but the external profile names can still contain spaces.

CSV format allows you to manage the mapping files in a spreadsheet program. If you are constructing a CSV file by hand, you should be aware how a CSV file handles commas in fields. Again, CSV files, managed in a spreadsheet program, can be converted easily to Block format.

Profile Mapping Files

There are a number of available formats for the mapping files between AVEVA catalogues and those of external 3D steel detailing packages. The mapping files indicate a correlation between the profile in AVEVA and its equivalent in the other system, to which, or from which, data is to be transferred. It is your responsibility to make sure that any geometrical modelling required in either system is suitably reproduced in the other. The mapping files supplied are modifiable and extensible.

Note:
It is assumed that the package importing the data performs the mapping to local names. Any system exporting data exports its own local names without performing any translation process whatsoever. This interface checks that there is a valid mapping for a Profile before it is exported, even though the local AVEVA profile name is still exported. If the SDNF output file is inspected, this can be a cause for misunderstanding as the AVEVA profile names are visible, and not the names translated for the target package.

Record Structure for Profile Mapping File

The mapping file consists of records of AVEVA catalogue or specification profile name matched with the external profile name and two other fields giving the origin and profile type (shape code) as recognized by the external package.

The profile names for the external package must be ascertained and matched correctly with the equivalent application name.

Steel Standard Field

Some 3D steel detailing packages cannot mix profiles from more than one steel standard at the same time. The external package may stop if it finds a profile from a different steel standard. Therefore, we need to record the origin of the profile in the third field, the Steel Standard field, which is currently codified as:

If you want to include profiles or joints from another standard or country, you must add a new and unique identifier.

Profile Type Field

The Profile Type field defines exactly what type (shape) the profile is. There may be many occurrences of the same profile name in the 3D steel detailing package, but used in different manners. For example, only those T shapes which are derived from cutting up I shapes may be stored and recorded in the file. For example:

Similarly, angles (L shapes) are further classified if they are to be placed back to back by either the long or short leg to form a double-angle profile. For example:

We have assumed that double angles may have a gap (for example, 0 or more) corresponding to type 10, but to differentiate between short-leg and long-leg double angles we have used type 10 to identify the long and type 11 the short leg back-to-back double angles.

The profile type codes for the old application catalogue are:

Note:

Types 10 and 11 are often not available in external 3D steel detailing packages as a single Catalogue entry. In those cases, they must therefore be modelled as two single sections.

If Bent Plates are to be treated as angles with regard to, for example, mirroring, they must be classified as angles (type 9).

Extend the Profile Mapping File

To extend the facilities provided by the system, the ASCII file may be extended. Once you have found a match between the application catalogue profile name and the equivalent profile in the external detailing package, the name matching may be added to the file, along with the catalogue origin and profile type.

Sample Profile Mapping File

The actual shape code number is not critical: the combination of the shape code and the country code IS critical. The combination of the shape and country codes enable us to identify exactly which AVEVA Catalog item is being used. The list of country codes has been extended for the new AVEVA structural profile catalogue. This allows you to differentiate between the old and new catalogues, and the equivalent shapes in each catalogue. This means that we can apply treatment, such as rotation or mirroring, to any particular shape.

The example displays a short extract of a Profile mapping file between the application and Intergraph FrameWorks.

Note:
The identification line at the top of the file which indicates the Target Package.

Also that it is not complete in any way.

AVEVA            FRAMEWORKS

HE280A          HEA280          EUR 20

HE280B          HEB280          EUR 21

L35x5           L35*5           EUR 9

L40x20x3        L40*20*3        EUR 9

OD355.6x12.2    PD355.6*12.2    EUR 13

OD355.6x8       PD355.6*8       EUR 13

T45             T45             EUR 6

T50             T50             EUR 6

T60             T60             EUR 6

T70             T70             EUR 6

T80             T80             EUR 6

T90             T90             EUR 6

UNP100          UNP100          EUR 8

UNP120          UNP120          EUR 8

There are three formats for Profile mapping files. The first two formats may be space or comma separated. And are indicated as such by setting the !!SDNFProfSep variable as !!SDNFSpaceSep or !!SDNFCommaSep.

The first has been described here. Each line in the mapping file contains 4 fields - the AVEVA Catalog or specification profile name, the external profile name, the country code and the shape code. Interpretation of the first field depends upon the !!SDNFProfMapRef variable as 'SPRE' or 'CATR'.

In this format, each line in the mapping file contains 5 fields - the AVEVA Catalog profile name, - the AVEVA specification profile name, the external profile name, the country code and the shape code. Which of the AVEVA columns is picked also depends upon the !!SDNFProfMapRef variable. In order to distinguish this file from the previous format, the header line has an additional version field.

For example:

The third, and now preferred, format is the Block format, a space separated file that has been pre-processed to facilitate more rapid parsing. Again, each record has 5 fields selectable according to the !!SDNFProfMapRef variable. This file has a header with more fields describing the column sizes for the file.

For example:

This file type is indicated by setting the !!SDNFProfSep variable to be !!SDNFBlockSep.

Error and Log File Messages

AVEVA ABSI/SDNF Mapping File Converter

This is a tool to format the profile mapping files shared by the SDNF and ABSI interfaces and AVEVA E3D Structural Design from CSV files to a format for more streamlined use. It transforms input files, including formulaic entries into a block format where we know how big each field is. This makes the reading of the files much faster.

In order to speed up the interface the top line of the mapping file gives details of the field widths in the rest of the file.

For example:

COMMENT;CATREF;SPREF;EXTERNAL;STANDARD;SHAPE

#;EU_BF100x7;EU-BF100x7;;EU;21

;EU_CF_CHS101.6x2.0;EU-CF-CHS101.6x2.0;=CHS{1}*{2};EU;7

;EU_CF_CHS101.6x2.5;EU-CF-CHS101.6x2.5;=CHS{1}*{2};EU;7

;EU_CF_CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU;7

Goes to:

AVEVA BOCAD 5 19 19 19 3 2

EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0 EU 7

EU_CF_CHS101.6x2.5 EU-CF-CHS101.6x2.5 CHS101.6*2.5 EU 7

EU_CF_CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU-CF-CHS101.6x3.0 EU 7

The converter does run stand-alone from the application install folder, but it is also accessible from the Control menus on the Export and Import main dialogs for both SDNF and ABSI interfaces.

The format of the file is as follows:

[PDMS Catref name, PDMS Specref name] [External profile name, country code, shape code]

For example:

EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0 EU 7

The converter does run stand-alone from the application install folder, but it is also accessible from the Control menus on the Export and Import main dialogs for both SDNF and ABSI interfaces.

The format of the file is as follows…

[PDMS Catref name, PDMS Specref name] [External profile name, country code, shape code]

For example:

EU_CF_CHS101.6x2.0 EU-CF-CHS101.6x2.0 CHS101.6*2.0 EU 7

The shape and country codes are internal to us to help us uniquely identify the profile. At translation time, using a combination of these fields we can build a dictionary for profile mapping between PDMS/AVEVA E3D Design and AVEVA E3D Structural Design, for example.

The Convertor

It is accessed from the SDNF or ABSI interface main windows:

It can also be accessed if you set up a link to run the program from within the application installation.

Operation

There are 4 main combinations of settings:

Case 1: Source folder unchecked/ External folder unchecked

(user specified output file name - allows producing temporary or copy files)

Input source file and target file names. Transform source file -> external file

For example:

Bocad-BS.csv -> externalFileName.map

Case 2: Source folder unchecked/ External folder checked

(output file name derived from input file name)

Input source file and external folder names. Transform source file -> external file in target folder

For example:

Bocad-BS.csv -> Bocad-BS.map in external folder

Case 3: Source folder checked/ External folder unchecked

(merge all CSV files into a stated file)

Input source folder and external file names. Transform and merge all source files -> 1 big target file

For example:

(Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv) -> externalFileName.map

Case 4: Source folder checked/ External folder checked

(bulk processing of multiple CSV files)

Input source folder and external folder names. Transform all source files in source folder -> 1 external file per source file in external folder

For example:

Bocad-ASNZ.csv, Bocad-BS.csv, … Bocad-US.csv -> Bocad-ASNZ.map, Bocad-BS.map, … Bocad-US.map

The latter 2 options enable you to build larger compound mapping files of various sets of standards. By default, we issue a single file per standard. However, you are able to concatenate various standards into your working set using the bulk options.

Small Details

The CSV file separator can be ',' ';' or tab. You will have to tell the spreadsheet package what the field separator is as you open the source file.

The formulae can use either '{}' or '()'. Formulae also begin with '='. This is often an indicator for internal formulae. In order to see the formulae without the system making any attempt to evaluate them, you will have to turn this feature off, by showing the fields only.

The translator saves the previous configuration settings in the first place it can find out of the folders pointed to by the environment variables AVEVA_DESIGN_USER, PDMSUSER, TEMP.

Workflow for Mapping file conversion

The workflow is essentially converting a .csv file to a .map file.

You will spend your time in Excel editing the CSV file. When done, it should go through the mapping tool to produce a .map file.

If there are errors, the converter produces an annotated .map.csv file to enable you to see where the problems are. Ideally the problems should be rectified in the main source CSV file and the file converted again.

For both AVEVA E3D Design/PDMS and AVEVA E3D Structural Design, the source file for the mapping file production will be the .csv file. The resultant mapping file is shared by the SDNF and ABSI interfaces as well as the AVEVA E3D Structural Design product.

The conversion process can rely on other tables and files that are relevant to the external package. The External data folder is the folder that contains the converter related files, for example: the alle_prof.inp, profitab.inp and the generic.lis files for AVEVA E3D Structural Design. For the converting of mapping files for other applications there is a recommended file structure to aid the conversion. We will have another folder with the profile lists and anything else we need. This is described in detail below.

The other targets that the tool lists are more for round-tripping AVEVA E3D Design->AVEVA E3D Design or PDMS->PDMS. In this case the 2nd and 3rd columns will be the same now. If you used the CATR, the 1st and 3rd columns would be the same.

Installed Mapping Files

We supply mapping files for the application and PDMS to allow round tripping of data, for AVEVA E3D Structural Design and a sample set for Intergraph Frameworks, the originators of the SDNF file format.

How one uses the Frameworks files as a template to build mapping files for other targets will be described below.

The source CSV files are in a folder <target>_CSV, and the output mapping files are in a folder <target_Maps>.

The system is configured to pick these up automatically using the BLOCKMAPS environment variable. If you place them somewhere else on your file system, you will have to tell the interfaces where they are. That is described in the ABSI and SDNF interface documentation.

The source file text below:

Is translated to:

Building your own mapping files for any other target application

There are basic lists that the interfaces and converter rely on.

Old catalogue shape codes

New Catalogue shape codes

Design Parameter Shapes

Catalogue Country Codes

It must be noted that these lists are not fixed. If you wish to create a new country catalogue, then create a new country abbreviation and then use it consistently. So too with the profile shapes. The lists indicated are related to the supplied catalogues and gtypes. If you create your own catalogues and GTYPEs, just set up a new meaning. The interface documentation also describes the requirements of catalogues, plines and orientation mapping files that must be satisfied for a successful translation.

Source CSV File

The source CSV file is of the form:

COMMENT;CATREF;SPREF;EXTERNAL;STANDARD;SHAPE

#;EU_BF100x7;EU-BF100x7;;EU;21

;EU_CF_CHS101.6x2.0;EU-CF-CHS101.6x2.0;=CHS{1}*{2};EU;7

;EU_CF_CHS101.6x2.5;EU-CF-CHS101.6x2.5;=CHS{1}*{2};EU;7

;EU_CF_CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU-CF-CHS101.6x3.0;EU;7

In the example above, the ';' character is used as a field separator. The converter also allows ',' and the tab character. To manage the file in a spreadsheet program, you will have to tell it which character to use.

There are 6 columns:

The top line of the file must contain these headings, or precisely 6 fields which are taken to be column names.

By using a "=" in front of the external profile name, the name will be interpreted as a formula that defines value substitution. This means that the formula will be interpreted by replacing the {n} by the n'th group of number of the name contained in second column. Up to 9 substitutions are allowed. The characters that are considered as a number are: 0123456789 and '-' and '/'. The characters '-' and '/' should be enclosed by at least one digit on each side to be consider as part of a number group.

For example:

The new csv file will have the formulas interpreted, in the example:

Supporting external profile data files

For generating mapping files for applications other than AVEVA E3D Structural Design, AVEVA E3D Design or PDMS, there is a folder and file structure you will need to follow. The files for Frameworks will provide a template. However, the TEST mapping file is the only one that has been completed

There are 3 separate folders: the source CSV files, the resultant mapping files and the supporting data files.

The important file to note is the shapes.txt file. This is a file that links the shape to the file tables in the standard folders below. Below is a sample of the shapes.txt file.

This indicates, for example, that files C.txt (line 7) are related to the shape code 4, which you will see above refers to C shapes. The profile tables related to the external package may then be sorted into folders named according to the standard to which they apply. This will assist in housekeeping. As this is just a sample data set, the C.txt contains just 1 entry, UNP220. The interface now has enough information to perform the conversion.

Editing the CSV File

The entries are not necessarily in the same order as input, this is because they are sorted on output as well for ease of searching.

Material Mapping Files

Elements cannot be transferred through the SDNF if they do not have a valid material associated with them.

The existing application material description may not be recognized in the external 3D steel detailing package; consequently, there must be a means by which we can translate the material description between systems. A Material mapping file is available which relates the application text description of a material to that output to, or found in, an SDNF file.

Note:
You can modify and extend the mapping file.

There are two similar mapping files required: one for the application and the other for the 3D steel detailing package. Greater modularity and independence of each component in the interface is allowed for.

Note:
It is assumed that the package importing the data performs the mapping to local names. Any system exporting data exports its own local names without performing any translation process whatsoever. The interface, checks that there is a valid mapping for a Material before it is exported, even though the local application material text is still exported. If the SDNF output file is inspected, this can be a cause for misunderstanding as the material texts are still visible, and not the text translated for the target package.

When the SDNF interface is started, the Properties database is searched for SOLI elements which may define materials used to fabricate elements. An internal list is then built for rapid reference.

Materials are usually associated with application elements using the Material Reference attribute, MATR, which points to a SOLI element in the Properties database. However, you may want to use the local :SDNFMGRADE attribute to specify the material. Either of these should be set for the interface to be able to export elements successfully.

If the system is still not specific enough, there is a mechanism by which you can define from where the material information is to be derived.

When an element is exported, its material is determined by inspecting the :SDNFMGRADE attribute first, then the Description attribute of the SOLI element to which the MATR refers. If that fails, the user configurable mechanism is invoked. The text is then transferred locally to the :SDNFMGRADE attribute on the SCTN or PANE element. The text is then looked up in the Material mapping file to check that there is a translation into the SDNF file replacement text. The local material text is still exported.

When an element is to be imported, the SDNF file material description is looked up in the material mapping file and translated into the application’s equivalent text string. Initially, this is copied into the :SDNFMGRADE attribute of the element before any attempt is made to rationalise the MATR. If a SOLI element with this material text is found, the interface is set the MATR to point to the correct SOLI element.

As with the profile mapping file, the first line is an identifier which indicates the external package or system with which the file is associated.

Error and Log File Messages

User-Definable Material Macro

You can modify the sample macro, sdnfgetusermatl.pmlfnc, as named by the !!SDNFMaterialMac global variable and given in the SDNF\dflts\user\SDNFPML\functions folder in the user data folder, if you have specific requirements as to where the material information resides. The sdnfgetusermatl.pmlfnc function can be modified. After which, you should execute a PML REHASH ALL command.

The example macro is:

define function !!SDNFGetUserMatl( ) is STRING

  -- initialization

  !material = STRING( )

  !material = |unset|

  !start = ( ref )

  -- Set default material

  !defaultMaterial = |St 37-2|

  -- Some User specific PML to get the required info

  !type = ( type )

  if( !type eq |GENSEC| )then

    -- Material stored on Catalogue component

    goto catr

    handle any

      -- Bad or null reference

      !material = !defaultMaterial

      golabel /Finished

    endhandle

    !material = ( :Material )

    handle any

      !material = !defaultMaterial

      golabel /Finished

    endhandle

    if( !material eq |unset| or $

        !material.unset( ) or $

        !material.length( ) eq 0 )then

      -- Use default material

      !material = !defaultMaterial

    endif

  elseif( !type eq |PANE| )then

    -- Try to return :SDNFMGRADE or default material

     !material = ( :SDNFMGRADE )

    if( !material eq |unset| or $

        !material.unset( ) or $

        !material.length( ) eq 0 )then

      -- Use default material

      !material = !defaultMaterial

    endif

  endif

  -- Return string and exit

  label /Finished

  $!start

  return !material

endfunction

The example assumes that the material information for GENSECs resides on the catalogue component in the UDA :MATERIAL. If, for any reason, a material cannot be identified, a default value of 'St 37-2' is assigned.

The interface assumes, by default, that this file exists in a folder below the %PMLLIB% search path, and that the starting point for database navigation is the current Model element under consideration, for example, a Section, a GENSEC or Panel.

Note:
In writing the user macro, you must handle all errors encountered so that the macro always safely returns a valid PML string, whatever it may be.

Also, that materials for Panels must also be determined using this macro.

Error and Log File Messages

Sample Material Mapping File

The example is sample comma separated mapping (CSV) file to map between the application materials found in the Properties database and the SDNF file targeted at Intergraph FrameWorks.

AVEVA,FRAMEWOEKS

"unset","unset"

"TREAD-ALU","TREAD-Aluminum"

"ALUMINIUM","Aluminum"

"GR 420 I","GR 420 I"

"Pyrocrete","Fire concrete"

"Tread Grade","Tread Grade"

"LDPHP-GRADE","LDPHP-GRADE"

"Aluminium, cast","Aluminium, cast"

"Aluminium, wrought","Wrought Aluminium"

"Aluminium, Duralumin","Duralumin"

"Brass, red 80% Cu","Red Brass "

"Brass, yellow 65% Cu","Yellow Brass "

"Brass, cast","Cast Brass"

"Steel, carbon","Carbon Steel"

"Steel, chrome","Chrome Steel"

"Steel, Ni-chrome","Ni Steel"

Profile Orientation Mapping Files

Using the Profile Orientation Mapping File, you can define how the SDNF interface translates a profile from the application’s format into the SDNF Neutral File format on Export, or from it on Import. Details of how the Neutral File understands default orientations of certain profiles are available. Refer to SDNF - Structural Steel Detailing Neutral File Format for further information.

If you define your own catalogue profiles, or modify the supplied ones, and need to transform them into or from the SDNF format, this mapping file should be used. In all cases an Orientation mapping file should be available, even if it is empty apart from the first line. For example:

AVEVA FRAMEWORKS

BRI 8 0 180

BRI 9 1 180

DIN 8 0 180

DIN 9 1 180

EUR 8 0 180

EUR 9 1 180

The first line is the file identification line, described as for the Material or Profile mapping files. The structure of the rest of the mapping file is of a comma or space separated file with four fields per line.

The first two fields provide the identification of the profile for treatment. The first of the identification fields states the steel standard from which the profile is to be taken. The second is the actual profile shape code according to the codes given. Thus, in the example, the channels (type 8) and angles (type 9) from the Euronorm, DIN and British Standard catalogues have been identified for special treatment.

The third and fourth fields describe what you want to do with the profile shape. The third is the mirroring flag, which should be set to 1 if the profile is to be reflected about the Y-axis. For angle profiles, this is commonly the case. No mirroring is indicated by a value of 0 in this field.

The last field defines how much additional angular rotation you want to apply to the shape. For example, some catalogues may define the long leg of an unequal angle to be on the horizontal, whereas SDNF expects it to be vertical. The rotation angle must be between 180 and +180 degrees.

Note:
Mirroring might change the start and end positions of the linear member. It is therefore advisable that if you can achieve the same result purely by rotation, then that is the preferred option. You must then avoid confusion in the external package.

If, during the Import or Export process, an entry for a specific profile is not found, no action is taken, and no error message is output as it is assumed that you do not want the profile to receive special treatment.

The figure illustrates the effect of each operation on different catalogue representations of an angle profile. We re-emphasise the difference in the handedness of the coordinate systems.

Unicode Text String Description Files

The SDNF format specification states that the interface file is to be ASCII, understood to be only 7-bit ASCII. As a result, if you take advantage of the Unicode features of the application, you may have issues when exporting and importing a model into the application. The primary danger is where there are catalogue profile or material names in the application that contain Unicode characters. Therefore, a dictionary file may be written to convert any application strings that contain Unicode characters into equivalent strings that do not. It is these latter strings that appear in the SDNF file. The strings might actually be a description of the profile, rather than the known profile name, providing users of the external application with valid profile information.

Because there are strings other than the profile names that appear in the SDNF file, this Unicode description file should be regarded as a kind of dictionary, a look-up for any string, rather than just a profile name description table. Therefore, its format and use is different from that of the other mapping files. It is used immediately prior to writing out the text strings and it is only to contain the strings that require stripping of Unicode characters. It is also used on file import.

The Unicode description file may be customized for each target system, in the same way as the other mapping tables. The file contains:

• An indication of the encoding to be used for the SDNF file

  • Unicode UTF-8 with a Byte Order Mark (BOM):

    ENCODING:UTF8BOM

  • Unicode UTF-8 without BOM:

    ENCODING:UTF8NOBOM

  • Force to Default encoding:

    ENCODING:DEFAULT

  • Force to ASCII:

    ENCODING:ASCII

• A set of string substitutions to be used whenever a quoted-string is written to the SDNF file.

  • As potentially any character can be used in the string, first non-space character of the line is used as a delimiter for that line

  • Only complete strings would be substituted

  • Comment lines are indicated by '#'

  • Not every string needs to be in the dictionary - others would be passed through without error (but would trigger a warning if characters were lost in the encoding)

So a dictionary for export might look like:

You are not forced to prepare one of these files: the system copes if one does not exist. It would just mean that the strings would not be translated and you would have to take a chance with the target package. Further, the file can be empty, but if there are any strings requiring description, there must be the ENCODING: statement as the first non comment line in the file.

It should be noted that SDNF text fields are of a fixed maximum width. If the resultant text is too long, it is truncated, and you are warned. Ideally, the translation should succeed with no truncation warnings, and all profiles mapped either by the main mapping file or through using the Unicode description file. If, however, you decide to output in UTF-8 characters, and thereby diverge from the literal interpretation of the SDNF format, truncation does not take place.

On import, the system attempts to recognize names in the dictionary, and to translate them back into the original application names. The process as carried out in addition to the usual profile and material mapping files.

The example is an extract of a log file trying to use the Unicode description file to translate text fields.