Open Access Series in Informatics

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:

• Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
• They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
• Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
• Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

• Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
• After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
• Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.

• No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
• Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
• Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

• The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
• Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
• It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
• Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
• Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
• Submitting a bbl-file only or an inline-bibliography is not sufficient.

The metadata associated with a DOI may not be available in all services, especially in the context of Crossref. The reason for this is that we use DataCite as our DOI registry and not CrossRef. CrossRef is certainly the largest registry for DOIs, but there are a few others (see https://www.doi.org/the-community/existing-registration-agencies/).

However, our data can be retrieved in a number of ways. DataCite offers several search options and APIs that are similar to those of CrossRef, see for example https://commons.datacite.org/.

Alternatively, you can of course retrieve the complete set of metada directly from us (https://drops.dagstuhl.de/metadata) or the basic data set from dblp (https://dblp.org).

Please note that in the metadata form there are funding fields at the bottom of each author block as well as a general funding field at the very bottom of the form (see "Additional Metadata").

In the PDF, all of these funding fields are merged to one funding block on the title page, where the author-specific funding fields are automatically preceded by the author's name.

Important! Please do not double funding information by repeating in the general field what is already contained in the author specific ones and vice versa.

As general rule of how to distribute funding information on the different fields consider the following: If a funding is clearly assigned to an author, please use the author-specific funding block. You should only deviate from this rule if the funding block on the title page of the PDF becomes unnecessarily long due to the fact that several authors have the same funding information.

The left justification of the equations is not random but part of the LIPIcs style and the other styles of Dagstuhl Publishing. We decided some years ago that we prefer text-like content (incl. equations and captions) to be left-justified and not centered. In contrast, figures and tables are centered. See also the LIPIcs Author Guidelines:

https://submission.dagstuhl.de/styles/instructions/lipics

The alignment of the equations is thus a deliberate style decision of the series. Therefore, we cannot comply with any request for centering.

Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:

• The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
• For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

We try to harmonize dashes across the whole volume (even across the whole series). We clearly address this as one of our typesetting actions in the author guidelines - admittedly, at the very end, cf. p.1:21, Section 3.2 of our current author instructions for LIPIcs authors.

However, seeking uniformity is always difficult if different style guides give different advice.

The University of Oxford Style Guide explicitly says on p. 13:

m-dash
Do not use; use an n-dash instead.

n-dash
Use in a pair in place of round brackets or commas, surrounded by spaces.
Use singly and surrounded by spaces to link two parts of a sentence, in place of a colon.

Generally, it seems that in British English the " -- " variant is preferred over "---", whereas in American English it is just the opposite. (It seems, however, that there is no uniform opinion on this in either language area.)

Hence our replacement ("---" -> " -- ") follows at least one of the accepted style guides.

Please contact the editors of the respective volume concerning this question. It is up to them to decide on a policy regarding the page limit.

Note that there is a certain flexibility concerning any page limit (+/- 1 page) to avoid too much extra effort to harmonize style-compliant formatting and page limit for both authors and the Dagstuhl Editorial Office.

\relatedversion{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL.

As all metadata should be self-contained, please add a persistent URL, e.g. \relatedversion{A full version of the paper is available at \url{...}.}. This also simplifies the access for all readers. Additional to the URL, you might add a reference (\cite{...}).

Metadata should be self-contained as they are not only part of the document / PDF but also extracted and stored in a machine-readable format along with the actual document.

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable / persistent file storage, we highly recommend to publish your document in a reliable repository like arXiv or HAL.

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

Supplementary materials are all kinds of resources related to a scholarly article such as research data, source code, research software, posters, slides, ... hosted on a repository like zenodo, figshare, ..., Software Heritage.

Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.

• During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
• authors approve or ask for (minor) corrections
• Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
• Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
• Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
• Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.

---

IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.

---

Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).

---

In any case, even if we cannot make the requested changes, you will be informed by E-mail.

• During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
• authors approve or ask for (minor) corrections
• Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
• Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
• Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
• Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

Here is an example of a completely filled author macro:

\author{John Q. Public}
{Institute of Pure Nonsense, Dummy University, Atlantis
 \and \url{http://www.myhomepage.edu}}
{johnqpublic@dummyuni.org}
{https://orcid.org/0000-0002-1825-0097}
{funded by the man in the moon.}

Please note:

• Use full first and last name.
• City and country belong to the minimum requirements on an affiliation.
• If an author has several different affiliations, please clearly separate them with the keyword \and.
• E-mail, ORCID, and funding are optional.
• Author macros cannot be shared! Please use separate author macros even if two or more authors have the same affiliation!

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

• abbreviate first names
• in case of middle initials: use \, as illustrated in the example
• be consistent with the \author macros
• in case of 2 authors: concatenate with " and "
• in case of 3 or more authors, see the sample for concatenation
• in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

• The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
• Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
• It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
• Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
• Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
• Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

• use full first and last names
• be consistent with the \author macros
• in case of 2 authors: concatenate with " and "
• in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

• comma as delimiter
• first word and every proper noun should be capitalized

\relatedversiondetails{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL. Sample usage:

\relatedversiondetails[cite={bibtex-reference}]{Full Version}{https://arxiv.org/abs/...}

As all metadata should be self-contained, please add a persistent URL to the cited version (as illustrated above). This also simplifies the access for all readers.

\supplementdetails{...} may be used to denote supplements like related research data, source code, posters, slides, ... hosted on a repository like Zenodo, Figshare, ..., Software Heritage.

Sample usage:

\supplementdetails[subcategory={Source Code}, swhid={...}]{Software}{https://github.com/...}

• The subcategory is free text, while the category ("Software" in the above example) must be one of the following words: Audiovisual, Collection, DataPaper, Dataset, Event, Image, InteractiveResource, Model, PhysicalObject, Service, Software, Sound, Text, Workflow, Other. (This is controlled vocabulary prescribed by our DOI provider.)
• The swhid (Software Heritage identifier) is optional and will usually be added by the publisher.

Please note:

• In case of a resource that may evolve over time (e.g., source code under active development), sufficient details must be provided for readers to find the specific relevant version.
• Relevant materials can be referred to via URLs (either directly in the text or in footnotes) or via a bibliographical reference in the text. Please ensure any URLs are formatted as such, i.e., clickable in the digital version of the article to visit the relevant page.
• Relevant resources included in this statement must be well-documented or otherwise self-explanatory for readers viewing the materials.
• Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use of platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:

• Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
• They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
• Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
• Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

• Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
• After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
• Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.

• No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
• Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
• Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

• The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
• Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
• It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
• Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
• Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
• Submitting a bbl-file only or an inline-bibliography is not sufficient.

The metadata associated with a DOI may not be available in all services, especially in the context of Crossref. The reason for this is that we use DataCite as our DOI registry and not CrossRef. CrossRef is certainly the largest registry for DOIs, but there are a few others (see https://www.doi.org/the-community/existing-registration-agencies/).

However, our data can be retrieved in a number of ways. DataCite offers several search options and APIs that are similar to those of CrossRef, see for example https://commons.datacite.org/.

Alternatively, you can of course retrieve the complete set of metada directly from us (https://drops.dagstuhl.de/metadata) or the basic data set from dblp (https://dblp.org).

Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:

• The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
• For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

\relatedversion{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL.

As all metadata should be self-contained, please add a persistent URL, e.g. \relatedversion{A full version of the paper is available at \url{...}.}. This also simplifies the access for all readers. Additional to the URL, you might add a reference (\cite{...}).

Metadata should be self-contained as they are not only part of the document / PDF but also extracted and stored in a machine-readable format along with the actual document.

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable / persistent file storage, we highly recommend to publish your document in a reliable repository like arXiv or HAL.

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

• We charge the total cost of the entire volume to the conference organization. We do not charge individual authors.
• The Processing Charge is 60 EUR (net) ...
  • per published paper (if the average count of main text () pages per article is ≤ 20)
  • per block of 20 main text pages (otherwise).
• To give a precise formula for calculating the charge for the entire proceedings volume, let P be the total number of main text pages from the n papers in the volume. Then:
      Total cost(entire volume) = max(n, floor(P/20)) * 60 EUR (net).
• Please note that we expect a certain flexibility concerning any page limit (+/- 1 page) to avoid too much extra effort to harmonize style-compliant formatting and page limit for both authors and final typesetting by the Dagstuhl Editorial Office.

---

() "Main-text pages" are all contents except the title page with title, authors, affiliations, abstracts, ..... and the bibliography.

• During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
• authors approve or ask for (minor) corrections
• Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
• Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
• Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
• Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

Before the volume is officially published, Dagstuhl Publishing...

• creates a web-portal on the Dagstuhl Publication Server DROPS and communicates the link to the editors
• provides a detailed change-log for all papers
• asks the editors to resolve open issues that could not be clarified during the author approval (if any)
• waits for an explicit approval of the editors to expose the web-portal to the public

The editors check everything carefully and ask for minor changes, if necessary.

When approved, the volume will be officially published.

First note that there are no automatic actions triggered when the editor submission deadline has passed! You actually decide on when to hand over the volume to Dagstuhl Publishing. (However, if you miss the deadline, we cannot guarantee a timely publication.)

Your tasks here are:

• checking for completeness and remind delayed authors on submitting their papers
• checking the order of papers (re-ordering, if necessary)
• checking for/setting the correct paper categories (e.g. Invited Talk, Extended Abstract, ...)
• writing a preface and including it into the pre-generated front matter provided by the Submission System
• handing over the volume at the specified date (editor submission deadline) to Dagstuhl Publishing
• no need to edit LaTeX sources submitted by the authors manually (although the possibility is given)

The front matter should contain the preface, table of contents and information about the conference organisation, but no other content. Information on the conference should include the list of invited speakers and the titles of their talks.
(due to a policy passed by the LIPIcs editorial board in 2019)

For the sake of the dissemination of science, we recommend that conference organisers encourage invited speakers to provide full write-ups for their invited talks to be published as articles (labelled as "Invited Paper") in the proceedings of the conference. In case invited speakers are only willing to provide an (extended) abstract of their invited talks, LIPIcs recommends that those be also published as short papers, explicitly labelled as "Abstract of Invited Talk" in the PDF and metadata to avoid confusion with contributed articles. All papers related to the invited talks will be included in the proceedings, along with the contributed articles, and will attract the APC. This policy ensures that, independent of their lengths, the contributions accompanying invited talks can be easily referenced and also have full metadata including a DOI.
(This is a recommendation of the LIPIcs editorial board.)

As a publicly funded institution, we have to recover the costs of our publishing activities so that there is no competitive advantage over commercial providers. For the cost recovery we work with an article processing charge (APC), which currently is 60 EUR (net); for more details, see below (). This amount was set under the assumption that the average length of a paper does not substantially exceed 15 to 20 main text pages, i.e., number of pages after typesetting excluding title page and the bibliography.

Given the above, we suggest 20 main text pages as a page limit, which could for instance be in the form of 15 pages for the main body of paper plus up to 5 pages for appendices. Note that this is only a recommendation and it is up to the editors of the respective volume to decide on a policy regarding the page limit. Moreover, we expect a certain flexibility concerning any page limit (+/- 1 page) to avoid too much extra effort to harmonize style-compliant formatting and page limit for both authors and the Dagstuhl Editorial Office.

---

() When specifying a page limit please have in mind the following facts about our APC:

• Processing Charge of 60 EUR (net) ...
  • per published paper (if the average count of main text pages [as defined above] per article is ≤ 20)
  • per block of 20 main text pages (otherwise).
• To give a precise formula for calculating the charge for the entire proceedings volume, let P be the total number of main text pages from the n papers in the volume. Then:
      Total cost(entire volume) = max(n, floor(P/20)) * 60 EUR (net).

First note that the specified author submission deadline does not automatically trigger any actions (like closing the submission). However, it is the deadline communicated to the authors in E-mails generated by the system. Actually, you decide on when to close the submission manually.

The editor's tasks during paper submission are:

• editors monitor the progress of paper submissions (there is an E-mail notification)
• editors send reminders (guided by the Submission Server) in case of incomplete submissions
• editors check the page limits (if any) and encourage the authors to comply with the style guidelines
• editors write a preface and include it in a pre-generated front matter template
• editors guarantee a handing over of the volume within the agreed deadline
• no need to check the submitted LaTeX sources manually (there are some automatic checks on upload)
• no need to do any kind of typesetting

Dagstuhl Publishing usually needs between six and eight weeks from submission of the camera-ready versions to publication, depending on the seasonal workload. If a conference is unable to meet this time requirement, there is a middle way in the form of "preliminary proceedings" in addition to the classic option of "post-proceedings".

Preliminary proceedings will not be published on our publication server but will only be made temporarily accessible on a separate webpage. This page requires the user to input a CAPTCHA, thus creating a barrier to prevent webcrawlers like Google etc. from accessing and indexing the papers of the preliminary proceedings (it would be quite difficult to "repair" this afterwards). Furthermore, the PDFs are watermarked, indicating that the version is preliminary, and include a URL where the officially published version will eventually be available). The preliminary proceedings thus consist of an overview page with rudimentary metadata (title + authors) and the preliminary PDFs of the papers.

Camera-ready versions should be submitted at least two weeks prior to the event in order for the preliminary proceedings to be ready in time. The official publication will then take place in the weeks following the event.

• During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
• authors approve or ask for (minor) corrections
• Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
• Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
• Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
• Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.

---

IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.

---

Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).

---

In any case, even if we cannot make the requested changes, you will be informed by E-mail.

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

• abbreviate first names
• in case of middle initials: use \, as illustrated in the example
• be consistent with the \author macros
• in case of 2 authors: concatenate with " and "
• in case of 3 or more authors, see the sample for concatenation
• in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

• The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
• Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
• It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
• Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
• Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
• Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

• use full first and last names
• be consistent with the \author macros
• in case of 2 authors: concatenate with " and "
• in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

• comma as delimiter
• first word and every proper noun should be capitalized

\relatedversiondetails{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL. Sample usage:

\relatedversiondetails[cite={bibtex-reference}]{Full Version}{https://arxiv.org/abs/...}

As all metadata should be self-contained, please add a persistent URL to the cited version (as illustrated above). This also simplifies the access for all readers.

\supplementdetails{...} may be used to denote supplements like related research data, source code, posters, slides, ... hosted on a repository like Zenodo, Figshare, ..., Software Heritage.

Sample usage:

\supplementdetails[subcategory={Source Code}, swhid={...}]{Software}{https://github.com/...}

• The subcategory is free text, while the category ("Software" in the above example) must be one of the following words: Audiovisual, Collection, DataPaper, Dataset, Event, Image, InteractiveResource, Model, PhysicalObject, Service, Software, Sound, Text, Workflow, Other. (This is controlled vocabulary prescribed by our DOI provider.)
• The swhid (Software Heritage identifier) is optional and will usually be added by the publisher.

Please note:

• In case of a resource that may evolve over time (e.g., source code under active development), sufficient details must be provided for readers to find the specific relevant version.
• Relevant materials can be referred to via URLs (either directly in the text or in footnotes) or via a bibliographical reference in the text. Please ensure any URLs are formatted as such, i.e., clickable in the digital version of the article to visit the relevant page.
• Relevant resources included in this statement must be well-documented or otherwise self-explanatory for readers viewing the materials.
• Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use of platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.