ensure svg width does not exceed the page space

docs/architecture/services-communication.md

@@ -7,4 +7,4 @@ geekdocEditPath: edit/master/docs/architecture
 geekdocFilePath: services-communication.md
 ---
 
-{{< svg src="/ocis/static/ocis-services-communication.drawio.svg" >}}
+{{< figure src="/ocis/static/ocis-services-communication.drawio.svg" >}}

docs/extensions/storage/_index.md

@@ -16,7 +16,7 @@ The storage extension wraps [reva](https://github.com/cs3org/reva/) and adds an
 
 *Clients* will use the *Spaces Registry* to poll or get notified about changes in all *Spaces* a user has access to. Every *Space* has a dedicated `/dav/spaces/<spaceid>` WebDAV endpoint that is served by a *Spaces Provider* which uses a specific reva storage driver to wrap an underlying *Storage System*.
 
-{{< svg src="extensions/storage/static/overview.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/overview.drawio.svg" >}}
 
 The dashed lines in the diagram indicate requests that are made to authenticate requests or lookup the storage provider:
 1. After authenticating a request, the proxy may either use the CS3 `userprovider` or the accounts service to fetch the user information that will be minted into the `x-access-token`.
@@ -31,4 +31,4 @@ The bottom part is lighter because we will deprecate it in favor of using only t
 In order to reason about the request flow, two aspects in the architecture need to be understood well:
 1. What kind of [*namespaces*]({{< ref "./namespaces.md" >}}) are presented at the different WebDAV and CS3 endpoints?
 2. What kind of [*resource*]({{< ref "./terminology.md#resources" >}}) [*references*]({{< ref "./terminology.md#references" >}}) are exposed or required: path or id based?
-{{< svg src="extensions/storage/static/storage.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storage.drawio.svg" >}}

docs/extensions/storage/namespaces.md

@@ -10,7 +10,7 @@ geekdocFilePath: namespaces.md
 A *namespace* is a set of paths with a common prefix. Depending on the endpoint you are talking to you will encounter a different kind of namespace:
 In ownCloud 10 all paths are considered relative to the users home. The CS3 API uses a global namespace and the *storage providers* use a local namespace with paths relative to the storage providers root.
 
-{{< svg src="extensions/storage/static/namespaces.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/namespaces.drawio.svg" >}}
 
 The different paths in the namespaces need to be translated while passing [*references*]({{< ref "./terminology.md#references" >}}) from service to service. While the oc10 endpoints all work on paths we internally reference shared resources by id, so the shares don't break when a file is renamed or moved inside a storage [*space*]({{< ref "./spaces" >}}). The following table lists the various namespaces, paths and id based references:
 

docs/extensions/storage/spaces.md

@@ -186,7 +186,7 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 A storage *space* is a logical concept. It organizes a set of [*resources*]({{< ref "#resources" >}}) in a hierarchical tree. It has a single *owner* (*user* or *group*),
 a *quota*, *permissions* and is identified by a `storage space id`.
 
-{{< svg src="extensions/storage/static/storagespace.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}}
 
 Examples would be every user's personal storage *space*, project storage *spaces* or group storage *spaces*. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A storage [*Spaces Registry*]({{< ref "./spacesregistry.md" >}}) then allows listing the capabilities of storage *spaces*, e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
 

docs/extensions/storage/spacesprovider.md

@@ -17,18 +17,18 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 A *storage provider* manages [*resources*]({{< ref "#resources" >}}) identified by a [*reference*]({{< ref "#references" >}})
 by accessing a [*storage system*]({{< ref "#storage-systems" >}}) with a [*storage driver*]({{< ref "./storagedrivers.md" >}}).
 
-{{< svg src="extensions/storage/static/spacesprovider.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/spacesprovider.drawio.svg" >}}
 
 
 ## Frontend
 
 The oCIS frontend service starts all services that handle incoming HTTP requests:
 - *ocdav* for ownCloud flavoured WebDAV
-- *ocs* for sharing, user provisioning, capabilities and other OCS API endpoints 
+- *ocs* for sharing, user provisioning, capabilities and other OCS API endpoints
 - *datagateway* for up and downloads
 - TODO: *ocm*
 
-{{< svg src="extensions/storage/static/frontend.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/frontend.drawio.svg" >}}
 
 ### WebDAV
 
@@ -83,7 +83,7 @@ The API [already returns the storage id](https://doc.owncloud.com/server/develop
     <file_source>3994486</file_source>
     <file_parent>3994485</file_parent>
     <file_target>/Shared/Paris.jpg</file_target>
-``` 
+```
 [Creating shares only takes the **path** as the argument](https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html#function-arguments) so creating and navigating shares only needs the path. When you update or delete a share it takes the `share id` not the `file id`.
 {{< /hint >}}
 
@@ -109,4 +109,4 @@ It is used by the reva *gateway*
 to look up `address` and `port` of the [*storage provider*]({{< ref "#storage-providers" >}})
 that should handle a [*reference*]({{< ref "#references" >}}).
 
-{{< svg src="extensions/storage/static/storageregistry.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storageregistry.drawio.svg" >}}

docs/extensions/storage/spacesregistry.md

@@ -17,5 +17,4 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 
 A storage *spaces registry* manages the [*namespace*]({{< ref "./namespaces.md" >}}) for a *user*: it is used by *clients* to look up storage spaces a user has access to, the `/dav/spaces` endpoint to access it via WabDAV, and where the client should mount it in the users personal namespace.
 
-{{< svg src="extensions/storage/static/spacesregistry.drawio.svg" >}}
-
+{{< figure src="/extensions/storage/static/spacesregistry.drawio.svg" >}}

docs/extensions/storage/terminology.md

@@ -64,12 +64,12 @@ Technically, this means that every storage driver needs to have a map of a `uuid
 ## Technical concepts
 
 ### Storage Systems
-{{< svg src="extensions/storage/static/storageprovider.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storageprovider.drawio.svg" >}}
 
 A *storage provider* manages multiple [*storage spaces*]({{< ref "#storage-space" >}})
 by accessing a [*storage system*]({{< ref "#storage-systems" >}}) with a [*storage driver*]({{< ref "#storage-drivers" >}}).
 
-{{< svg src="extensions/storage/static/storageprovider-spaces.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storageprovider-spaces.drawio.svg" >}}
 
 ## Storage Space Registries
 
@@ -81,7 +81,7 @@ It is a tree of [*resources*]({{< ref "#resources" >}})*resources*
 with a single *owner* (*user* or *group*),
 a *quota* and *permissions*, identified by a `storage space id`.
 
-{{< svg src="extensions/storage/static/storagespace.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}}
 
 Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
 
@@ -98,4 +98,3 @@ There might be multiple [*storage drivers*]({{< ref "./storagedrivers.md" >}}) f
 
 ### Gateways
 A *gateway* acts as a facade to the storage related services. It authenticates and forwards API calls that are publicly accessible.
-

docs/ocis/_index.md

@@ -21,7 +21,7 @@ The below diagram shows the core conceps that are the foundation for the new arc
 - [*Storage spaces*]({{< ref "../extensions/storage/terminology#storage-spaces" >}}) represent a collection of files and folders. A users personal files are contained in a *storage space*, a group or project drive is a *storage space*, and even incoming shares are treated and implemented as *storage spaces*. Each with properties like owners, permissions, quota and type.
 - [*Storage providers*]({{< ref "../extensions/storage/terminology#storage-providers" >}}) can hold multiple *storage spaces*. At an oCIS instance, there might be a dedicated *storage provider* responsible for users personal storage spaces. There might be multiple, either to shard the load, provide different levels of redundancy or support custom workflows. Or there might be just one, hosting all types of *storage spaces*.
 
-{{< svg src="ocis/static/idea.drawio.svg" >}}
+{{< figure src="/ocis/static/idea.drawio.svg" >}}
 
 As an example, Einstein might want to share something with Marie, who has an account at a different identity provider and uses a different storage space registry. The process makes use of [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) for authentication and would look something like this:
 
@@ -63,4 +63,4 @@ We run a huge [test suite](https://github.com/owncloud/core/tree/master/tests),
 
 Running `bin/ocis server` will start the below services, all of which can be scaled and deployed on a single node or in a cloud native environment, as needed.
 
-{{< svg src="ocis/static/architecture-overview.drawio.svg" >}}
+{{< figure src="/ocis/static/architecture-overview.drawio.svg" >}}

docs/ocis/adr/0014-microservices-runtime.md

@@ -56,7 +56,7 @@ Number 3: A hybrid solution between framework and in-house.
 
 ### Design
 
-{{< svg src="ocis/static/runtime.drawio.svg" >}}
+{{< figure src="/ocis/static/runtime.drawio.svg" >}}
 
 First of, every ocis service IS a go-micro service, and because go-micro makes use of urfave/cli, a service can be conveniently wrapped inside a subcommand. Writing a supervisor is then a choice. We do use a supervisor to ensure long-running processes and embrace the "let it crash" mentality. The piece we use for this end is called [Suture](https://github.com/thejerf/suture).
 

docs/ocis/config.md

@@ -15,7 +15,7 @@ In order to simplify deployments and development the configuration model from oC
 
 ## Overview of the approach
 
-{{< svg src="ocis/static/ocis-config-redesign.drawio.svg" >}}
+{{< figure src="/ocis/static/ocis-config-redesign.drawio.svg" >}}
 
 ## In-depth configuration
 

docs/ocis/deployment/monitoring-tracing.md

@@ -17,7 +17,7 @@ This documentation describes how to set up a long running monitoring & tracing i
 
 # Overview about the proposed solution
 
-{{< svg src="ocis/static/monitoring_tracing_overview.drawio.svg" >}}
+{{< figure src="/ocis/static/monitoring_tracing_overview.drawio.svg" >}}
 
 ## Monitoring & tracing clients
 

docs/ocis/flow-docs/public-upload-flow.md

@@ -12,4 +12,4 @@ geekdocFilePath: public-upload-flow.md
 
 The following diagram describes the flow of requests:
 
-{{< svg src="ocis/static/tus-public-upload.svg" >}}
+{{< figure src="/ocis/static/tus-public-upload.svg" >}}