Configuration

You can fully customize the viewer's behaviour by providing a configuration object to the TIDO instance. First of all, there should be set either a collection or a manifest value.

By default, TIDO will render 5 panels displaying sequence tree, metadata, image, text content and annotation views.

There are options to

• add/remove multiple panels
• freely combine view components in panels
• show/hide header features
• change the color scheme
• and more ...

Example configuration:

Code
<script id="tido-config" type="application/json">
  {
    "allowNewCollections": false,
    "defaultPanelMode": "split",
    "lang": "de",
    "panels": [
      {
        "collection": "https://api.ahiqar.uni-goettingen.de/textapi/ahiqar/syriac/collection.json",
        "manifest": "https://api.ahiqar.sub.uni-goettingen.de/textapi/ahiqar/syriac/3r145/manifest.json"
      }
    ],
    "theme": {
      "primaryColor": "#1E40AF"
    },
    "rootCollections": [
      "https://textapi.dev.vierwachen.sub.uni-goettingen.de/api/4w/collection.json"
    ],
    "translations": {
      "de": {
        "accurate": "Handschriftengetreu",
        "simplified": "Vereinfacht"
      }
    },
    "title": "Vier Wachen Edition"
  }
</script>

The Keys in Detail

Panel Views

This array of PanelViewConfig objects defines the actual visible content inside a panel. It is a list of objects, each of which creates a resizable split pane inside the panel. This configuration will be applied to all additionally added panels. Users can toggle on/off each split pane by the "View" dropdown in the panel header. It will show your configured labels of each PanelViewConfig as options. If no label is stated, it will show the raw content type identifier instead.

Types

Annotations

We provide configuration options to customize both the display and filtering of annotations.

The configuration is organized by concern. Each aspect can be defined independently using its own configuration object under a dedicated key.

Working with annotations, especially variants, can be complex. Variant annotations reference one or more witnesses, which are identified by string identifiers. Within the configuration, these witness identifiers are treated as annotation types. This allows you to apply the same configuration principles to witnesses as you would to any other annotation type.

If no annotations configuration is provided at all, TIDO will discover the currently available annotations on-the-fly. The visible types and filters are highly dependent on the loaded panel content.

Types

A map of config objects for annotation types. Each key represents the annotation type string ("x-content-type"). Each value is an AnnotationTypeConfig object for setting a custom label and icon. These values will be used in the UI to customize the display of annotations items in the panel sidebar.

As mentioned above, variant annotations are a special case. In order to configure the witnesses display, you can set a the idno value from the refs-Array in the annotationsPage response.

Example:

Code
{
  "annotations": {
    "types": {
      "Place": { "label": "Ort" },
      "witness_a": { "label": "Witness A" }
    }
  }
}

Filters

Annotations displayed in the sidebar can be filtered by their type. You can define a hierarchical structure for these filter options, referred to as a filter tree. Each node in the filter tree can control multiple annotation types simultaneously. Therefore, you need to specify an array of annotation types that should be affected by a given filter node.

At the root level, you can optionally define a rootSelectionRule (allowed values: multiple or single) to control the overall behavior and layout of the filter UI:

If set to single, the UI renders a tab bar containing the root-level nodes and a content area below it. Selecting a tab updates the content area to display the child nodes of the selected root option.

If set to multiple, a multi-selection tree is rendered without a tab bar, allowing multiple root-level nodes to be selected simultaneously.

If the rule is not specified, we set it to multiple.

Example:

Code
{
  "annotations": {
    "filters": {
      "rootSelectionRule": "single",
      "items": [
        {
          "label": "Variants",
          "types": ["Variant"],
          "items": [
            {
              "label": "Witness A",
              "types": ["witness_a"]
            },
            {
              "label": "Witness B",
              "types": ["witness_b"]
            }
          ]
        },
        {
          "label": "Commentary",
          "items": [
            {
              "label": "Entities",
              "items": [
                {
                  "label": "Places",
                  "types": ["place", "region"]
                },
                {
                  "label": "Persons",
                  "types": ["person"]
                }
              ]
            },
            {
              "label": "Additions",
              "types": ["addition"]
            }
          ]
        },
        {
          "label": "Dictionary",
          "types": ["dict"]
        }
      ]
    }
  }
}

AnnotationsMode

By default we provide an AnnotationsMode toggle which enables switching between list and aligned mode. Aligned mode will arrange annotations at the top position of text targets. List mode will ignore positioning and arrange the annotations vertically one after another. To specify the initial selected mode you should add defaultMode in annotations config as following.

Example:

Code
{
  "annotations": {
    "defaultMode": "list"
  }
}

You can also have only one mode of annotations. In this case AnnotationsToggle is not shown anymore. To accomplish this, you should add singleMode key in config as shown below.

Example:

Code
{
  "annotations": {
    "singleMode": "aligned"
  }
}

If no key regarding modes is specified, then by default AnnotationsToggle is shown with aligned mode as initially selected.

Translations

We provide a flexible way to use TIDO in your desired language. First of all we keep all translation keys in files under public/translations. Each file has to follow the naming convention [ISO 639-1 language code].json. By default, we provide a limited amount of supported languages. However, you can configure your custom languages though the TIDO config object. Append your language under the translations key in the config and set the lang key to your language, so it is treated as active language.

Collection Namespaces

In TIDO we give you the ability to define custom translations for different collections.

This is how it works: The translation key/value pairs are always wrapped by a namespace which can be either common or a collection slug. The default namespace is common and is used as a fallback namespace. You have to provide at least one namespace in your translation objects. If you don't need to use collection namespaces it still has to be common. If the namespace is a TextAPI collection slug, we check at initialization time of each panel whether there is a match between the namespace key and the slug from the loaded collection. You don't need to provide a full set of translation key/value pairs on each namespace. As mentioned before, common is a fallback namespace, so if any translation key is missing on your collection namespace, it will still be translated from the commonnamespace.

Hint: There is a difference between fixed keys that we use internally (like add_new_panel) or dynamic keys that we might receive from the TextAPI (like dynamic metadata keys). If you want to translate the latter ones, just state them as keys to your translation object.

Example:

Code
{
  "lang": "fr",
  "translations": {
    "fr": {
      "common": {
        "add_new_panel": "Ajouter un nouveau panneau",
        "title": "Titre",
        "my_custom_key": "Valeur très importante",
        "That one string": "Ce texte",
        "manifest": "manuscrit"
      },
      "special_collection": {
        "manifest": "livre"
      }
    }
  }
}

You can see that the first two keys add_new_panel and title are our fixed app keys and the other two keys are custom project keys. If you set lang to a language that we don't support and omit certain translations in your config, we will display those in English. If you don't provide a translation for a custom key, it will be displayed just as-is. Also notice how the manifest key is being set to a different word for special_collection.