globallightingdata · Kurpanik · May 11, 2026 · May 6, 2026 · May 11, 2026 · May 11, 2026
diff --git a/.markdownlint.json b/.markdownlint.json
@@ -0,0 +1,6 @@
+{
+  "MD013": false,
+  "MD033": {
+    "allowed_elements": [ "img", "br", "div" ]
+  }
+}
diff --git a/babel.config.js b/babel.config.js
diff --git a/blog/2021-01-20-template.md b/blog/2021-01-20-template.md
@@ -13,7 +13,7 @@ Alles vor dem *truncate* Kommentar unten wird zusätzlich als Vorschau angezeigt
 
 Letzte Zeile, die noch in der Vorschau (und Blogbeitrag selbst) angezeigt wird.
 
-<!--truncate-->
+{/*truncate*/}
 
 Erste Zeile, die nur im Blogbeitrag selbst sichtbar ist.
 
@@ -77,11 +77,9 @@ Zweite Zeile, dieser Satz wird durch zwei Leerstellen oben umgebrochen.
 
 ### Emphasis
 
-Emphasis, aka italics, with *asterisks* or _underscores_.
+Emphasis, aka italics, with *asterisks*
 
-Strong emphasis, aka bold, with **asterisks** or __underscores__.
-
-Combined emphasis with **asterisks and _underscores_**.
+Strong emphasis, aka bold, with **asterisks**
 
 Strikethrough uses two tildes. ~~Scratch this.~~
 
@@ -200,20 +198,6 @@ Quote break.
 
 ---
 
-### Inline HTML
-
-Should be avoided, but is possible
-
-<dl>
-  <dt>Definition list</dt>
-  <dd>Is something people use sometimes.</dd>
-
-  <dt>Markdown in HTML</dt>
-  <dd>Does *not* work **very** well. Use HTML <em>tags</em>.</dd>
-</dl>
-
----
-
 ### More about Line Breaks
 
 Here's a line for us to start with.

diff --git a/blog/2021-03-12-welcome.md b/blog/2021-03-12-welcome.md
@@ -14,7 +14,7 @@ benefit in creating of data on manufacturer side and a benefit for designers and
 users in a reduced handling and an open structure. GLDF includes more capabilities as ROLF and
 ULD format combined.
 
-<!--truncate-->
+{/*truncate*/}
 
 ## Motivation and History
 

diff --git a/blog/2021-03-13-roadmap.md b/blog/2021-03-13-roadmap.md
@@ -11,6 +11,6 @@ GLDF is a true teamwork of DIAL and RELUX. The further software development of l
 tools and the integration in the applications will need many efforts. Here is a preliminary
 road map with time estimations of the next GLDF development steps.
 
-<!--truncate-->
+{/*truncate*/}
 
 ![Roadmap](https://raw.githubusercontent.com/globallightingdata/files/master/blog/GLDF_Roadmap_211216.png)
diff --git a/blog/2021-03-22-licht-2021.md b/blog/2021-03-22-licht-2021.md
@@ -9,9 +9,9 @@ tags: [fair]
 [![Licht 2021](https://i.imgur.com/i9GM4Sn.jpg)](https://www.licht2021.de/panel-session/04-lichtplanung-bim-und-lichtberechnungsprogramme)
 [Panel Session 04: Lichtplanung - BIM und Lichtberechnungsprogramme](https://www.licht2021.de/panel-session/04-lichtplanung-bim-und-lichtberechnungsprogramme)
 
-<!--truncate-->
+{/*truncate*/}
 
-### Session topics
+## Session topics
 
 - [Klaus Heiß](https://www.licht2021.de/referenten/322)
   - Lighting design in BIM

diff --git a/blog/2022-04-01-rc1-and-tool.md b/blog/2022-04-01-rc1-and-tool.md
@@ -10,7 +10,7 @@ Today we are pleased to publish the first release candidate of the Global Lighti
 
 We have also developed two new tools that will make it easier to write and read the GLDF and the new geometry format L3D.
 
-<!--truncate-->
+{/*truncate*/}
 
 ## Release candidate 1
 
@@ -22,7 +22,7 @@ In the course of this publication, we have also adapted an new versioning scheme
 
 ## New L3D Editor
 
-You can find our new L3D Editor [here](/l3d-editor). It is still in beta stage, so we would appreciate a lot of feedback. Have fun trying it out!
+You can find our new [L3D Editor here](/l3d-editor). It is still in beta stage, so we would appreciate a lot of feedback. Have fun trying it out!
 
 ![GLDF Logo](/img/homepage/l3d-editor-logo.webp 'Editor Logo')
 

diff --git a/blog/2022-05-03-release-parser.md b/blog/2022-05-03-release-parser.md
@@ -8,7 +8,7 @@ tags: [gldf.net, tools, release]
 
 The *GLDF.NET* Parser - a GLDF XML serializer and deserializer for [DotNet](https://dotnet.microsoft.com) - is available now for GLDF [1.0.0-rc.1](https://github.com/globallightingdata/gldf/releases/tag/v1.0.0-rc.1). In this blog post you will find a quick introduction and overview of its usage.
 
-<!--truncate-->
+{/*truncate*/}
 
 ## What is it
 

diff --git a/blog/2023-03-09-release-l3d-editor.md b/blog/2023-03-09-release-l3d-editor.md
@@ -11,15 +11,14 @@ Today we've released the **first major version** of the **L3D Editor** 🥳. It
 
 This post is a **brief summary** of what has changed since the beta version. As well as a small preview of the near-term **roadmap**.
 
-<!-- markdownlint-disable-next-line -->
 <img src="/img/homepage/l3d-editor-logo.webp" alt="GLDF Container" width="180" />
 
-<!--truncate-->
+{/*truncate*/}
 
 ## Where can I get it
 
 :::tip
-A short **description** and links to the **docs** and the **L3D Editor** itself can be found [**here**](/l3d-editor).
+A short **description** and links to the **docs** and the **L3D Editor** itself can [**be found here**](/l3d-editor).
 :::
 
 ---
@@ -64,7 +63,7 @@ A short **description** and links to the **docs** and the **L3D Editor** itself
 
 ### Documentation
 
-A comprehensive documentation can now be accessed directly from the editor (and found [**here**](/docs/tools-dev/l3d-editor)).
+A comprehensive documentation can now be accessed directly from the editor ([**or here**](/docs/tools-dev/l3d-editor)).
 
 ---
 
@@ -74,7 +73,7 @@ Finally, a short outlook on further changes:
 
 - **L3D XSD 1.0 support**  
   Currently, the L3D Editor supports the L3D XSD in version 0.10. One upcoming major change will be the integration of the final L3D XSD specification 1.0.
-  :::warning Important
+  :::warning[Important]
   Even though the L3D Editor is already final, the L3D XSD is still close to finalisation. It is unlikely, but we cannot guarantee that the final version won't introduce **breaking changes**. Keep this in mind when creating L3Ds.
   :::
 

diff --git a/blog/2023-04-17-release-gldf-rc2.md b/blog/2023-04-17-release-gldf-rc2.md
@@ -10,7 +10,8 @@ tags: [gldf, release]
 On the way to the final version 1.0 of the GLDF, we have published the next release candidate based on feedback. As always, the changelog can be found on Github: [GLDF v1.0.rc2](https://github.com/globallightingdata/gldf/releases/tag/v1.0.0-rc.2).
 
 Since this is still a pre-release version, we have taken the opportunity to include necessary breaking changes that we would like to avoid in the final version. Below is a short guide on how to migrate existing GLDFs from rc1 to the new rc2 version.
-<!--truncate-->
+
+{/*truncate*/}
 
 ---
 

diff --git a/blog/2023-06-23-release-gldf-rc3.md b/blog/2023-06-23-release-gldf-rc3.md
@@ -10,7 +10,8 @@ tags: [gldf, release]
 Today we have published the third release candidate of version 1.0. The changelog can be found on Github as always: [GLDF v1.0.rc3](https://github.com/globallightingdata/gldf/releases/tag/v1.0.0-rc.3).
 
 Below is a short guide on how to migrate existing GLDFs from rc.2 to the new rc.3 version. We have kept the changes to a minimum.
-<!--truncate-->
+
+{/*truncate*/}
 
 ---
 

diff --git a/docs/container/about-container.md b/docs/container/about-container.md
@@ -7,7 +7,6 @@ sidebar_label: About GLDF Container
 
 Now that a GLDF XML file has been created as described in the previous chapters, the next step is to **package it** together with the **referenced files** in a common **ZIP archive**. We decided to do this so that GLDFs always consist of a **single file** - and are thus easier to exchange or download. It also reduces the risk of files being forgotten when they are passed on.
 
-<!-- markdownlint-disable-next-line -->
 <img src="/img/docs/container/container.webp" alt="GLDF Container" width="370" />
 
 Another advantage is **compression**, so GLDFs consume less storage space and/or bandwidth.
@@ -23,15 +22,15 @@ Even it is possible to create GLDFs without any files. Or to reference them excl
 Lets step throuh a **simple example** on how to **create a GLDF container**. A complete specification follows in the [next chapter](container-specification.md).
 
 1. The best way to start is to create an **empty directory** and to copy the **GLDF XML and all corresponding files** into it:
-  <!-- markdownlint-disable-next-line -->
+
   <img src="/img/docs/container/create-1.webp" alt="GLDF Container" width="500" /><br />
 
   In this example we have 5 files this way:
     - The GLDF XML file itself named *my new gldf.xml*
     - One referenced Eulumdat file named *symmetrical.ldt*
     - Three geometry files for the three level of detail (see [`Geometries`](/docs/structure/geometries.md)) named *low.l3d*, *medium.l3d* and *high.l3d*  
 2. **Rename** your GLDF XML file to *product.xml*, as this is the **expected name** inside the container
-    <!-- markdownlint-disable-next-line -->
+
     <img src="/img/docs/container/create-2.webp" alt="GLDF Container" width="500" />
 3. **Move** all **files into subdirectories**
   :::info
@@ -40,18 +39,18 @@ Lets step throuh a **simple example** on how to **create a GLDF container**. A c
   So for all JPG images with the content type `image/jpg` it would be **image**. For all PNG images with the content type `image/png` it would be **image** as well. For geometry files with the content type `geo/l3d` it would be **geo**. And for photometries with the contentType `ldc/ldt` it would be **ldc**. And so on.
   :::
   In our example, as we have geometries and a photometry file, the folder structure should now look like this
-  <!-- markdownlint-disable-next-line -->
+
   <img src="/img/docs/container/create-3.webp" alt="GLDF Container" width="300" />
 
   With the subdirectories
     - geo 🠖 *low.l3d* + *medium.l3d* + *high.l3d*
     - ldc 🠖 *symmetrical.ldt*
 4. **Compress** all the content with a tool like [7-Zip](https://7-zip.org). Or using the Windows File Explorer: Select all files/folders 🠖 right click and choose *Send To* 🠖 *compressed (zipped) folder*
-  <!-- markdownlint-disable-next-line -->
+
   <img src="/img/docs/container/create-4.webp" alt="GLDF Container" width="390" />
 5. Finally, **rename** the resulting file extension to **.gldf** (it may be necessary to activate the visibility of file extensions in your Windows File Explorer
-  <!-- markdownlint-disable-next-line -->
+
   <img src="/img/docs/container/create-5.webp" alt="GLDF Container" width="390" />
 6. The GLDF file created this way can now be **distributed and used**
-  <!-- markdownlint-disable-next-line -->
-  <img src="/img/docs/container/create-6.webp" alt="GLDF Container" width="110" />
+
+  <img src="/img/docs/container/create-6.webp" alt="GLDF Container" width="110" />
diff --git a/docs/container/container-specification.md b/docs/container/container-specification.md
@@ -2,7 +2,6 @@
 title: GLDF Container Specification
 sidebar_label: Container Specification
 ---
-<!-- markdownlint-disable MD033 (no html im markdown) -->
 
 ## General
 
@@ -80,4 +79,4 @@ For a manufacturer with the name *ManufacturerXY* and a luminaire with the name
 
 ## L3D Container
 
-The [Luminaire 3D](/docs/geometry/l3d-intro) container specification is described [here](/docs/geometry/l3d-container-spec)
+The [Luminaire 3D](/docs/geometry/l3d-intro) container specification [is described here](/docs/geometry/l3d-container-spec)
diff --git a/docs/container/meta-information.md b/docs/container/meta-information.md
@@ -7,19 +7,18 @@ sidebar_label: Meta-Information
 
 A GLDF file can require information, that does **not refer to the specific** product it provides. This information are more of a **technical nature**. For this data, a separate file is intended in the GLDF: the **`meta-information.xml`**. Its content is specified like the `product.xml` through a [XSD Schema](/download) and will be described in this chapter.
 
-:::caution important
+:::caution[Important]
 The `meta-information.xml` is not intended to store manufacturers luminaire data.  
 These have to be written into the `product.xml`!
 :::
 
 ## XSD
 
-<!-- markdownlint-disable-next-line -->
 <img src="/img/docs/container/meta-info-xsd.webp" alt="Meta Information XSD" width="450" />
 
 ## `name` attribute convention
 
-:::info property naming
+:::info[property naming]
 The convention for the `name` attribute is the following:
 
 `Issuer`-`PropertyName`

diff --git a/docs/conventions/gldf-over-ldc.md b/docs/conventions/gldf-over-ldc.md
@@ -2,13 +2,12 @@
 title: GLDF over Photometry
 sidebar_label: GLDF over Photometry
 ---
-<!-- markdownlint-disable MD033 (no html im markdown) -->
 
 ## Definition
 
 One convention in the GLDF is: which **priority** applies, if the **same property** is present in the **photometry** as well as in the **GLDF**:
 
-:::important Convention
+:::important[Convention]
 If a property is present
 
 - in a linked photometry file

diff --git a/docs/conventions/ids-and-timecodes.md b/docs/conventions/ids-and-timecodes.md
@@ -23,11 +23,12 @@ Worldwide unique UUIDs can be generated for example here: [guidgenerator.com](ht
 
 ## Timecodes
 
-:::note TLDR;
+:::note[TLDR;]
 GLDF contains two timestamps in the [`Header`](/docs/structure/header.md) element, that allows to precisely distinguish the last time:
 
 - When a **GLDF as a whole** has changed -> `GldfCreationTimeCode`
 - When **anything product related** inside the GLDF has changed. -> `ProductDataTimeCode`
+
 :::
 
 The difference in detail is the following:
@@ -37,7 +38,7 @@ The difference in detail is the following:
 - **`ProductDataTimeCode`**  
   This element must reflect **the last time**, when something **only related to the product data** has **changed**. **Excluding any metadata** like manufacturer contact information in the [`Header`](/docs/structure/header.md). So this applies to any changes in XML childs of [`GeneralDefinitions`](/docs/structure/xml-hierarchy.md) and [`ProductDefinitions`](/docs/structure/xml-hierarchy.md), as well as files related to the product like product images or photometries. But not to the elements in the [`Header`](/docs/structure/header.md) area or files like the manufacturer image.
 
-:::caution Important
+:::caution[Important]
 Both timestamps must completly ignore changes to the [**meta-information.xml**](/docs/container/meta-information) file. Whether it is created, deleted or modified. As this file is intended only for digital signatures and similar. And is otherwise completly unrelated to the GLDF content at all.
 :::
 

diff --git a/docs/conventions/measurement-units.md b/docs/conventions/measurement-units.md
@@ -2,7 +2,6 @@
 title: Measurement Units
 sidebar_label: Measurement Units
 ---
-<!-- markdownlint-disable MD033 (no html im markdown) -->
 
 In GLDF and L3D, units are used according to the **International System of Units** (or derived from it). They are firmly assigned to the respective fields and documented accordingly in the XSD.
 
@@ -14,7 +13,7 @@ In both **GLDF** and **L3D**, dimensions are exclusively specified in millimeter
 
 The following units are currently in use:
 
-|**Quantity**|**Unit name**|**Symbol**|
+| **Quantity** | **Unit name** | **Symbol** |
 | :--- | :------: | :------: |
 | Dimensions | millimetres | \[mm\] |
 | Angle | degrees | \[°\] |

diff --git a/docs/conventions/referencing.md b/docs/conventions/referencing.md
@@ -5,7 +5,7 @@ sidebar_label: Referencing
 
 As described in the [chapters on XML hierarchy](/docs/structure/xml-hierarchy.md), the GLDF is structured in a **modular** way, where parts of the luminaire are defined first and then **combined to form [Variants](/docs/structure/variant.md)**. This is done in the XML by referencing the blocks with each other.
 
-:::tip Convention
+:::tip[Convention]
 For this purpose, each block, that can be **referenced in subsequent blocks**, has an `id` attribute.
 :::
 
@@ -39,7 +39,7 @@ The `id` value of a `File` element in this example is *photometryFile*:
 
 This `File` can now be referenced in subsequent elements.
 
-:::tip Convention
+:::tip[Convention]
 For the purpose of referencing prepreviously defined blocks, subsequent XML node(s) contains XML elements, which **ends** with `...Reference` in their **name**.
 :::
 

diff --git a/docs/conventions/variant-over-global.md b/docs/conventions/variant-over-global.md
@@ -11,7 +11,7 @@ For this reason, we divided the GLDF product definitions into two parts. The fir
 
 The second part is the [`Variants`](/docs/structure/variant.md) part. You can define the variations of your product and apply properties to the different [`Variants`](/docs/structure/variant.md) individually instead of globally in the [`ProductMetaData`](/docs/structure/product) part above.
 
-:::important Convention
+:::important[Convention]
 If a property is present in `ProductMetaData`
 
 - it **applies to all variants** in the gldf file
@@ -20,11 +20,11 @@ If a property is present in `ProductMetaData`
 This convention **always prevails** without having to be explicitly defined.
 :::
 
-### Example 1
+## Example 1
 
 Let's assume you have a standing luminaire in your product portfolio with different electrical components for other markets. You can apply all the same pictures, names, descriptions, etc., to all variants but define separate electrical properties in the electrical section of the descriptive attributes.
 
-### Example 2
+## Example 2
 
 You have a track-mounted luminaire that comes with different reflectors. All Luminaires will have the same name, descriptive attributes, etc. However, the 3D Model and the Light distribution would change for the other variants.
 

diff --git a/docs/geometry/introduction.md b/docs/geometry/introduction.md
@@ -7,6 +7,6 @@ sidebar_label: Introduction
 
 There are many reasons for creating a three-dimensional model of a luminaire.
 
-They range from simple placeholder objects that help to avoid geometric overlaps to the most detailed product visualisations of design-oriented luminaires. 
+They range from simple placeholder objects that help to avoid geometric overlaps to the most detailed product visualisations of design-oriented luminaires.
 
 From the point of view of most relevant planning processes, it is advantageous to create a model that allows the user to visually recognise the product without overloading the overall project with too many details (high-resolution meshes).
diff --git a/docs/geometry/l3d-container-spec.md b/docs/geometry/l3d-container-spec.md
@@ -58,4 +58,4 @@ The .obj files must not contain more than one material per file.
 
 ## GLDF Container
 
-The **GLDF** container specification is described [here](/docs/container/container-specification)
+The **GLDF** container specification [is described here](/docs/container/container-specification)
diff --git a/docs/geometry/parametric-introduction.md b/docs/geometry/parametric-introduction.md
@@ -2,7 +2,6 @@
 title: Parametric Geometry Introduction
 sidebar_label: Introduction
 ---
-<!-- markdownlint-disable MD033 (no html im markdown) -->
 
 ## The Concept
 
@@ -14,13 +13,13 @@ Our Parametric 3D Model web service allows you to upload an input XML file and p
 
 This guide will walk you through the steps to create a sample parametric L3D model and help you understand how the web service works. The outline of the process is as follows:
 
-- Create an input XML file according to our <a href="/xsd/p3d/p3d.xsd" target="_blank">XSD</a> file specification.
+- Create an input XML file according to our [XSD](/xsd/p3d/p3d.xsd) file specification.
 - Send the input XML file to our web service.
 - The web service will respond with a URL where you can download the generated L3D file.
 
 The following is an example based on the Windows platform. We will create a Windows batchfile (.bat) and a sample source XML file to demonstrate and test the web service.
 
-:::warning Important
+:::warning[Important]
 Before you start, you will need to obtain authentication information from Relux or DIAL.
 
 Make sure that you substitute "EMAIL" and "PASSWORD" with your actual email address and password as registered with the Relux API service. If you have any doubts, please reach out to [support@relux.com](mailto:support@relux.com) for assistance.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -58,4 +58,4 @@ The .obj files must not contain more than one material per file.

		## GLDF Container

		The GLDF container specification is described [here](/docs/container/container-specification)
		The GLDF container specification [is described here](/docs/container/container-specification)