diogo/aura_chi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: diogo:4f53c02235154c6e224320e0ae61aa3dc5c90d9b
Branches Tags
diogo:master
..
compare: diogo:6d0df9ad6d89a84ead7f3f4adb5f783bbb9e0a27
Branches Tags
diogo:master

10 Commits
4f53c02235 ... 6d0df9ad6d

Author SHA1 Message Date
Diogo Peralta Cordeiro
6d0df9ad6d port template 2025-06-28 21:32:11 +01:00
Diogo Peralta Cordeiro
687c1305db jtasso's final review 2025-04-11 21:42:30 +01:00
Diogo Peralta Cordeiro
69f7a225a6 Spell check 2025-04-09 15:33:48 +01:00
Diogo Peralta Cordeiro
899716319e jtasso review 2025-04-09 03:39:18 +01:00
Diogo Peralta Cordeiro
cac5284129 review v6 2025-04-08 13:46:36 +01:00
Diogo Peralta Cordeiro
6339d63aaa update bootstrap to include runtime 2025-04-07 17:27:19 +01:00
Diogo Peralta Cordeiro
4d6c967106 finish text 2025-04-07 03:40:49 +01:00
Diogo Peralta Cordeiro
f3d104c606 close section 3 2025-04-07 02:50:44 +01:00
Diogo Peralta Cordeiro
813a2bc7bf update fundamental concepts 2025-04-06 21:43:31 +01:00
Diogo Peralta Cordeiro
dd8da36f20 close 1 and 2 2025-04-06 18:30:32 +01:00
21 changed files with 14819 additions and 6506 deletions
Expand all files Collapse all files

47
.gitignore vendored
View File

@@ -1,25 +1,50 @@
main.pdf *~
*.aux *.aux
main.fls *.bbl
main.fdb_latexmk *.bcf
main.out *.blg
main.log *.cfg
*.cut
*.dvi
*.glo
*.gls
*.hd
*.idx
*.ilg
*.ind
*.lof
*.log
*.lot
*.out
*.ps
*.rpi
*.run.xml
*.tgz
*.thm
*.toc
*.zip
acmart.cls
main.pdf
main.acn main.acn
main.acr
main.alg
main.bbl main.bbl
main.bcf main.bcf
main.blg main.blg
main.brf
main.fdb_latexmk
main.fls
main.glg
main.glo main.glo
main.gls
main.glsdefs main.glsdefs
main.ist main.ist
main.loa main.loa
main.lof main.lof
main.log
main.lot main.lot
main.out
main.run.xml main.run.xml
main.synctex(busy)
main.toc main.toc
svg-inkscape/ svg-inkscape/
main.acr
main.alg
main.glg
main.gls
main.synctex(busy)
main.brf

3224
ACM-Reference-Format.bst Normal file
View File

File diff suppressed because it is too large Load Diff

0
makefile → Makefile Executable file → Normal file
View File

1286
abbrv-doi-hyperref-narrow.bst
View File

File diff suppressed because it is too large Load Diff

1285
abbrv-doi-hyperref.bst
View File

File diff suppressed because it is too large Load Diff

1286
abbrv-doi-narrow.bst
View File

File diff suppressed because it is too large Load Diff

1285
abbrv-doi.bst
View File

File diff suppressed because it is too large Load Diff

BIN
acm-jdslogo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

8985
acmart.dtx Normal file
View File

File diff suppressed because it is too large Load Diff

31
acmart.ins Normal file
View File

@@ -0,0 +1,31 @@
%
% Doctrip file for acmart
% This file is in public domain
% $Id: acmart.ins,v 1.1 2015/11/23 22:42:55 boris Exp $
%
\def\batchfile{acmart.ins}
\input docstrip
\keepsilent
\showprogress
\askforoverwritefalse
\generate{%
\file{acmart.cls}{\from{acmart.dtx}{class}}
\file{acmart-tagged.cls}{\from{acmart.dtx}{class,tagged}}
}
\obeyspaces
\Msg{*****************************************************}%
\Msg{* Congratulations! You successfully generated the *}%
\Msg{* acmart package. *}%
\Msg{* *}%
\Msg{* Please move the file acmart.cls to where LaTeX *}%
\Msg{* files are stored in your system. The manual is *}%
\Msg{* acmart.pdf. *}%
\Msg{* *}%
\Msg{* The package is released under LPPL *}%
\Msg{* *}%
\Msg{* Happy TeXing! *}%
\Msg{*****************************************************}%

908
acmauthoryear.bbx Normal file
View File

@@ -0,0 +1,908 @@
\ProvidesFile{acmauthoryear.bbx}[2022-02-14 v0.1 biblatex bibliography style]
% Inherit a default style
\RequireBibliographyStyle{authoryear-comp}
%%% New command definitions from trad-standard.bbx
\newcommand*{\newcommaunit}{\@ifstar\newcommaunitStar\newcommaunitNoStar}
\newcommand*{\newcommaunitStar}{\setunit*{\addcomma\space}}
\newcommand*{\newcommaunitNoStar}{\setunit{\addcomma\space}}
%%% Forward compatibility for date+extradate
\ifcsundef{ifbibmacroundef}{
\ifcsundef{abx@macro@date+extradate}{ %%% For really really old biblatex that miss \ifbibmacroundef
\blx@warning{bibmacro 'date+extradate' is missing.\MessageBreak
Please consider updating your version of biblatex.\MessageBreak
Using 'date+extrayear' instead}%
\providebibmacro*{date+extradate}{\usebibmacro{date+extrayear}}
}{}
}
{
\ifbibmacroundef{date+extradate}{
\blx@warning{bibmacro 'date+extradate' is missing.\MessageBreak
Please consider updating your version of biblatex.\MessageBreak
Using 'date+extrayear' instead}%
\providebibmacro*{date+extradate}{\usebibmacro{date+extrayear}}
}{}
}
%%% Localisation strings for ACM
\DefineBibliographyStrings{american}{%
mathesis = {Master's thesis},
phdthesis = {Ph\adddot{}D\adddotspace Dissertation},
editor = {(Ed\adddot)},
editors = {(Eds\adddot)},
edition = {ed\adddot},
}
%%% Formatting for fields
%\DeclareFieldFormat
% [article,inbook,incollection,inproceedings,patent,thesis,unpublished]
% {title}{#1}
\DeclareFieldFormat{pages}{#1}
\DeclareFieldFormat{numpages}{#1 pages}
\DeclareFieldFormat{number}{#1}
\DeclareFieldFormat{articleno}{Article #1}
\DeclareFieldFormat{key}{#1}
\DeclareFieldFormat{urldate}{Retrieved\space{}#1\space{}from}
\DeclareFieldFormat{lastaccessed}{Retrieved\space{}#1\space{}from}
\DeclareFieldFormat{url}{\url{#1}}
\DeclareFieldFormat{edition}{%
\printtext[parens]{\ifinteger{#1}
{\mkbibordedition{#1}~\bibstring{edition}}
{#1\isdot~\bibstring{edition}}}}
% Handle urls field containing 'and' separated list of URLs
% https://github.com/plk/biblatex/issues/229
\DeclareListFormat{urls}{%
\url{#1}%
\ifthenelse{\value{listcount}<\value{liststop}}
{\addcomma\space}
{}}
\renewbibmacro*{url}{\iffieldundef{url}{\printlist{urls}}{\printfield{url}}}
%%% Bibmacro definitions
\renewbibmacro*{translator+others}{%
\ifboolexpr{
test \ifusetranslator
and
not test {\ifnameundef{translator}}
}
{\printnames{translator}%
\setunit{\addcomma\space}%
\usebibmacro{translator+othersstrg}%
\clearname{translator}}
{\printfield{key}}}
\newbibmacro*{year}{%
\iffieldundef{year}%
{\printtext{[n.\ d.]}}%
{\printfield{year}}%
}
\renewbibmacro*{date}{\printtext[parens]{\printdate}}
\renewbibmacro*{url+urldate}{\iffieldundef{urlyear}
{\iffieldundef{lastaccessed}
{}
{\printfield{lastaccessed}%
\setunit*{\addspace}}%
}
{\usebibmacro{urldate}%
\setunit*{\addspace}}%
\usebibmacro{url}%
}
\renewbibmacro*{journal+issuetitle}{%
\usebibmacro{journal}%
\setunit*{\addcomma\space}%
\iffieldundef{series}
{}
{\newunit%
\printfield{series}%
\setunit{\addspace}}%
\usebibmacro{volume+number+date+pages+eid}%
\newcommaunit%
% \setunit{\addspace}%
\usebibmacro{issue-issue}%
\setunit*{\addcolon\space}%
\usebibmacro{issue}%
\newunit}
\newbibmacro*{volume+number+date+pages+eid}{%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}
\usebibmacro{date-ifmonth}
\setunit{\addcomma\space}%
\iffieldundef{pages}%
{\printfield{numpages}}%
{\printfield{pages}}%
\newcommaunit%
\printfield{eid}}%
\renewbibmacro*{chapter+pages}{%
\printfield{chapter}%
\setunit{\bibpagespunct}%
\iffieldundef{pages}%
{\printfield{numpages}}%
{\printfield{pages}}%
\newunit}
\renewbibmacro*{editor+others}{%
\ifboolexpr{
test \ifuseeditor
and
not test {\ifnameundef{editor}}
}
{\printnames{editor}%
\setunit{\addcomma\space}%
\usebibmacro{editor+othersstrg}%
\clearname{editor}}
{\iflistundef{organization}{}{\printlist{organization}}}
\usebibmacro{date+extradate}
}
\newbibmacro*{issue-issue}{%
\iffieldundef{issue}%
{}%
{\printfield{issue}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
}%
\newunit}
\newbibmacro*{maintitle+booktitle+series+number}{%
\iffieldundef{maintitle}
{}
{\usebibmacro{maintitle}%
\newunit\newblock
\iffieldundef{volume}
{}
{\printfield{volume}%
\printfield{part}%
\setunit{\addcolon\space}}}%
\usebibmacro{booktitle}%
\setunit*{\addspace}
\printfield[parens]{series}%
\setunit*{\addspace}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\newunit
}
\renewbibmacro*{booktitle}{%
\ifboolexpr{
test {\iffieldundef{booktitle}}
and
test {\iffieldundef{booksubtitle}}
}
{}
{\printtext[booktitle]{%
\printfield[titlecase]{booktitle}%
\iffieldundef{booksubtitle}{}{
\setunit{\subtitlepunct}%
\printfield[titlecase]{booksubtitle}}%
}%
}%
\printfield{booktitleaddon}}
\renewbibmacro*{volume+number+eid}{%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}%
\printfield{eid}}
\renewbibmacro*{publisher+location+date}{%
\printlist{publisher}%
\setunit*{\addcomma\space}%
\printlist{location}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
\newunit}
\newbibmacro{date-ifmonth}{%
\iffieldundef{month}{}{%
\usebibmacro{date}
}%
}
\renewbibmacro*{institution+location+date}{%
\printlist{school}%
\setunit*{\addcomma\space}%
\printlist{institution}%
\setunit*{\addcomma\space}%
\printlist{location}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
\newunit}
\renewbibmacro*{periodical}{%
\iffieldundef{title}
{}
{\printtext[title]{%
\printfield[titlecase]{title}%
\setunit{\subtitlepunct}%
\printfield[titlecase]{subtitle}}}%
\newunit%
\usebibmacro{journal}}
\renewbibmacro*{issue+date}{%
\iffieldundef{issue}
{\usebibmacro{date}}
{\printfield{issue}%
\setunit*{\addspace}%
\usebibmacro{date}}%
\newunit}
\renewbibmacro*{title+issuetitle}{%
\usebibmacro{periodical}%
\setunit*{\addspace}%
\iffieldundef{series}
{}
{\newunit
\printfield{series}%
\setunit{\addspace}}%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}%
\printfield{eid}%
\setunit{\addspace}%
\usebibmacro{issue+date}%
\setunit{\addcolon\space}%
\usebibmacro{issue}%
\newunit}
\renewbibmacro*{doi+eprint+url}{%
\iftoggle{bbx:url}
{\iffieldundef{doi}{
\usebibmacro{url+urldate}
}{\iffieldundef{distinctURL}
{}
{\usebibmacro{url+urldate}}
}
}%
\newunit\newblock
\iftoggle{bbx:eprint}
{\usebibmacro{eprint}}
{}%
\newunit\newblock
\iftoggle{bbx:doi}
{\printfield{doi}}
{}}
%%% Definitions for drivers (alphabetical)
\DeclareBibliographyDriver{article}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock%
\usebibmacro{title}%
\newunit%
\printlist{language}%
\newunit\newblock%
\usebibmacro{byauthor}%
\newunit\newblock%
\usebibmacro{bytranslator+others}%
\newunit\newblock%
\printfield{version}%
\newunit\newblock%
\usebibmacro{journal+issuetitle}%
\newunit%
\usebibmacro{byeditor+others}%
\newunit%
\printfield{note}%
\newunit\newblock%
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock%
\usebibmacro{doi+eprint+url}%
\newunit\newblock%
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock%
\usebibmacro{related}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{book}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{maintitle+title}%
\newunit%
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{edition}%
\newunit
\usebibmacro{series+number}%
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\newunit\newblock
\printfield{volumes}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{inbook}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\iffieldundef{author}%
{\usebibmacro{byeditor+others}}%
{\usebibmacro{author/translator+others}}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
% \usebibmacro{in:}%
\usebibmacro{bybookauthor}%
\newunit\newblock
\usebibmacro{maintitle+booktitle}%
\newunit\newblock
\iffieldundef{author}{}%if undef then we already printed editor
{\usebibmacro{byeditor+others}}%
\newunit\newblock
\printfield{edition}%
\newunit
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{incollection}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{in:}%
\usebibmacro{maintitle+booktitle}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{edition}%
\newunit
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{inproceedings}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{in:}%
\usebibmacro{maintitle+booktitle+series+number}%
\newunit\newblock
\usebibmacro{event+venue+date}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{manual}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor}%
\newunit\newblock
\printfield{edition}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{type}%
\newunit
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{misc}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{howpublished}%
\newunit\newblock
\printfield{type}%
\newunit
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\usebibmacro{organization+location+date}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{online}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit\newblock
\usebibmacro{date-ifmonth}%
\newunit\newblock
\iftoggle{bbx:eprint}
{\usebibmacro{eprint}}
{}%
\newunit\newblock
\usebibmacro{url+urldate}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareFieldFormat[patent]{number}{Patent No.~#1}
\DeclareBibliographyDriver{patent}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{date}%
\newunit\newblock
\printfield{type}%
\setunit*{\addspace}%
\printfield{number}%
\iflistundef{location}
{}
{\setunit*{\addspace}%
\printtext[parens]{%
\printlist[][-\value{listtotal}]{location}}}%
\newunit\newblock
\usebibmacro{byholder}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{periodical}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{editor}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title+issuetitle}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byeditor}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{issn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{report}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\printfield{type}%
\setunit*{\addspace}%
\printfield{number}%
\newunit\newblock
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\usebibmacro{institution+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isrn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{thesis}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\printfield{type}%
\newunit
\usebibmacro{institution+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
%
% Include support for software entries
%
\blx@inputonce{software.bbx}{biblatex style for software}{}{}{}{}
%
% Handle ACM specific ArtifactSoftware entry exactly as the software entry (a soft alias will not work)
%
\DeclareStyleSourcemap{
\maps[datatype=bibtex]{
\map{
\step[typesource=artifactsoftware,typetarget=software]
\step[typesource=artifactdataset,typetarget=dataset]
}
}
}
%%% Compatibility with ACM bibtex formatting
%
% Show given name first in the reference list
%
\DeclareNameAlias{sortname}{given-family}
%
% Produce a bibliography with small font size
%
\renewcommand*{\bibfont}{\bibliofont\footnotesize}
%
% Remove parentheses from date+extradate
%
\RequirePackage{xpatch}
\xpatchbibmacro{date+extradate}{%
\printtext[parens]%
}{%
\newblock\setunit*{.\space}%
\printtext%
}{}{}
%%% Set option values for ACM style
\ExecuteBibliographyOptions{
dashed=false, % Do not use dashes for bibliography items with the same set of authors
labeldate=year,
abbreviate=true,
dateabbrev=true,
isbn=true,
doi=true,
urldate=comp,
url=true,
maxbibnames=9,
maxcitenames=2,
backref=false,
sorting=nty,
halid=true,
swhid=true,
swlabels=true,
vcs=true,
license=false,
language=american
}
% We use lowercase DOI
\DeclareFieldFormat{doi}{%
doi\addcolon
\ifhyperref
{\href{https://doi.org/#1}{\nolinkurl{#1}}}
{\nolinkurl{#1}}}

219
acmauthoryear.cbx Normal file
View File

@@ -0,0 +1,219 @@
\ProvidesFile{acmauthoryear.cbx}[2022-02-14 v0.1]
\RequireCitationStyle{authoryear-comp}
\RequirePackage{xpatch}
%
% Hyperlink citations like acmart natbib implementation
%
% From https://tex.stackexchange.com/a/27615/133551
% Combine label and labelyear links
\xpatchbibmacro{cite}
{\usebibmacro{cite:label}%
\setunit{\printdelim{nonameyeardelim}}%
\usebibmacro{cite:labeldate+extradate}}
{\printtext[bibhyperref]{%
\DeclareFieldAlias{bibhyperref}{default}%
\usebibmacro{cite:label}%
\setunit{\printdelim{nonameyeardelim}}%
\usebibmacro{cite:labeldate+extradate}}}
{}
{\PackageWarning{biblatex-patch}
{Failed to patch cite bibmacro}}
% Include labelname in labelyear link
\xpatchbibmacro{cite}
{\printnames{labelname}%
\setunit{\printdelim{nameyeardelim}}%
\usebibmacro{cite:labeldate+extradate}}
{\printtext[bibhyperref]{%
\DeclareFieldAlias{bibhyperref}{default}%
\printnames{labelname}%
\setunit{\printdelim{nameyeardelim}}%
\usebibmacro{cite:labeldate+extradate}}}
{}
{\PackageWarning{biblatex-patch}
{Failed to patch cite bibmacro}}
\renewbibmacro*{textcite}{%
\iffieldequals{namehash}{\cbx@lasthash}
{\iffieldundef{shorthand}
{\ifthenelse{\iffieldequals{labelyear}{\cbx@lastyear}\AND
\(\value{multicitecount}=0\OR\iffieldundef{postnote}\)}
{\setunit{\addcomma}%
\usebibmacro{cite:extradate}}
{\setunit{\compcitedelim}%
\usebibmacro{cite:labeldate+extradate}%
\savefield{labelyear}{\cbx@lastyear}}}
{\setunit{\compcitedelim}%
\usebibmacro{cite:shorthand}%
\global\undef\cbx@lastyear}}
{\ifnameundef{labelname}
{\iffieldundef{shorthand}
{\usebibmacro{cite:label}%
\setunit{%
\global\booltrue{cbx:parens}%
\printdelim{nonameyeardelim}\bibopenbracket}%
\ifnumequal{\value{citecount}}{1}
{\usebibmacro{prenote}}
{}%
\usebibmacro{cite:labeldate+extradate}}
{\usebibmacro{cite:shorthand}}}
{\printnames{labelname}%
\setunit{%
\global\booltrue{cbx:parens}%
\printdelim{nameyeardelim}\bibopenbracket}%
\ifnumequal{\value{citecount}}{1}
{\usebibmacro{prenote}}
{}%
\iffieldundef{shorthand}
{\iffieldundef{labelyear}
{\usebibmacro{cite:label}}
{\usebibmacro{cite:labeldate+extradate}}%
\savefield{labelyear}{\cbx@lastyear}}
{\usebibmacro{cite:shorthand}%
\global\undef\cbx@lastyear}}%
\stepcounter{textcitecount}%
\savefield{namehash}{\cbx@lasthash}}%
\setunit{%
\ifbool{cbx:parens}
{\bibclosebracket\global\boolfalse{cbx:parens}}
{}%
\textcitedelim}}
\xpatchbibmacro{textcite}
{\printnames{labelname}}
{\printtext[bibhyperref]{\printnames{labelname}}}
{}
{\PackageWarning{biblatex-patch}
{Failed to patch textcite bibmacro}}
\renewbibmacro*{textcite:postnote}{%
\usebibmacro{postnote}%
\ifthenelse{\value{multicitecount}=\value{multicitetotal}}
{\setunit{}%
\printtext{%
\ifbool{cbx:parens}
{\bibclosebracket\global\boolfalse{cbx:parens}}
{}}}
{\setunit{%
\ifbool{cbx:parens}
{\bibclosebracket\global\boolfalse{cbx:parens}}
{}%
\textcitedelim}}}
% NEW
\newbibmacro*{citeauthor}{%
\ifnameundef{labelname}
{\iffieldundef{shorthand}
{\printtext[bibhyperref]{%
\usebibmacro{cite:label}}%
\setunit{%
\global\booltrue{cbx:parens}%
\printdelim{nonameyeardelim}\bibopenbracket}%
\ifnumequal{\value{citecount}}{1}
{\usebibmacro{prenote}}
{}%
\printtext[bibhyperref]{\usebibmacro{cite:labeldate+extradate}}}
{\printtext[bibhyperref]{\usebibmacro{cite:shorthand}}}}
\printtext[bibhyperref]{\printnames{labelname}}}
%
% Put brackets around citations
%
\DeclareCiteCommand{\cite}[\mkbibbrackets]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{cite}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand*{\cite}[\mkbibbrackets]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{citeyear}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand{\parencite}[\mkbibbrackets]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{cite}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand*{\parencite}[\mkbibbrackets]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{citeyear}}
{}
{\usebibmacro{postnote}}
\DeclareMultiCiteCommand{\parencites}[\mkbibbrackets]{\parencite}
{\setunit{\multicitedelim}}
\DeclareCiteCommand{\footcite}[\mkbibfootnote]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{cite}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand{\footcitetext}[\mkbibfootnotetext]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{cite}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand{\smartcite}[\iffootnote\mkbibbrackets\mkbibfootnote]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{cite}}
{}
{\usebibmacro{postnote}}
\DeclareMultiCiteCommand{\smartcites}[\iffootnote\mkbibbrackets\mkbibfootnote]
{\smartcite}{\setunit{\multicitedelim}}
\DeclareCiteCommand{\citeauthor}
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{citeauthor}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand{\citeyear}
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{citeyear}}
{}
{\usebibmacro{postnote}}
\DeclareCiteCommand{\citeyearpar}[\mkbibbrackets]
{\usebibmacro{cite:init}%
\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\usebibmacro{citeyear}}
{}
{\usebibmacro{postnote}}
%
% Provide aliases for natbib-compatible commands
%
\newcommand*{\citep}{\parencite}
\newcommand*{\citet}{\textcite}
% add others here
\endinput

33
acmdatamodel.dbx Normal file
View File

@@ -0,0 +1,33 @@
% Teach biblatex about numpages field
\DeclareDatamodelFields[type=field, datatype=literal]{numpages}
\DeclareDatamodelEntryfields{numpages}
% Teach biblatex about articleno field
\DeclareDatamodelFields[type=field, datatype=literal]{articleno}
\DeclareDatamodelEntryfields{articleno}
% Teach biblatex about urls field
\DeclareDatamodelFields[type=list, datatype=uri]{urls}
\DeclareDatamodelEntryfields{urls}
% Teach biblatex about school field
\DeclareDatamodelFields[type=list, datatype=literal]{school}
\DeclareDatamodelEntryfields[thesis]{school}
\DeclareDatamodelFields[type=field, datatype=literal]{key}
\DeclareDatamodelEntryfields{key}
% Teach biblatex about lastaccessed field
\DeclareDatamodelFields[type=field,datatype=literal]{lastaccessed}
\DeclareDatamodelEntryfields{lastaccessed}
% Teach biblatex about distincturl field
\DeclareDatamodelFields[type=field, datatype=literal]{distinctURL}
\DeclareDatamodelEntryfields{distinctURL}
%
% include software data model from biblatex-software
%
\blx@inputonce{software.dbx}{biblatex data model extension for software}{}{}{}{}

893
acmnumeric.bbx Normal file
View File

@@ -0,0 +1,893 @@
\ProvidesFile{acmnumeric.bbx}[2017-09-27 v0.1 biblatex bibliography style]
% Inherit a default style
\RequireBibliographyStyle{trad-plain}
%%% Localisation strings for ACM
\DefineBibliographyStrings{american}{%
mathesis = {Master's thesis},
phdthesis = {Ph\adddot{}D\adddotspace Dissertation},
editor = {(Ed\adddot)},
editors = {(Eds\adddot)},
edition = {ed\adddot},
}
%%% Formatting for fields
%\DeclareFieldFormat
% [article,inbook,incollection,inproceedings,patent,thesis,unpublished]
% {title}{#1}
\DeclareFieldFormat{pages}{#1}
\DeclareFieldFormat{numpages}{#1 pages}
\DeclareFieldFormat{number}{#1}
\DeclareFieldFormat{articleno}{Article #1}
\DeclareFieldFormat{key}{#1}
\DeclareFieldFormat{urldate}{Retrieved\space{}#1\space{}from}
\DeclareFieldFormat{lastaccessed}{Retrieved\space{}#1\space{}from}
\DeclareFieldFormat{url}{\url{#1}}
\DeclareFieldFormat{edition}{%
\printtext[parens]{\ifinteger{#1}
{\mkbibordedition{#1}~\bibstring{edition}}
{#1\isdot~\bibstring{edition}}}}
% Handle urls field containing 'and' separated list of URLs
% https://github.com/plk/biblatex/issues/229
\DeclareListFormat{urls}{%
\url{#1}%
\ifthenelse{\value{listcount}<\value{liststop}}
{\addcomma\space}
{}}
\renewbibmacro*{url}{\iffieldundef{url}{\printlist{urls}}{\printfield{url}}}
%%% Bibmacro definitions
\renewbibmacro*{translator+others}{%
\ifboolexpr{
test \ifusetranslator
and
not test {\ifnameundef{translator}}
}
{\printnames{translator}%
\setunit{\addcomma\space}%
\usebibmacro{translator+othersstrg}%
\clearname{translator}}
{\printfield{key}}}
\newbibmacro*{year}{%
\iffieldundef{year}%
{\printtext{[n.\ d.]}}%
{\printfield{year}}%
}
\renewbibmacro*{date}{\printtext[parens]{\printdate}}
\renewbibmacro*{url+urldate}{\iffieldundef{urlyear}
{\iffieldundef{lastaccessed}
{}
{\printfield{lastaccessed}%
\setunit*{\addspace}}%
}
{\usebibmacro{urldate}%
\setunit*{\addspace}}%
\usebibmacro{url}%
}
\renewbibmacro*{journal+issuetitle}{%
\usebibmacro{journal}%
\setunit*{\addcomma\space}%
\iffieldundef{series}
{}
{\newunit%
\printfield{series}%
\setunit{\addspace}}%
\usebibmacro{volume+number+date+pages+eid}%
\newcommaunit%
% \setunit{\addspace}%
\usebibmacro{issue-issue}%
\setunit*{\addcolon\space}%
\usebibmacro{issue}%
\newunit}
\newbibmacro*{volume+number+date+pages+eid}{%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}
\usebibmacro{date-ifmonth}
\setunit{\addcomma\space}%
\iffieldundef{pages}%
{\printfield{numpages}}%
{\printfield{pages}}%
\newcommaunit%
\printfield{eid}}%
\renewbibmacro*{chapter+pages}{%
\printfield{chapter}%
\setunit{\bibpagespunct}%
\iffieldundef{pages}%
{\printfield{numpages}}%
{\printfield{pages}}%
\newunit}
\renewbibmacro*{editor+others}{%
\ifboolexpr{
test \ifuseeditor
and
not test {\ifnameundef{editor}}
}
{\printnames{editor}%
\setunit{\addcomma\space}%
\usebibmacro{editor+othersstrg}%
\clearname{editor}}
{\iflistundef{organization}{}{\printlist{organization}}}}
\newbibmacro*{issue-issue}{%
\iffieldundef{issue}%
{}%
{\printfield{issue}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
}%
\newunit}
\newbibmacro*{maintitle+booktitle+series+number}{%
\iffieldundef{maintitle}
{}
{\usebibmacro{maintitle}%
\newunit\newblock
\iffieldundef{volume}
{}
{\printfield{volume}%
\printfield{part}%
\setunit{\addcolon\space}}}%
\usebibmacro{booktitle}%
\setunit*{\addspace}
\printfield[parens]{series}%
\setunit*{\addspace}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\newunit
}
\renewbibmacro*{booktitle}{%
\ifboolexpr{
test {\iffieldundef{booktitle}}
and
test {\iffieldundef{booksubtitle}}
}
{}
{\printtext[booktitle]{%
\printfield[titlecase]{booktitle}%
\iffieldundef{booksubtitle}{}{
\setunit{\subtitlepunct}%
\printfield[titlecase]{booksubtitle}}%
}%
}%
\printfield{booktitleaddon}}
\renewbibmacro*{volume+number+eid}{%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}%
\printfield{eid}}
\renewbibmacro*{publisher+location+date}{%
\printlist{publisher}%
\setunit*{\addcomma\space}%
\printlist{location}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
\newunit}
\newbibmacro{date-ifmonth}{%
\iffieldundef{month}{}{%
\usebibmacro{date}
}%
}
\renewbibmacro*{institution+location+date}{%
\printlist{school}%
\setunit*{\addcomma\space}%
\printlist{institution}%
\setunit*{\addcomma\space}%
\printlist{location}%
\setunit*{\addcomma\space}%
\usebibmacro{date-ifmonth}%
\newunit}
\renewbibmacro*{periodical}{%
\iffieldundef{title}
{}
{\printtext[title]{%
\printfield[titlecase]{title}%
\setunit{\subtitlepunct}%
\printfield[titlecase]{subtitle}}}%
\newunit%
\usebibmacro{journal}}
\renewbibmacro*{issue+date}{%
\iffieldundef{issue}
{\usebibmacro{date}}
{\printfield{issue}%
\setunit*{\addspace}%
\usebibmacro{date}}%
\newunit}
\renewbibmacro*{title+issuetitle}{%
\usebibmacro{periodical}%
\setunit*{\addspace}%
\iffieldundef{series}
{}
{\newunit
\printfield{series}%
\setunit{\addspace}}%
\printfield{volume}%
\setunit*{\addcomma\space}%
\printfield{number}%
\setunit*{\addcomma\space}%
\printfield{articleno}
\setunit{\addcomma\space}%
\printfield{eid}%
\setunit{\addspace}%
\usebibmacro{issue+date}%
\setunit{\addcolon\space}%
\usebibmacro{issue}%
\newunit}
\renewbibmacro*{doi+eprint+url}{%
\iftoggle{bbx:url}
{\iffieldundef{doi}{
\usebibmacro{url+urldate}
}{\iffieldundef{distinctURL}
{}
{\usebibmacro{url+urldate}}
}
}%
\newunit\newblock
\iftoggle{bbx:eprint}
{\usebibmacro{eprint}}
{}%
\newunit\newblock
\iftoggle{bbx:doi}
{\printfield{doi}}
{}}
%%% Definitions for drivers (alphabetical)
\DeclareBibliographyDriver{article}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock%
\usebibmacro{year}%
\newunit%
\usebibmacro{title}%
\newunit%
\printlist{language}%
\newunit\newblock%
\usebibmacro{byauthor}%
\newunit\newblock%
\usebibmacro{bytranslator+others}%
\newunit\newblock%
\printfield{version}%
\newunit\newblock%
\usebibmacro{journal+issuetitle}%
\newunit%
\usebibmacro{byeditor+others}%
\newunit%
\printfield{note}%
\newunit\newblock%
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock%
\usebibmacro{doi+eprint+url}%
\newunit\newblock%
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock%
\usebibmacro{related}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{book}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}%
\newunit%
\usebibmacro{maintitle+title}%
\newunit%
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{edition}%
\newunit
\usebibmacro{series+number}%
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\newunit\newblock
\printfield{volumes}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{inbook}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\iffieldundef{author}%
{\usebibmacro{byeditor+others}}%
{\usebibmacro{author/translator+others}}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
% \usebibmacro{in:}%
\usebibmacro{bybookauthor}%
\newunit\newblock
\usebibmacro{maintitle+booktitle}%
\newunit\newblock
\iffieldundef{author}{}%if undef then we already printed editor
{\usebibmacro{byeditor+others}}%
\newunit\newblock
\printfield{edition}%
\newunit
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{incollection}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{in:}%
\usebibmacro{maintitle+booktitle}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{edition}%
\newunit
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{inproceedings}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{in:}%
\usebibmacro{maintitle+booktitle+series+number}%
\newunit\newblock
\usebibmacro{event+venue+date}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\iffieldundef{maintitle}
{\printfield{volume}%
\printfield{part}}
{}%
\newunit
\printfield{volumes}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{manual}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor}%
\newunit\newblock
\printfield{edition}%
\newunit\newblock
\usebibmacro{series+number}%
\newunit\newblock
\printfield{type}%
\newunit
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit
\usebibmacro{publisher+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{misc}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{howpublished}%
\newunit\newblock
\printfield{type}%
\newunit
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\usebibmacro{organization+location+date}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{online}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/editor+others/translator+others}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{byeditor+others}%
\newunit\newblock
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\printlist{organization}%
\newunit\newblock
\usebibmacro{date-ifmonth}%
\newunit\newblock
\iftoggle{bbx:eprint}
{\usebibmacro{eprint}}
{}%
\newunit\newblock
\usebibmacro{url+urldate}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareFieldFormat[patent]{number}{Patent No.~#1}
\DeclareBibliographyDriver{patent}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}%
\newunit
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{date}%
\newunit\newblock
\printfield{type}%
\setunit*{\addspace}%
\printfield{number}%
\iflistundef{location}
{}
{\setunit*{\addspace}%
\printtext[parens]{%
\printlist[][-\value{listtotal}]{location}}}%
\newunit\newblock
\usebibmacro{byholder}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{periodical}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{editor}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit
\usebibmacro{title+issuetitle}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byeditor}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{issn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{report}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\printfield{type}%
\setunit*{\addspace}%
\printfield{number}%
\newunit\newblock
\printfield{version}%
\newunit
\printfield{note}%
\newunit\newblock
\usebibmacro{institution+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isrn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
\DeclareBibliographyDriver{thesis}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author}%
\setunit{\labelnamepunct}\newblock
\usebibmacro{year}
\newunit
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\printfield{type}%
\newunit
\usebibmacro{institution+location+date}%
\newunit\newblock
\usebibmacro{chapter+pages}%
\newunit
\printfield{pagetotal}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{isbn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\printfield{note}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
%
% Include support for software entries
%
\blx@inputonce{software.bbx}{biblatex style for software}{}{}{}{}
%
% Handle ACM specific ArtifactSoftware entry exactly as the software entry (a soft alias will not work)
%
\DeclareStyleSourcemap{
\maps[datatype=bibtex]{
\map{
\step[typesource=artifactsoftware,typetarget=software]
\step[typesource=artifactdataset,typetarget=dataset]
}
}
}
%
% Show given name first in the reference list
%
\DeclareNameAlias{sortname}{given-family}
%
% Produce a bibliography with small font size
%
\renewcommand*{\bibfont}{\bibliofont\footnotesize}
%%% Set option values for ACM style
\ExecuteBibliographyOptions{
labeldate=year,
abbreviate=true,
dateabbrev=true,
isbn=true,
doi=true,
urldate=comp,
url=true,
maxbibnames=9,
maxcitenames=2,
backref=false,
sorting=nty,
halid=true,
swhid=true,
swlabels=true,
vcs=true,
license=false,
language=american
}
% We use lowercase DOI
\DeclareFieldFormat{doi}{%
doi\addcolon
\ifhyperref
{\href{https://doi.org/#1}{\nolinkurl{#1}}}
{\nolinkurl{#1}}}

5
acmnumeric.cbx Normal file
View File

@@ -0,0 +1,5 @@
\ProvidesFile{acmnumeric.cbx}[2017-09-27 v0.1]
\RequireCitationStyle{numeric}
\endinput

63
biblio.bib
View File

@@ -1,12 +1,14 @@
@misc{AFrame, @misc{AFrame,
title = {{A-Frame}: A Web Framework for Building Virtual Reality Experiences}, title = {{A-Frame}: A Web Framework for Building Virtual Reality Experiences},
author = {{A-Frame Authors}}, author = {{A-Frame Authors}},
howpublished = {\url{https://aframe.io/}} howpublished = {\url{https://aframe.io/}},
year = {[n.\,d.]}
} }
@misc{AndroidXRUnity, @misc{AndroidXRUnity,
title = {{D}evelop with {U}nity for {XR}}, title = {{D}evelop with {U}nity for {XR}},
author = {{Google Inc.}}, author = {{Google Inc.}},
howpublished = {\url{https://developer.android.com/develop/xr/unity}} howpublished = {\url{https://developer.android.com/develop/xr/unity}},
year = {[n.\,d.]}
} }
@incollection{AppleRealityKitChapter9, @incollection{AppleRealityKitChapter9,
title = {{RealityKit}}, title = {{RealityKit}},
@@ -20,32 +22,44 @@
@misc{AppleVisionOS, @misc{AppleVisionOS,
title = {{visionOS}}, title = {{visionOS}},
author = {{Apple Inc.}}, author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/visionos/}} howpublished = {\url{https://developer.apple.com/visionos/}},
year = {[n.\,d.]}
}
@misc{AppleVisionOSRenderPipeline,
title = {Understanding the visionOS Render Pipeline},
author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/documentation/visionos/understanding-the-visionos-render-pipeline}},
year = {[n.\,d.]}
} }
@misc{ARCoreCloudAnchors, @misc{ARCoreCloudAnchors,
title = {Cloud Anchors allow different users to share AR experiences}, title = {Cloud Anchors allow different users to share AR experiences},
author = {{Google Inc.}}, author = {{Google Inc.}},
howpublished = {\url{https://developers.google.com/ar/develop/cloud-anchors}} howpublished = {\url{https://developers.google.com/ar/develop/cloud-anchors}},
year = {[n.\,d.]}
} }
@misc{ARCoreDocumentation, @misc{ARCoreDocumentation,
title = {Overview of ARCore and Supported Development Environments}, title = {Overview of ARCore and Supported Development Environments},
author = {{Google Inc.}}, author = {{Google Inc.}},
howpublished = {\url{https://developers.google.com/ar/develop}} howpublished = {\url{https://developers.google.com/ar/develop}},
year = {[n.\,d.]}
} }
@misc{ARKitDocumentation, @misc{ARKitDocumentation,
title = {{ARKit}}, title = {{ARKit}},
author = {{Apple Inc.}}, author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/documentation/arkit}} howpublished = {\url{https://developer.apple.com/documentation/arkit}},
year = {[n.\,d.]}
} }
@misc{ARWorldMap, @misc{ARWorldMap,
title = {{ARWorldMap}}, title = {{ARWorldMap}},
author = {{Apple Inc.}}, author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/documentation/arkit/arworldmap}} howpublished = {\url{https://developer.apple.com/documentation/arkit/arworldmap}},
year = {[n.\,d.]}
} }
@misc{ARKitWorldAnchor, @misc{ARKitWorldAnchor,
title = {WorldAnchor}, title = {WorldAnchor},
author = {{Apple Inc.}}, author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/documentation/arkit/worldanchor}} howpublished = {\url{https://developer.apple.com/documentation/arkit/worldanchor}},
year = {[n.\,d.]}
} }
@inproceedings{huynh2022layerable, @inproceedings{huynh2022layerable,
title = {Layerable Apps: Comparing Concurrent and Exclusive Display of Augmented Reality Applications}, title = {Layerable Apps: Comparing Concurrent and Exclusive Display of Augmented Reality Applications},
@@ -57,7 +71,8 @@
} }
@misc{khronosopenxr, @misc{khronosopenxr,
title = {{OpenXR} - {H}igh-performance access to {AR} and {VR} platforms and devices}, title = {{OpenXR} - {H}igh-performance access to {AR} and {VR} platforms and devices},
howpublished = {\url{https://www.khronos.org/openxr}} howpublished = {\url{https://www.khronos.org/openxr}},
year = {[n.\,d.]}
} }
@techreport{knibbe2015juggling, @techreport{knibbe2015juggling,
title = {Juggling the Effects of Latency: Software Approaches to Minimizing Latency in Dynamic Projector-Camera Systems}, title = {Juggling the Effects of Latency: Software Approaches to Minimizing Latency in Dynamic Projector-Camera Systems},
@@ -99,17 +114,20 @@
@misc{MagicLeapSpacesApp, @misc{MagicLeapSpacesApp,
title = {{S}paces {A}pplication}, title = {{S}paces {A}pplication},
author = {{Magic Leap, Inc.}}, author = {{Magic Leap, Inc.}},
howpublished = {\url{https://developer-docs.magicleap.cloud/docs/guides/features/spaces/spaces-tool/}} howpublished = {\url{https://developer-docs.magicleap.cloud/docs/guides/features/spaces/spaces-tool/}},
year = {[n.\,d.]}
} }
@misc{MagicLeapSpatialAnchors, @misc{MagicLeapSpatialAnchors,
title = {{S}patial {A}nchors}, title = {{S}patial {A}nchors},
author = {{Magic Leap, Inc.}}, author = {{Magic Leap, Inc.}},
howpublished = {\url{https://developer-docs.magicleap.cloud/docs/guides/features/spaces/spatial-anchors/}} howpublished = {\url{https://developer-docs.magicleap.cloud/docs/guides/features/spaces/spatial-anchors/}},
year = {[n.\,d.]}
} }
@misc{MetaSpatialAnchorsPersist, @misc{MetaSpatialAnchorsPersist,
title = {{S}patial {A}nchors}, title = {{S}patial {A}nchors},
author = {{Meta Platforms, Inc.}}, author = {{Meta Platforms, Inc.}},
howpublished = {\url{https://developers.meta.com/horizon/documentation/unity/unity-spatial-anchors-persist-content/}} howpublished = {\url{https://developers.meta.com/horizon/documentation/unity/unity-spatial-anchors-persist-content/}},
year = {[n.\,d.]}
} }
@misc{MicrosoftLearnAzureSpatialAnchors, @misc{MicrosoftLearnAzureSpatialAnchors,
title = {Intro to Azure Mixed Reality Services: Azure Spatial Anchors}, title = {Intro to Azure Mixed Reality Services: Azure Spatial Anchors},
@@ -132,7 +150,8 @@
@software{ros, @software{ros,
title = {{R}obot {O}perating {S}ystem ({ROS})}, title = {{R}obot {O}perating {S}ystem ({ROS})},
author = {{Stanford Artificial Intelligence Laboratory et al.}}, author = {{Stanford Artificial Intelligence Laboratory et al.}},
howpublished = {\url{https://www.ros.org}} howpublished = {\url{https://www.ros.org}},
year = {[n.\,d.]}
} }
@inproceedings{Ruth2019ARsecurity, @inproceedings{Ruth2019ARsecurity,
title = {Secure multi-user content sharing for augmented reality applications}, title = {Secure multi-user content sharing for augmented reality applications},
@@ -149,20 +168,24 @@
@misc{TrackingPointsWorldSpace, @misc{TrackingPointsWorldSpace,
title = {Tracking Specific Points in World Space}, title = {Tracking Specific Points in World Space},
author = {{Apple Inc.}}, author = {{Apple Inc.}},
howpublished = {\url{https://developer.apple.com/documentation/visionos/tracking-points-in-world-space/}} howpublished = {\url{https://developer.apple.com/documentation/visionos/tracking-points-in-world-space/}},
year = {[n.\,d.]}
} }
@misc{unity_dots, @misc{unity_dots,
title = {{U}nity's {D}ata-{O}riented {T}echnology {S}tack (DOTS)}, title = {{U}nity's {D}ata-{O}riented {T}echnology {S}tack (DOTS)},
howpublished = {\url{https://unity.com/dots}} howpublished = {\url{https://unity.com/dots}},
year = {[n.\,d.]}
} }
@misc{unity_mars, @misc{unity_mars,
title = {{U}nity {M}ars --- {A}dvanced Workflows for {AR} Developers}, title = {{U}nity {M}ars --- {A}dvanced Workflows for {AR} Developers},
howpublished = {\url{https://unity.com/products/unity-mars}} howpublished = {\url{https://unity.com/products/unity-mars}},
year = {[n.\,d.]}
} }
@misc{UnityECSConcepts, @misc{UnityECSConcepts,
title = {Entity Component System Introduction}, title = {Entity Component System Introduction},
author = {{Unity Technologies}}, author = {{Unity Technologies}},
howpublished = {\url{https://docs.unity3d.com/Packages/com.unity.entities@1.3/manual/concepts-ecs.html}} howpublished = {\url{https://docs.unity3d.com/Packages/com.unity.entities@1.3/manual/concepts-ecs.html}},
year = {[n.\,d.]}
} }
@article{van2010survey, @article{van2010survey,
title = {A Survey of Augmented Reality Technologies, Applications and Limitations}, title = {A Survey of Augmented Reality Technologies, Applications and Limitations},
@@ -206,3 +229,9 @@
url = {https://www.microsoft.com/en-us/research/publication/combining-multiple-depth-cameras-and-projectors-for-interactions-on-above-and-between-surfaces/}, url = {https://www.microsoft.com/en-us/research/publication/combining-multiple-depth-cameras-and-projectors-for-interactions-on-above-and-between-surfaces/},
% booktitle = {UIST '10 Proceedings of the 23nd annual ACM symposium on User interface software and technology} % booktitle = {UIST '10 Proceedings of the 23nd annual ACM symposium on User interface software and technology}
} }
@misc{XDGDesktopPortals,
title = {XDG Desktop Portals},
author = {{freedesktop.org}},
howpublished = {\url{https://flatpak.github.io/xdg-desktop-portal/}},
year = {[n.\,d.]}
}

2
figures/bootstrap.drawio.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 82 KiB

784
main.tex
View File

@@ -1,54 +1,73 @@
% $Id: template.tex 11 2007-04-03 22:25:53Z jpeltier $ %% Commands for TeXCount
%TC:macro \cite [option:text,text]
%TC:macro \citep [option:text,text]
%TC:macro \citet [option:text,text]
%TC:envir table 0 1
%TC:envir table* 0 1
%TC:envir tabular [ignore] word
%TC:envir displaymath 0 word
%TC:envir math 0 word
%TC:envir comment 0 0
%%
%% The first command in your LaTeX source must be the \documentclass
%% command.
%%
%% For submission and review of your manuscript please change the
%% command to \documentclass[manuscript, screen, review]{acmart}.
%%
%% When submitting camera ready or to TAPS, please change the command
%% to \documentclass[sigconf]{acmart} or whichever template is required
%% for your publication.
%%
%%
%%\documentclass[sigconf,authordraft]{acmart}
\documentclass[manuscript,review,anonymous]{acmart}
%%\documentclass[manuscript,review]{acmart}
%%
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
\providecommand\BibTeX{{%
Bib\TeX}}}
%\documentclass{vgtc} % final (conference style) %% Rights management information. This information is sent to you
\documentclass[review]{vgtc} % review %% when you complete the rights form. These commands have SAMPLE
%\documentclass[widereview]{vgtc} % wide-spaced review %% values in them; it is your responsibility as an author to replace
%\documentclass[preprint]{vgtc} % preprint %% the commands and values with those provided to you when you
%\documentclass[electronic]{vgtc} % electronic version %% complete the rights form.
\setcopyright{acmlicensed}
%% Uncomment one of the lines above depending on where your paper is \copyrightyear{2018}
%% in the conference process. ``review'' and ``widereview'' are for review \acmYear{2018}
%% submission, ``preprint'' is for pre-publication, and the final version \acmDOI{XXXXXXX.XXXXXXX}
%% doesn't use a specific qualifier. Further, ``electronic'' includes %% These commands are for a PROCEEDINGS abstract or paper.
%% hyperreferences for more convenient online viewing. \acmConference[Conference acronym 'XX]{Make sure to enter the correct
conference title from your rights confirmation email}{June 03--05,
%% Please use one of the ``review'' options in combination with the 2018}{Woodstock, NY}
%% assigned online id (see below) ONLY if your paper uses a double blind %%
%% review process. Some conferences, like IEEE Vis and InfoVis, have NOT %% Uncomment \acmBooktitle if the title of the proceedings is different
%% in the past. %% from ``Proceedings of ...''!
%%
%% Figures should be in CMYK or Grey scale format, otherwise, colour %%\acmBooktitle{Woodstock '18: ACM Symposium on Neural Gaze Detection,
%% shifting may occur during the printing process. %% June 03--05, 2018, Woodstock, NY}
\acmISBN{978-1-4503-XXXX-X/2018/06}
%% it is recomended to use ``\cref{sec:bla}'' instead of ``Fig.~\ref{sec:bla}''
\graphicspath{{figures/}{pictures/}{images/}{./}} % where to search for the images
\usepackage{times} % we use Times as the main font
\renewcommand*\ttdefault{txtt} % a nicer typewriter font
%% We encourage the use of mathptmx for consistent usage of times font
%% throughout the proceedings. However, if you encounter conflicts
%% with other math-related packages, you may want to disable it.
\usepackage{mathptmx} % use matching math font
%% Diogo's packages %% Diogo's packages
\usepackage[svgnames]{xcolor} \usepackage{cleveref}
\usepackage{svg} \usepackage{svg}
\usepackage{tabularx} \usepackage{tabularx}
\usepackage{booktabs} \usepackage{booktabs}
\usepackage{listings} \usepackage{listings}
\PassOptionsToPackage{hyphens}{url}\usepackage[pagebackref,bookmarks]{hyperref}
% Diogo Custom colours % Diogo Custom colours
\colorlet{punct}{red!60!black} \colorlet{punct}{red!60!black}
\definecolor{delim}{RGB}{20,105,176} \definecolor{delim}{RGB}{20,105,176}
\colorlet{numb}{magenta!60!black} \colorlet{numb}{magenta!60!black}
\lstdefinelanguage{json}{ \lstdefinelanguage{json}{
basicstyle=\normalfont\ttfamily, basicstyle=\footnotesize\ttfamily,
numbers=left, numbers=left,
numberstyle=\scriptsize, numberstyle=\scriptsize,
stepnumber=1, stepnumber=1,
numbersep=8pt, numbersep=8pt,
showtabs=false,
showstringspaces=false, showstringspaces=false,
breaklines=true, breaklines=true,
frame=single, frame=single,
@@ -71,100 +90,149 @@
{]}{{{\color{delim}{]}}}}{1}, {]}{{{\color{delim}{]}}}}{1},
} }
%% If you are submitting a paper to a conference for review with a double %%
%% blind reviewing process, please replace the value ``0'' below with your %% Submission ID.
%% OnlineID. Otherwise, you may safely leave it at ``0''. %% Use this when submitting an article to a sponsored event. You'll
\onlineid{1429} %% receive a unique submission ID from the organizers
%% of the event, and this ID should be used as the parameter to this command.
%%\acmSubmissionID{123-A56-BU3}
%% declare the category of your paper, only shown in review mode %%
\vgtccategory{Software architectures, toolkits, and engineering} %% For managing citations, it is recommended to use bibliography
%% files in BibTeX format.
%%
%% You can then either use BibTeX with the ACM-Reference-Format style,
%% or BibLaTeX with the acmnumeric or acmauthoryear sytles, that include
%% support for advanced citation of software artefact from the
%% biblatex-software package, also separately available on CTAN.
%%
%% Look at the sample-*-biblatex.tex files for templates showcasing
%% the biblatex styles.
%%
%% allow for this line if you want the electronic option to work properly %%
\vgtcinsertpkg %% The majority of ACM publications use numbered citations and
%% references. The command \citestyle{authoryear} switches to the
%% In preprint mode you may define your own headline. If not, the default IEEE copyright message will appear in preprint mode. %% "author year" style.
%\preprinttext{To appear in an IEEE VGTC sponsored conference.} %%
%% If you are preparing content for an event
%% This adds a link to the version of the paper on IEEEXplore %% sponsored by ACM SIGGRAPH, you must use the "author year" style of
%% Uncomment this line when you produce a preprint version of the article %% citations and references.
%% after the article receives a DOI for the paper from IEEE %% Uncommenting
%\ieeedoi{xx.xxxx/TVCG.201x.xxxxxxx} %% the next command will enable that style.
%%\citestyle{acmauthoryear}
%% Paper title. %%
%% end of the preamble, start of the body of the document source.
\title{AURA: The Augmented Reality Unified Representation Architecture}
%% This is how authors are specified in the conference style
%% Author and Affiliation (single author).
%%\author{Roy G. Biv\thanks{e-mail: roy.g.biv@aol.com}}
%%\affiliation{\scriptsize Allied Widgets Research}
%% Author and Affiliation (multiple authors with single affiliations).
%%\author{Roy G. Biv\thanks{e-mail: roy.g.biv@aol.com} %
%%\and Ed Grimley\thanks{e-mail:ed.grimley@aol.com} %
%%\and Martha Stewart\thanks{e-mail:martha.stewart@marthastewart.com}}
%%\affiliation{\scriptsize Martha Stewart Enterprises \\ Microsoft Research}
%% Author and Affiliation (multiple authors with multiple affiliations)
\author{Diogo Peralta Cordeiro\thanks{e-mail: mail@diogo.site} %
\and João Borges de Sousa\thanks{e-mail: jtasso@fe.up.pt}} %
\affiliation{\scriptsize University of Porto}
%% A teaser figure can be included as follows
\teaser{
\centering
\includesvg[inkscapelatex=false, width=\linewidth]{figures/teaser.drawio.svg}
\caption{Overview of AURA's role during multi-application deployment.
a) An AURA-based system scans the room, and independently launched applications submit their spatial and behavioural requirements through AURA manifests.
b) The AURA-powered Head-Mounted Display (HMD) identifies suitable components in the environment and, with user input, assigns them to each application by creating dedicated ambients (e.g., $\alpha_1$, $\alpha_2$). This allows Application 1 and 2 to coexist within the same room.}
\label{fig:teaser}
}
%% Abstract section.
\abstract{
Augmented Reality (AR) integrates digital content into physical space across diverse platforms, including projection systems, head-mounted displays, and mobile devices. However, current AR frameworks lack a standardized, platform-independent method for applications to declare their spatial and system-level requirements. This fragmentation complicates cross-platform development, and hinders the coexistence of multiple AR applications within the same environment.
We introduce AURA --- the \textbf{A}ugmented Reality \textbf{U}nified \textbf{R}epresentation \textbf{A}rchitecture ---, which defines a manifest format through which applications specify their spatial components, interactive elements, participating agents, and required system resource needs. AURA enables multiple applications to run concurrently by assigning them to scoped containers and managing their access to shared physical surfaces. AURA also supports dynamic, context-aware behaviour via event-driven triggers and system-mediated data exchanges at runtime. Through examples, we demonstrate how AURA facilitates cross-platform development and application interoperability.
} % end of abstract
%% Keywords that describe your work. Will show as 'Index Terms' in journal
%% please capitalize first letter and insert punctuation after last keyword.
\keywords{Ubiquitous computing, multi-application interoperability, interactive spaces, spatial computing, augmented reality, application manifest, human-machine interaction, interaction design.}
%% Copyright space is enabled by default as required by guidelines.
%% It is disabled by the 'review' option or via the following command:
% \nocopyrightspace
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%% START OF THE PAPER %%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document} \begin{document}
%% The ``\maketitle'' command must be the first command after the %%
%% ``\begin{document}'' command. It prepares and prints the title block. %% The "title" command has an optional parameter,
%% allowing the author to define a "short title" to be used in page headers.
\title{AURA: The Augmented Reality Unified Representation Architecture}
%% the only exception to this rule is the \firstsection command %%
\firstsection{Introduction} %% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
%% Of note is the shared affiliation of the first two authors, and the
%% "authornote" and "authornotemark" commands
%% used to denote shared contribution to the research.
\author{Diogo Peralta Cordeiro}
\email{mail@diogo.site}
\orcid{0000-0002-0260-5121}
\author{João Borges de Sousa}
\email{jtasso@fe.up.pt}
\orcid{0000-0002-2528-4666}
\affiliation{%
\institution{University of Porto}
\city{Porto}
\country{Portugal}
}
%%
%% By default, the full list of authors will be used in the page
%% headers. Often, this list is too long, and will overlap
%% other information printed in the page headers. This command allows
%% the author to define a more concise list
%% of authors' names for this purpose.
\renewcommand{\shortauthors}{Diogo et al.}
%%
%% The abstract is a short summary of the work to be presented in the
%% article.
\begin{abstract}
Augmented Reality (AR) integrates digital content into physical space across diverse platforms, including projection systems, head-mounted displays, and mobile devices. However, current AR frameworks lack a standardized, platform-independent method for applications to declare their spatial and system-level requirements. This fragmentation complicates cross-platform development, and hinders the coexistence of multiple AR applications within the same environment.
We introduce AURA --- the \textbf{A}ugmented Reality \textbf{U}nified \textbf{R}epresentation \textbf{A}rchitecture ---, which defines a manifest format through which applications specify their spatial components, interactive elements, participating agents, and required system resources. AURA enables multiple applications to run concurrently by assigning them to scoped containers and managing their access to shared physical surfaces. AURA also supports dynamic, context-aware behaviour via event-driven triggers and system-mediated data exchanges at runtime. Through examples, we demonstrate how AURA facilitates cross-platform development and application interoperability.
\end{abstract}
%%
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
%% Please copy and paste the code instead of the example below.
%%
\begin{CCSXML}
<ccs2012>
<concept>
<concept_id>10003120.10003121.10003124.10010392</concept_id>
<concept_desc>Human-centered computing~Mixed / augmented reality</concept_desc>
<concept_significance>500</concept_significance>
</concept>
<concept>
<concept_id>10003120.10003138.10003139.10010904</concept_id>
<concept_desc>Human-centered computing~Ubiquitous computing</concept_desc>
<concept_significance>300</concept_significance>
</concept>
<concept>
<concept_id>10003120.10003123</concept_id>
<concept_desc>Human-centered computing~Interaction design</concept_desc>
<concept_significance>100</concept_significance>
</concept>
</ccs2012>
\end{CCSXML}
\ccsdesc[500]{Human-centered computing~Mixed / augmented reality}
\ccsdesc[300]{Human-centered computing~Ubiquitous computing}
\ccsdesc[100]{Human-centered computing~Interaction design}
%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
\keywords{Spatial Computing, Application Manifest, Multi-application Systems, Intelligent Environments, Machine Perception, Interactive Spaces}
%% A "teaser" image appears between the author and affiliation
%% information and the body of the document, and typically spans the
%% page.
\begin{teaserfigure}
\centering
\includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/teaser.drawio.svg}
\caption{Overview of AURA's role during multi-application deployment.
a) An AURA-based system scans the room, and independently created and launched applications submit their spatial and behavioural requirements through AURA manifests.
b) The AURA-powered Head-Mounted Display (HMD) identifies suitable components in the environment and, with user input, assigns them to each application by creating dedicated ambients (e.g., $\alpha_1$, $\alpha_2$). This allows Applications 1 and 2 to coexist within the same room.}
\label{fig:teaser}
\end{teaserfigure}
\received{20 February 2007}
\received[revised]{12 March 2009}
\received[accepted]{5 June 2009}
%%
%% This command processes the author and affiliation and title
%% information and builds the first part of the formatted document.
\maketitle \maketitle
%% \section{Introduction} %for journal use above \firstsection{..} instead \section{Introduction}
Augmented Reality (AR) is emerging as a key paradigm for immersive computing, blending digital content with the physical world in real time. Despite rapid advances in hardware and toolkits, developing AR applications today remains a fragmented endeavor. Different platforms (e.g., mobile AR toolkits, smartglasses) and engines (Unity, Unreal, etc.) impose distinct content representations and siloed runtime contexts. This fragmentation makes it difficult to coordinate multiple AR experiences together. In practice, users are confined to one AR application at a time, and there is no straightforward way to allow multiple AR apps to augment the environment concurrently \cite{huynh2022layerable}. These gaps highlight a pressing need for a unifying framework that can represent AR content in a platform-agnostic, shareable manner across applications. Augmented Reality (AR) is emerging as a key paradigm for immersive computing, blending digital content with the physical world in real time. Despite rapid advances in hardware and toolkits, developing AR applications today remains a fragmented endeavour. Different platforms (e.g., mobile AR toolkits, smart-glasses) and engines (Unity, Unreal, etc.) impose distinct content representations and siloed runtime contexts. This fragmentation makes it difficult to coordinate multiple AR experiences together. In practice, users are confined to one AR application at a time, and there is no straightforward way to allow multiple AR apps to augment the environment concurrently \cite{huynh2022layerable}.
Most existing AR development platforms, such as Unity's XR Interaction Toolkit and Unreal Engine's AR APIs, are geared toward building single-application experiences. These tools provide abstractions for tracking, rendering, and input (for example, ARKit provides world tracking and scene understanding \cite{ARKitDocumentation}, and ARCore offers similar capabilities on Android \cite{ARCoreDocumentation}), but they lack a standardized model for representing application structure, coordinating access to physical components, or supporting interaction logic across applications. Unity's XR Interaction Toolkit, for instance, is a ``high-level, component-based, interaction system for creating VR and AR experiences' \cite{AndroidXRUnity}, focused on common interactions within one app. This single-app focus limits scalability, complicates cross-platform deployment, and hinders the development of multi-application AR environments. Most existing AR development platforms, such as Unity's XR Interaction Toolkit and Unreal Engine's AR APIs, are geared toward building single-application experiences. These tools provide abstractions for tracking, rendering, and input (for example, ARKit provides world tracking and scene understanding \cite{ARKitDocumentation}, and ARCore offers similar capabilities on Android \cite{ARCoreDocumentation}), but they lack a standardized model for representing application structure, coordinating access to physical components, or supporting interaction logic across applications. Unity's XR Interaction Toolkit, for instance, is a ``high-level, component-based, interaction system for creating VR and AR experiences'' \cite{AndroidXRUnity}, focused on common interactions within one application. This single-app focus limits scalability, complicates cross-platform deployment, and hinders the development of multi-application AR environments.
The motivation for AURA stems from several observations. First, current AR experiences are typically built in isolation: there is no standard way for one AR app to expose its content or to incorporate content from others. This not only limits content reuse but also prevents compelling multi-application scenarios --- for example, a navigation app and a social AR app cannot easily co-exist and share the view \cite{lebeck2019multiple}. Second, prior efforts to standardize AR content (such as AR markup languages or model-based UI design tools) have not been widely adopted by today's AR platforms, which favor imperative and engine-specific approaches. Third, as AR moves towards mainstream use, there is a growing need for cross-application interoperability and consistency, akin to how web browsers unified content on the Internet. AURA directly addresses these needs by providing a unified representation layer that sits between AR applications and the underlying AR runtime or operating system. By doing so, it facilitates interoperability, easier content creation, and safer multi-source augmentation (ensuring that virtual objects from different apps can coexist without conflict). The motivation for AURA stems from several observations. First, current AR experiences are typically built in isolation: there is no standard way for one AR application to expose its content or to incorporate content from others. This not only limits content reuse but also prevents compelling multi-application scenarios --- for example, a navigation app and a social AR app cannot easily co-exist and share the view \cite{lebeck2019multiple}. Second, prior efforts to standardize AR content (such as AR markup languages or model-based UI design tools) have not been widely adopted by today's AR platforms, which favour imperative and engine-specific approaches. Third, as AR moves towards mainstream use, there is a growing need for cross-application interoperability and consistency, akin to how web browsers unified content on the Internet. AURA directly addresses these needs by providing a unified representation layer that sits between AR applications and the underlying AR runtime or operating system. By doing so, it facilitates interoperability, simplifies content creation, and enables safer multi-source augmentation (ensuring that virtual objects from different apps can coexist without conflict).
We introduce AURA --- the \textbf{A}ugmented Reality \textbf{U}nified \textbf{R}epresentation \textbf{A}rchitecture --- a different approach to structuring AR applications and coordinating their behaviour within shared spatial environments. At its core, AURA introduces a manifest format that allows applications to formally declare their spatial and behavioural requirements, including entities, components, agents, and interaction logic. The system, in turn, defines the runtime context: available physical components, spatial subdivisions (\textit{ambients} and \textit{worlds}), and mappings between devices and applications. AURA is a different approach to structuring AR applications and coordinating their behaviour within shared spatial environments. At its core, AURA introduces a manifest format that allows applications to formally declare their spatial and behavioural requirements, including entities, components, agents, and interaction logic. The AURA-based system, in turn, guides the runtime context definition: available physical components, spatial subdivisions (\textit{ambients} and \textit{worlds}), and mappings between devices and applications.
AURA adopts terminology and structuring principles inspired by the Entity-Component-System (ECS) architecture, widely used in interactive software. Modern AR engines increasingly embrace ECS for performance and modularity (e.g., Apple's RealityKit uses an ECS design for AR scene content \cite{AppleRealityKitChapter9}, and Unity's DOTS ECS framework enables data-oriented high-performance AR/VR simulations \cite{unity_dots}). In AURA's architecture, entities are logical sets of components (which represent tracked surfaces, spatial areas, or physical devices), while the AURA-based runtime plays the role of the ``system'' in ECS --- it observes the physical space and mediates application runtime and agent interactions.
Importantly, AURA does not enforce a single global spatial model. Instead, each application is bound to an ambient-scoped view, enabling coexistence through a layered abstraction of space. The \textit{``unified''} nature of AURA refers to its consistent runtime contract: all applications interface with the system using a common schema, while the system tracks general interaction and coordinates access to components without requiring direct inter-application communication. Importantly, AURA does not enforce a single global spatial model. Instead, each application is bound to an ambient-scoped view, enabling coexistence through a layered abstraction of space. The \textit{``unified''} nature of AURA refers to its consistent runtime contract: all applications interface with the system using a common schema, while the system tracks general interaction and coordinates access to components without requiring direct inter-application communication.
To ground the architecture in a tangible scenario, \cref{fig:teaser} illustrates how AURA supports runtime coordination across multiple independent AR applications. In (a), two applications submit their manifests to an AURA-based system, which parses their spatial and behavioural requirements. In (b), the system creates an ambient for each application, which maps them within the physical space --- ensuring non-conflicting use of shared surfaces --- while enabling the user to intervene in the mapping process. The user can then interact with both applications in the same room. AURA enables: To ground the architecture in a tangible scenario, \cref{fig:teaser} illustrates how AURA supports runtime coordination across multiple independent AR applications. In (a), two applications submit their manifests to an AURA-based system, which parses their spatial and behavioural requirements. In (b), the system creates an ambient for each application, mapping them onto the physical space while preventing conflicts over shared surfaces. The mapping process remains user-adjustable, and interaction occurs via an HMD-based system --- though AURA abstracts away the underlying platform, as discussed later. AURA enables:
\begin{itemize} \begin{itemize}
\item Standardized definition of application structure, including components, entities, interaction logic, devices, and performance requirements; \item Standardized definition of application structure, including components, entities, interaction logic, devices, and performance requirements;
\item Concurrent execution of multiple AR applications in shared physical environments without conflict, enabling true coexistence; \item Concurrent execution of multiple AR applications in shared physical environments without conflict, enabling true coexistence;
@@ -173,32 +241,31 @@ To ground the architecture in a tangible scenario, \cref{fig:teaser} illustrates
In this paper, we present the core AURA specification and demonstrate how it enables scalable, interoperable, and modular AR systems. We focus on its support for application isolation, declarative interaction modelling, and conflict-free coordination of shared resources. Future work will explore runtime extensions such as probabilistic reasoning, formal validation, and distributed orchestration across heterogeneous AR platforms. In this paper, we present the core AURA specification and demonstrate how it enables scalable, interoperable, and modular AR systems. We focus on its support for application isolation, declarative interaction modelling, and conflict-free coordination of shared resources. Future work will explore runtime extensions such as probabilistic reasoning, formal validation, and distributed orchestration across heterogeneous AR platforms.
\section{Background and Related Work} \section{Background and Related Work}
AURA builds upon concepts from software architecture, human-computer interaction (HCI), and AR system design. In this section, we review the key areas of prior work that inform our approach, and we clarify how AURA differentiates itself from or extends these foundations. We first discuss the Entity-Component-System pattern as used in interactive systems and its relevance to AR content structuring. We then draw parallels to application manifest frameworks in other domains, which inspire AURA's declarative approach. Next, we examine past efforts in modeling and specifying AR applications (such as SSIML/AR and AR markup languages) that aimed to generalize AR development. Finally, we consider the challenge of cross-application AR and how existing platforms and research address --- or fail to address --- concurrent AR experiences. AURA builds upon concepts from software architecture, human-computer interaction (HCI), and AR system design. In this section, we review the key areas of prior work that inform our approach, and we clarify how AURA differentiates itself from or extends these foundations. We first discuss the Entity-Component-System pattern as used in interactive systems and its relevance to AR content structuring. We then draw parallels to application manifest frameworks in other domains, which inspire AURA's declarative approach. Next, we examine past efforts in modelling and specifying AR applications (such as SSIML/AR and AR markup languages) that aimed to generalize AR development. Finally, we consider the challenge of cross-application AR and how existing platforms and research address --- or fail to address --- concurrent AR experiences.
\subsection{Augmented Reality Technologies} %\subsection{Augmented Reality Technologies}
\begin{figure}[htbp] %\begin{figure}[htbp]
\centering % \centering
\includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/map_of_field.svg} % \includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/map_of_field.svg}
\caption{Augmented Reality as a form of Extended Reality.}\label{fig:ar_in_xr} % \caption{Augmented Reality as a form of Extended Reality.}\label{fig:ar_in_xr}
\end{figure} %\end{figure}
As illustrated in \cref{fig:ar_in_xr}, Augmented Reality is distinct from other forms of Extended Reality (XR). While Virtual Reality (VR) immerses users entirely within a simulated environment, and Mixed Reality (MR) tightly blends physical and virtual elements through real-time spatial alignment, AR focuses on enriching the user's perception of the physical world by adding digital elements in one or more modalities --- most commonly visual, but also aural, haptic or olfatory. AR systems can be broadly classified into three categories~\cite{van2010survey}: %As illustrated in \cref{fig:ar_in_xr}, Augmented Reality is distinct from other forms of Extended Reality (XR). While Virtual Reality (VR) immerses users entirely within a simulated environment, and Mixed Reality (MR) tightly blends physical and virtual elements through real-time spatial alignment, AR focuses on enriching the user's perception of the physical world by adding digital elements in one or more modalities --- most commonly visual, but also aural, haptic or olfatory. AR systems can be broadly classified into three categories~\cite{van2010survey}:
\begin{enumerate} %\begin{enumerate}
\item \textbf{Projection-Based AR:} These systems use projectors to overlay digital content onto physical surfaces, enabling shared experiences without the need for individual HMDs. Such systems have been explored extensively in applications like collaborative design, education, and entertainment. % \item \textbf{Projection-Based AR:} These systems use projectors to overlay digital content onto physical surfaces, enabling shared experiences without the need for individual HMDs. Such systems have been explored extensively in applications like collaborative design, education, and entertainment.
\item \textbf{Video See-Through AR:} In this approach, a live video feed of the real world is combined with virtual graphics before display. Most mobile AR applications (e.g., on smartphones or tablets using ARKit/ARCore) and some headsets, such as Apple Vision Pro, use video see-through; the device's camera provides the view of the world and virtual content is composited into the feed in real time. % \item \textbf{Video See-Through AR:} In this approach, a live video feed of the real world is combined with virtual graphics before display. Most mobile AR applications (e.g., on smartphones or tablets using ARKit/ARCore) and some headsets, such as Apple Vision Pro, use video see-through; the device's camera provides the view of the world and virtual content is composited into the feed in real time.
\item \textbf{Optical See-Through AR:} These are headsets that use transparent displays to superimpose light on the user's view of the real world, such as Microsoft HoloLens or Magic Leap. This allows users to see the real environment directly with their eyes while holographic images appear integrated into their surroundings. % \item \textbf{Optical See-Through AR:} These are headsets that use transparent displays to superimpose light on the user's view of the real world, such as Microsoft HoloLens or Magic Leap. This allows users to see the real environment directly with their eyes while holographic images appear integrated into their surroundings.
\end{enumerate} %\end{enumerate}
Each of these technological classes comes with different capabilities and interaction modalities, as well as their own set of strengths and challenges, such as the accuracy of the alignment of virtual and physical elements, and user experience consistency. However, regardless of display method, developers face similar software challenges in structuring AR content and interactions. Current AR development frameworks like ARKit/ARCore abstract many low-level details (tracking, sensor fusion, rendering) \cite{ARKitDocumentation}, yet developers still work in imperative terms (placing objects, writing event handlers) within a single app's context. AURA instead introduces a higher-level, declarative layer on top of such runtimes, enabling the definition of AR content and behaviour in a way that is agnostic to the underlying AR rendering technology and that permits multiple applications to share the same physical space. %Each of these technological classes comes with different capabilities and interaction modalities, as well as their own set of strengths and challenges, such as the accuracy of the alignment of virtual and physical elements, and user experience consistency. However, regardless of display method, developers face similar software challenges in structuring AR content and interactions. Current AR development frameworks like ARKit/ARCore abstract many low-level details (tracking, sensor fusion, rendering) \cite{ARKitDocumentation}, yet developers still work in imperative terms (placing objects, writing event handlers) within a single app's context. AURA instead introduces a higher-level, declarative layer on top of such runtimes, enabling the definition of AR content and behaviour in a way that is agnostic to the underlying AR rendering technology and that permits multiple applications to share the same physical space.
\subsection{Entity Component System Architecture in AR} \subsection{Entity Component System Architecture in AR}
Entity-Component-System (ECS) is a software architecture pattern that promotes composition over inheritance, separating data (components) from behaviour (systems) for better modularity and performance. ECS has proven especially useful in game development and interactive simulations, where many objects share behaviour patterns but differ in data. Modern AR engines have begun to adopt ECS principles. For example, Apple's RealityKit employs a modular ECS design: AR developers define entities and attach components (such as geometries, physics bodies, or anchors) to those entities, and define systems that operate on all entities with certain components. \cite{AppleRealityKitChapter9} Unity's DOTS framework similarly provides an ECS paradigm to improve performance in complex scenes, including AR/VR scenarios, by processing entities in bulk with optimized memory access patterns. In these engines, an \textit{entity} is typically a container or identifier, \textit{components} encapsulate attributes like position or visual mesh, and \textit{systems} run logic (e.g., physics or animation) on all entities possessing the requisite components. \cite{UnityECSConcepts} The Entity-Component-System (ECS) architecture separates data (components) from logic (systems), enabling modular, efficient representation of interactive environments. This pattern has seen widespread adoption in game development and is increasingly embraced in AR engines. For instance, Apple's RealityKit employs an ECS-based design, where developers define entities and attach components (e.g., geometries, anchors, physics bodies) to them, with systems processing entities based on their components \cite{AppleRealityKitChapter9}. Similarly, Unity's DOTS ECS framework improves runtime performance by processing large numbers of entities using data-oriented memory access patterns, including in AR/VR contexts \cite{UnityECSConcepts}.
The ECS pattern is relevant to AR not only for performance, but also for managing the dynamic, heterogeneous content that AR applications involve. AR scenes consist of various elements --- surfaces, 3D models, UI widgets, sensors --- that can be naturally modeled as components attached to entities in a scene graph or structure. Adopting an ECS-like approach in a higher-level architecture can enable AR content to be described in a flexible, engine-neutral way. AURA leverages ECS-inspired structuring to describe AR application needs: each AURA Entity represents a logical object or grouping in the AR scene (for example, a ``PhotoWall'' or an ``Avatar'' might be entities), and each Component attached to it represents a specific facet or resource (e.g., a planar surface in the physical world, a spatial coordinate system, a displayable 3D model, or an I/O device like a camera or microphone). Unlike Unity or RealityKit where entities and components are used in code at runtime, AURA's use of ECS is declarative --- the manifest lists entities and their required components, and the system (runtime) ensures at runtime that those requirements are met by binding the entities to actual physical resources. AURA draws on ECS principles to structure declarative AR applications in a runtime-independent way. Each AURA Entity represents a logical construct (e.g., a ``PhotoWall''), while Components encapsulate spatial or functional capabilities such as display surfaces, coordinate systems, or I/O devices. Unlike engine-level ECS systems, where entities and components exist in runtime code, AURA's ECS model is expressed declaratively through JSON-LD manifests. The runtime acts as the system layer: it matches component requirements to physical resources and mediates interactions, enabling applications to remain engine-neutral and spatially adaptive.
\subsection{Declarative Manifest Models in Robotics, Web, and XR} \subsection{Declarative Manifest Models in Robotics, Web, and XR}
@@ -208,33 +275,35 @@ On the web, declarative formats are the norm for content: HTML, CSS, and related
There have also been efforts to introduce declarative approaches specifically in XR (extended reality) content. Notably, A-Frame (by Mozilla) is a web framework that allows AR/VR scenes to be written in HTML using custom tags. A-Frame internally follows an entity-component architecture and lets developers declare 3D entities and their components in markup form, which are then realized by the runtime in the browser \cite{AFrame}. The success of A-Frame (and related WebXR frameworks) in lowering the barrier for creating XR content demonstrates the power of declarative abstractions. However, these frameworks operate at the level of a single application's content (inside one webpage or session). There have also been efforts to introduce declarative approaches specifically in XR (extended reality) content. Notably, A-Frame (by Mozilla) is a web framework that allows AR/VR scenes to be written in HTML using custom tags. A-Frame internally follows an entity-component architecture and lets developers declare 3D entities and their components in markup form, which are then realized by the runtime in the browser \cite{AFrame}. The success of A-Frame (and related WebXR frameworks) in lowering the barrier for creating XR content demonstrates the power of declarative abstractions. However, these frameworks operate at the level of a single application's content (inside one webpage or session).
Another relevant concept is the model-based user interface (UI) design from HCI, where high-level models of interaction are defined and then transformed into concrete UI implementations. Languages like UIML and XAML allowed designers to specify interfaces in an abstract way. In the AR domain, prior work on model-based approaches (discussed next) attempted to do something similar for AR interfaces. AURA can be seen as a model-based approach for AR system configuration: the manifest is the model of an AR app's interface with the world, which the AURA system then ``implements'' by allocating real devices, coordinate spaces, and interaction handlers.
\subsection{AR Content Description Languages and Frameworks} \subsection{AR Content Description Languages and Frameworks}
The idea of a standardized description for AR applications has been explored in prior research, though with limited adoption in practice. One early effort was SSIML/AR (Scene Structure and Integration Modeling Language for AR), a visual language for the abstract specification of AR user interfaces. SSIML/AR, introduced by Vitzthum~\cite{vitzthum2006ssimlar}, extended a 3D UI modeling language (SSIML) to cover AR-specific constructs, allowing developers to model virtual objects, interactions, and the relationships between real and virtual entities at a high level. While SSIML/AR demonstrated the feasibility of describing AR application structure abstractly, it was primarily a design-time tool and did not see integration with mainstream AR runtimes. The idea of a standardized description for AR applications has been explored in prior research, though with limited adoption in practice. One early effort was SSIML/AR (Scene Structure and Integration Modelling Language for AR), a visual language for the abstract specification of AR user interfaces. SSIML/AR, introduced by Vitzthum~\cite{vitzthum2006ssimlar}, extended a 3D UI modeling language (SSIML) to cover AR-specific constructs, allowing developers to model virtual objects, interactions, and the relationships between real and virtual entities at a high level. While SSIML/AR demonstrated the feasibility of describing AR application structure abstractly, it was primarily a design-time tool and did not see integration with mainstream AR runtimes.
In industry, several AR markup or description formats have been proposed. The Open Geospatial Consortium's Augmented Reality Markup Language (ARML) 2.0 is an XML-based standard for AR content, finalized in 2015 \cite{OGC_ARML2_Adoption}. ARML 2.0 allows AR content providers to specify virtual objects with their visual properties and anchors in the real world, and it even defines an ECMAScript-based interface for dynamic behaviours and user interactions. ARML was used by some early AR browsers like Wikitude, Layar, and Junaio to share AR content across platforms \cite{OGC_ARML2_Adoption}. However, ARML did not achieve broad adoption in the era of ARKit/ARCore --- partly because those platforms opted for their own APIs, and partly because ARML's scope was limited to relatively static content (points of interest, 3D annotations) rather than full application logic. In industry, several AR markup or description formats have been proposed. The Open Geospatial Consortium's Augmented Reality Markup Language (ARML) 2.0 is an XML-based standard for AR content, finalized in 2015 \cite{OGC_ARML2_Adoption}. ARML 2.0 allows AR content providers to specify virtual objects with their visual properties and anchors in the real world, and it even defines an ECMAScript-based interface for dynamic behaviours and user interactions. ARML was used by some early AR browsers like Wikitude, Layar, and Junaio to share AR content across platforms \cite{OGC_ARML2_Adoption}. However, ARML did not achieve broad adoption in the era of ARKit/ARCore --- partly because those platforms opted for their own APIs, and partly because ARML's scope was limited to relatively static content (points of interest, 3D annotations) rather than full application logic.
Another example was Metaio's AREL (Augmented Reality Experience Language), introduced around 2011 as part of the Junaio AR browser. AREL combined XML and JavaScript to let developers define AR scenes and basic interactions which the browser could then execute. It was essentially a declarative layer on top of Metaio's AR engine. Metaio's approach was ahead of its time, but once Metaio was acquired (and its technology folded into Apple's ARKit), AREL was discontinued. The broader AR industry shifted focus to native SDKs and engine-based development, leaving a gap in terms of a unifying content specification. Another example was Metaio's AREL (Augmented Reality Experience Language), introduced around 2011 as part of the Junaio AR browser. AREL combined XML and JavaScript to let developers define AR scenes and basic interactions which the browser could then execute. It was essentially a declarative layer on top of Metaio's AR engine. Metaio's approach was ahead of its time, but once Metaio was acquired (and its technology folded into Apple's ARKit), AREL was discontinued. The broader AR industry shifted focus to native SDKs and engine-based development, leaving a gap in terms of a unifying content specification.
AURA's manifest draws upon these lessons: like SSIML/AR and ARML, it seeks a cross-platform description format for AR content. But it goes further by explicitly modeling not just content placement, but also \textbf{behavioural logic and multi-application coordination}. AURA manifests are written in JSON (specifically JSON-LD for semantic clarity) instead of XML, aligning with modern web technologies and developer preferences. AURA is designed to work at runtime, not just as an offline description. This means the system can load manifests on the fly, reason about resource assignments, and manage multiple running AR applications, which prior markup languages did not address. In that sense, AURA serves a role analogous to an operating system's window manager or app coordinator, using manifest declarations as input. AURA's manifest draws upon these lessons: like SSIML/AR and ARML, it seeks a cross-platform description format for AR content. But it goes further by explicitly modelling not just content placement, but also \textbf{behavioural logic and multi-application coordination}. AURA manifests are written in JSON (specifically JSON-LD for semantic clarity) instead of XML, aligning with modern web technologies and developer preferences. AURA is designed to work at runtime, not just as an offline description. This means the system can load manifests on the fly, reason about resource assignments, and manage multiple running AR applications, which prior markup languages did not address. In that sense, AURA serves a role analogous to an operating system's window manager or app coordinator, using manifest declarations as input.
\subsection{Multi-Application AR and Spatial Computing Platforms} \subsection{Multi-Application AR and Spatial Computing Platforms}
Supporting multiple concurrently running AR applications in a shared physical environment presents challenges related to visual consistency, interaction integrity, and resource management. Although commercial platforms have made strides in spatial persistence and immersive UI, robust multi-application AR remains largely unsupported. Prior work such as Huynh et al.'s ``Layerable Apps'' \cite{huynh2022layerable} and Lebeck et al.'s early analysis of AR runtime conflicts \cite{lebeck2019multiple} highlights user interest in multi-app usage and the architectural shortcomings that impede it. In this section, we compare the architectural approaches of leading platforms --- including Microsoft HoloLens, Apple Vision Pro and ARKit, Magic Leap, Meta Quest, and Android ARCore --- across three dimensions: (1) spatial anchoring and persistence, (2) multi-application coexistence and spatial partitioning, and (3) runtime architecture and resource arbitration. We also contrast these designs with AURA's manifest-based runtime coordination model. Supporting multiple concurrently running AR applications in a shared physical environment presents challenges related to visual consistency, interaction integrity, and resource management. Although commercial platforms have made strides in spatial persistence and immersive UI, robust multi-application AR remains largely unsupported. Prior work such as Huynh et al.'s ``Layerable Apps'' \cite{huynh2022layerable} and Lebeck et al.'s early analysis of AR runtime conflicts \cite{lebeck2019multiple} highlights user interest in multi-app usage and the architectural shortcomings that impede it. In this section, we compare the architectural approaches of leading platforms --- including Microsoft HoloLens, Apple Vision Pro and ARKit, Magic Leap, Meta Quest, and Android ARCore --- across three dimensions: (1) spatial anchoring and persistence, (2) multi-application coexistence and spatial partitioning, and (3) runtime architecture and resource arbitration. We also contrast these designs with AURA's manifest-based runtime coordination model.
\paragraph{Spatial Anchoring and Persistence.} Modern AR platforms support application-level persistence through spatial anchors. Microsoft's HoloLens enables persistent and shareable anchors\cite{MicrosoftSpatialAnchors} via Azure Spatial Anchors\cite{MicrosoftLearnAzureSpatialAnchors}, though anchor management remains scoped per application. Apple's ARKit supports ARWorldMaps for persistence \cite{ARWorldMap}, while visionOS extends this with automatic anchor restoration \cite{AppleVisionOS}. Magic Leap introduces environmental ``Spaces'' to persist and share spatial mappings \cite{MagicLeapSpacesApp}. Meta's Mixed Reality Utility Kit supports anchor persistence \cite{MetaSpatialAnchorsPersist}, while ARCore offers similar functionality with Cloud Anchors \cite{ARCoreCloudAnchors}. Despite this, all platforms treat anchors as per-app constructs without system-level coordination. In contrast, AURA introduces declarative anchor management via manifests, enabling coordinated anchor access, deduplication, and shared reference across applications. \paragraph{Spatial Anchoring and Persistence.} Modern AR platforms support application-level persistence through spatial anchors. Microsoft's HoloLens enables persistent and shareable anchors\cite{MicrosoftSpatialAnchors} via Azure Spatial Anchors\cite{MicrosoftLearnAzureSpatialAnchors}, though anchor management remains scoped per application. Apple's ARKit supports ARWorldMaps for persistence \cite{ARWorldMap}, while visionOS extends this with automatic anchor restoration \cite{AppleVisionOS}. Magic Leap introduces environmental ``Spaces'' to persist and share spatial mappings \cite{MagicLeapSpacesApp}. Meta's Mixed Reality Utility Kit supports anchor persistence \cite{MetaSpatialAnchorsPersist}, while ARCore offers similar functionality with Cloud Anchors \cite{ARCoreCloudAnchors}. Despite this, all platforms treat anchors as per-app constructs without system-level coordination. In contrast, AURA introduces declarative anchor management via manifests, enabling coordinated anchor access, no duplication, and shared reference across applications.
\paragraph{Multi-Application Coexistence and Spatial Partitioning.} HoloLens enforces single-immersive-app execution, allowing only auxiliary 2D apps to coexist spatially \cite{lebeck2019multiple}. Magic Leap One enabled limited concurrency via ``prisms'' that spatially confine app content\cite{MagicLeapPrisms}, though overlap is not strictly prevented\cite{lebeck2019multiple}. VisionOS adopts a ``Shared Space'' model \cite{AppleVisionOS}, allowing multiple windowed apps to coexist within a common coordinate frame while preserving visual separation via UI depth cues. AURA diverges by allowing multiple applications to share or isolate space via dynamic \textit{ambients} and \textit{worlds}. Conflict resolution is handled proactively through spatial declarations, allowing flexible partitioning or cooperative content merging. \paragraph{Multi-Application Coexistence and Spatial Partitioning.} HoloLens enforces single-immersive-app execution, allowing only auxiliary 2D apps to coexist spatially \cite{lebeck2019multiple}. Magic Leap One enabled limited concurrency via ``prisms'' that spatially confine app content\cite{MagicLeapPrisms}, though overlap is not strictly prevented\cite{lebeck2019multiple}. VisionOS adopts a ``Shared Space'' model \cite{AppleVisionOS}, allowing multiple windowed apps to coexist within a common coordinate frame while preserving visual separation via UI depth cues. AURA diverges by allowing multiple applications to share or isolate space via \textit{ambients} and \textit{worlds}. Conflict resolution is handled proactively through spatial declarations, allowing flexible partitioning or cooperative content merging.
\paragraph{Runtime Architecture and Resource Arbitration.} Most commercial platforms simplify runtime scheduling by enforcing app exclusivity (e.g. ARCore) or restricting sensor access (e.g. HoloLens). VisionOS offers more advanced scheduling via a centralized compositor and shared spatial services, but lacks app-level coordination mechanisms. Magic Leap distributes access with minimal arbitration. AURA introduces a runtime mediator that interprets resource requirements from manifests, enforcing policies such as exclusive vs. shareable component access. Inspired by OS-level resource scheduling, AURA enables fair usage of sensors, rendering pipelines, and memory through its declarative runtime interface. \paragraph{Runtime Architecture and Resource Arbitration.} While commercial AR platforms have advanced features like persistent anchoring and SLAM sharing, comprehensive multi-application support remains limited. Platforms such as HoloLens and ARCore typically isolate applications, whereas Magic Leap and visionOS permit concurrent execution with minimal inter-app coordination. For instance, Apple's visionOS enables multiple applications to run simultaneously in a Shared Space, allowing users to interact with various app windows concurrently \cite{AppleVisionOSRenderPipeline}. However, visionOS lacks explicit mechanisms for app-level coordination of shared resources, relying instead on system-level management for resource allocation and scheduling.
While commercial AR platforms have converged on persistent anchoring and SLAM sharing, true multi-application support remains limited or implicit. Their designs either isolate apps (HoloLens, ARCore), loosely separate them (Magic Leap, visionOS), or avoid concurrent execution altogether (Quest, Android). AURA bridges this gap by treating spatial context as a shared, declaratively-managed resource. It provides a unified runtime that understands each application's spatial, behavioural, and resource requirements upfront, enabling proactive conflict resolution, safe coexistence, and extensible inter-app communication. In contrast, AURA introduces a runtime mediator that interprets resource requirements from application manifests, enforcing policies such as exclusive or shared component access. This approach aims to enable fair usage of sensors, rendering pipelines, and memory through its declarative runtime interface. By treating spatial context as a shared, declaratively managed resource, AURA provides a unified runtime that comprehends each application's spatial, behavioural, and resource requirements upfront, facilitating proactive conflict resolution, safe coexistence, and extensible inter-application communication.
\section{Fundamental AURA Concepts} \section{AURA Architecture and Runtime}\label{sec:aura-architecture}
To fully understand how AURA manifests are structured, it is essential to introduce the core concepts that define how spaces, objects, agents, and application logic are represented and coordinated within the system. These concepts provide a shared vocabulary for developers and systems to ensure consistent behaviour across multi-application AR environments. \begin{figure*}
\centering
\includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/bootstrap.drawio.svg}
\caption{The AURA bootstrap process. Applications declare abstract requirements, the system proposes compatible components, user feedback finalizes mappings (and may suggest that certain components are used for certain entities), application acknowledges the ambient announcing final mappings, and runtime execution begins.}\label{fig:aura_bootstrap}
\end{figure*}
\begin{table*} \begin{table*}
\caption{Comparison Between the Application and System Manifests.}\label{tab:manifest_comparison} \caption{Comparison Between the Application and System Manifests.}\label{tab:manifest_comparison}
@@ -242,101 +311,214 @@ To fully understand how AURA manifests are structured, it is essential to introd
\toprule \toprule
& \textbf{Application Manifest} & \textbf{System Manifest} \\ & \textbf{Application Manifest} & \textbf{System Manifest} \\
\midrule \midrule
\textbf{Purpose} & Defines a AR application's structure, entities, and behaviour & Defines the physical AR environment, available components, and ambient setup \\ \textbf{Purpose} & Defines an AR application's structure, Component requirements, Entities and behaviour. & Defines the physical AR environment, available concrete components, and ambient and world setup. \\
\midrule \midrule
\textbf{Written by} & Application developers & AR system administrators (or generated by the host platform in function of user input) \\ \textbf{Written by} & Application's author. & AR System Administrator (or generated by the host platform in function of user input). \\
\midrule \midrule
\textbf{Scope} & Focuses on an individual AR application & Covers the entire AR environment, supporting multiple applications \\ \textbf{Scope} & Focuses on an individual AR application. & Covers the entire AR environment, supporting multiple applications. \\
\midrule \midrule
\textbf{Key Elements} & Agents, components, entities, interaction rules & Components (e.g., physical surfaces), ambients, worlds, applications \\ \textbf{Key Elements} & Agents, Components requirements, Entities, Variables, Heuristics. & Components (e.g., physical surfaces), Ambients, Worlds. \\
\midrule \midrule
\textbf{Flexibility} & Defines only application-specific requirements & Ensures system-wide consistency and cross-application compatibility \\ \textbf{Responsibility} & Defines only application-specific requirements. & Ensures fair multi-application coexistence and interoperability. \\
\bottomrule \bottomrule
\end{tabularx} \end{tabularx}
\end{table*} \end{table*}
AURA introduces two primary types of manifests: the \textbf{application manifest} and the \textbf{system manifest}. \cref{tab:manifest_comparison} outlines the key differences.
The separation into two manifests enables \textbf{modular design and interoperability}, allowing multiple applications to share and interact within the same AR environment without requiring changing application logic.
\subsection{Core Terms and Definitions}
\paragraph{Component} %Represent foundational tracked real-world elements such as table-tops, walls, or other physical surfaces. Each component is described by spatial attributes (position, orientation, and size) and may contain structured data storage for application use.
\paragraph{Entity} An application-defined construct declared in the \textit{application manifest}. It represents a visualisation or interaction unit mapped to one or more components. %Entities are annotated with state machines, instance limits, and interaction triggers, defining how the application behaves in response to external stimuli.
\paragraph{Agent} An active participant in the AR environment. Examples include users (e.g., a person interacting) or devices (e.g., cameras, projectors). Agents are associated with roles (e.g., interactor, sensor) and services.
\paragraph{Ambient} Defines a bounded spatial area where a AR application operates. Ambients group together components and associate them with specific agents such as tracking and output devices. An ambient defines a coherent coordinate space for runtime operations and ensures consistent interpretation of spatial information. Each ambient hosts exactly one application at runtime.
\paragraph{World} Optional container that groups multiple ambients under a shared context, enabling spatial continuity and cross-ambient data exchange. Worlds facilitate coordination between connected spaces (e.g., multiple rooms) and define high-level rules for data visibility and conflict resolution.
\subsection{AURA Bootstrap Procedure}
\begin{figure*}
\centering
\includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/bootstrap.drawio.svg}
\caption{High-level runtime setup sequence in AURA. An application submits its manifest to the system, which identifies suitable components based on the physical environment. The user selects preferred components for application entities, and the system finalizes component availability. Once the application confirms the mapping, the system begins tracking spatial interactions and managing observable states.}\label{fig:aura_bootstrap}
\end{figure*}
The runtime in AURA is grounded in a declarative interaction between applications, the system, and the user. Once an application submits its AURA manifest, the system analyses the application's component and spatial requirements. It then matches these requirements to available components in the physical environment, which may include tracked surfaces, devices, or spatial regions.
As shown in \cref{fig:aura_bootstrap}, the system suggests a set of candidate components for the user to map application entities onto. This manual or semi-automated mapping step allows flexibility and ensures spatial alignment between the application logic and the environment. After the user selects preferred components or regions, the system finalizes their availability and communicates the mapping back to the application.
Finally, the application confirms which components each of its entities will assume, and the system begins spatial tracking, event dispatching, and state monitoring. This staged initialization ensures safe coexistence of multiple applications, avoids resource conflicts, and enables AURA's modular and adaptive runtime model.
\subsection{Interaction Logic vs. Application Internals}
AURA manifests describe only the \textit{externally observable} behaviour of applications. Internal logic (e.g., current photo index, animation effects, or semantic intent) is encapsulated within the application and not exposed to the system. This separation ensures both modularity and flexibility.
\subsection{Shared Memory and Data Exchange}
\begin{figure*} \begin{figure*}
\centering \centering
\includesvg[inkscapelatex=false, width=\linewidth]{figures/sarm_basic_storage_concept.drawio.svg} \includesvg[inkscapelatex=false, width=\linewidth]{figures/sarm_basic_storage_concept.drawio.svg}
\caption{The System Manifest defines Worlds ($\omega_1$, $\omega_2$) and their associated Ambients ($\alpha_1..\alpha_6$). Each Application is tied to a unique Ambient (1:1 relationship). When an Application (e.g., $A_1$) accesses a Component's storage, the associated Ambient (e.g., $\alpha_1$) mediates access to the correct scoped storage view (e.g., $C_1$'s $\omega_1$ data). Thus, $A_1$, $A_2$, and $A_3$ share the same view of $C_1$, while $A_4$ and $A_5$/$A_6$ operate over isolated data contexts.}\label{fig:sarm_basic_storage_concept} \caption{The System Manifest defines Worlds ($\omega_1$, $\omega_2$) and their associated Ambients ($\alpha_1..\alpha_6$). Each Application is tied to a unique Ambient (1:1 relationship). When an Application (e.g., $A_1$) accesses a Component's storage, the associated Ambient (e.g., $\alpha_1$) mediates access to the correct scoped storage view (e.g., $C_1$'s $\omega_1$ data). Thus, $A_1$, $A_2$, and $A_3$ share the same view of $C_1$, while $A_4$ and $A_5$/$A_6$ operate over isolated data contexts.}\label{fig:shared_memory}
\end{figure*} \end{figure*}
AURA supports data exchange between applications by attaching shared memory to components. This enables coordination without direct dependencies between applications. In \cref{fig:sarm_basic_storage_concept} we show how worlds and ambients influence data exchange ensuring proper interoperability. AURA provides a structured and extensible runtime model for AR systems by decoupling application behaviour from system-level resource management. It defines a declarative interface through which applications describe, among other aspects, their structure (via entities), spatial requirements (via components), and interaction patterns (via heuristics), while the system governs spatial safety, coordination, and execution. This section formalizes the core abstractions in AURA, presents the manifest structure, and details runtime semantics including spatial bootstrapping, component-based memory, and cross-application communication strategy.
\paragraph{Component Storage} Each component in the system manifest may include a structured data store. Applications can read or write to this memory under defined constraints, enabling indirect coordination. For example, placing a virtual photo on a surface may involve storing its metadata in the corresponding component's data structure. \subsection{Fundamental Concepts and Vocabulary}\label{sec:core-concepts}
\paragraph{Event-Driven Exchange} Applications may subscribe to updates on component storage or spatial triggers. For example, an application might be notified when a hand enters a surface region or when another application modifies a shared component. AURA establishes a declarative and runtime-coordinated interface between applications and spatial environments, separating responsibilities between the application and the system running it. Each application must provide a static \textbf{application manifest} describing its structure, requirements, and expected behaviour. While the runtime does not strictly require it, we recommend that implementations of AURA maintain a dynamically generated and persistent \textbf{system manifest}, which reflects the physical environment and current component configuration. This supports introspection, debugging, and reproducibility across sessions. \Cref{tab:manifest_comparison} outlines the key differences between both manifest types.
\paragraph{Request-Based Exchange} Applications may query component storage or retrieve data snapshots for non-reactive coordination. AURA introduces a shared vocabulary to describe the relationships between abstract application logic and concrete spatial and system resources. These concepts enable multi-application environments to remain spatially coherent, interoperable, and conflict-free.
\subsection{Real World vs Virtual Objects} \paragraph{Component}
A system-defined unit representing a trackable physical structure (e.g., table top, wall), associated device interface (e.g., projector output), or spatial regions. Components are declared in the \textit{system manifest}, including their spatial attributes, capabilities (e.g., input/output modalities). In the \textit{application manifest}, developers declare component \textit{requirements} via abstract descriptions (e.g., minimum dimensions, modalities), which the system maps to real-world instances at runtime. Components serve as the physical anchor for interaction and information exchange. Elements created and managed internally by the application --- such as photos, UI widgets, or 3D models --- are not declared as components in AURA. However, they may be spatially anchored to or interact with components at runtime, as discussed in \cref{sec:virtual-elements}.
In AURA, physical structures such as a table-top or a wall are declared in the system manifest as components and then made available to applications via ambients. Entities in application manifests refer to abstract components that have to be mapped to one or more of the components made available in the system manifest. Then the application decides which components build each of its entities. \paragraph{Entity}
An application-defined abstraction representing a logical unit of interaction or visualization within the AR environment. Entities are declared in the \textit{application manifest} and are mapped at runtime to one or more components, which provide their physical presence. An entity may observe discrete (e.g., proximity triggers) and continuous (e.g., component velocity) variables derived from the system's observation of components, which it uses to drive its behaviour. It may also include heuristics that describe commonly observed patterns through invariant-based state definitions over components (See \cref{sec:heuristics}). While entities are not responsible for rendering or tracking directly, they define how application logic attaches to the environment through the system-managed spatial structure.
\textbf{Virtual objects} (e.g., photos, documents, avatars) exist only within application logic. They are \textit{not} declared in AURA. However, their presence and movement may be reflected using the shared memory attached to physical components. \paragraph{Agent}
An agent represents an active participant in the AR environment. Depending on the system, Agents may provide services such as position tracking, gesture detection, or visual output --- along with the access mode (e.g., event-driven or polling). In the \textit{application manifest}, the application describes desired and required services. During runtime, application agents are dynamically matched to available system-level agents. Multiple instances of a given agent type may coexist depending on application constraints.
\paragraph{Data-Driven Movement of Virtual Objects} Applications simulate movement by transferring associated metadata across component storages: \paragraph{Ambient}
An ambient defines a spatially and logically bounded context in which a single AR application is executed. Declared in the \textit{system manifest}, an ambient groups a set of components and agents under a coherent coordinate system and enforces application-level isolation. Each ambient is assigned exactly one application at runtime, ensuring exclusive access to its associated components for rendering and interaction. Ambients serve as the primary unit of spatial scoping in AURA: they restrict where an application can observe, modify, or produce output, and they mediate data flow between applications and the system. Although ambients are disjoint in terms of assigned components, they may participate in shared coordination via higher-level \textit{world}s.
\paragraph{World}
A world is a higher-level construct that groups multiple ambients into a shared spatial and semantic context. Declared in the \textit{system manifest}, a world defines global coordination rules --- such as data visibility, and access policies --- that apply across its ambients. Worlds enable interoperability between applications by allowing scoped observation of shared component storage and event communication. While ambients enforce application isolation, worlds provide a mechanism for structured coexistence and communication between applications that occupy distinct but related regions of space.
\paragraph{Manifest}
The pair of declarations that form AURA's contract: the application manifest defines what an app wants to do, while the system manifest declares what is possible in the environment. Together, they define a binding between abstract logic and physical reality. An application manifest is static while the system manifest may be updated during runtime.
\subsection{Runtime Initialization and Spatial Matching}\label{sec:aura-bootstrap}
As illustrated in \cref{fig:aura_bootstrap}, execution in AURA begins when a user launches one or more applications --- potentially authored by different third-party developers --- and each submits its manifest to the AURA-based system. The system analyses the spatial, sensory, and interaction requirements declared in the manifests and identifies suitable components in the physical space. The user may optionally assist in mapping these components to application entities, offering spatial preferences or intent. Based on this input, the system provides each application with an ambient that includes the available components and a proposed entity-to-component assignment. Each application then decides which of the assigned components to bind to its entities. At runtime, the system monitors spatial triggers, schedules component updates, routes input and output, and manages state transitions --- all according to the declarative contracts defined in the manifests and the final entity-to-component bindings.
This process ensures that:
\begin{itemize} \begin{itemize}
\item Selecting a photo from a wall moves its data from the wall's component storage to the user's hand; \item Component use is explicitly negotiated;
\item Dropping the photo on a table updates the table's storage and clears the hand. \item Runtime conflicts (e.g., overlapping visual output or sensor contention) are avoided up front;
\item System and application share a consistent understanding of spatial layout.
\end{itemize} \end{itemize}
\paragraph{Alternative Handling} Applications may choose to bypass AURA's data exchange, but doing so breaks interoperability. Virtual object tracking and manipulation should ideally align with AURA's shared memory model for consistent system behaviour and multi-application support. %\begin{enumerate}
% \item The application submits a manifest detailing component requirements, agents, and entities.
% \item The system resolves these requests against available resources and proposes candidate mappings.
% \item The user may review and confirm these mappings via a configuration interface or preset rules.
% \item The system finalizes the ambient and component assignments and sends the ambient specification back to the application.
% \item The application communicates back the entity-component attribution to the system. Which may be updated anytime during runtime by the application.
% \item Runtime execution begins, with the system mediating spatial tracking, input/output dispatch, and variable observation.
%\end{enumerate}
\subsection{Component Visibility and Application Access} %At runtime, the system:
%\begin{enumerate}
% \item Parses application manifests and validates spatial constraints;
% \item Validates that all non-disjoint ambient areas don't have common components;
% \item Resolves component mappings and injects coordinates into the application's declared referential;
% \item Routes sensor and actuator access through system-controlled proxies, enforcing access limitations;
% \item Emits events for observable triggers, allowing the application to respond;
% \item Mediates access to component data and sensors.
%\end{enumerate}
Roesner et al.~\cite{Ruth2019ARsecurity} explored security and privacy risks in composable AR systems, noting the importance of sandboxing and policy enforcement to prevent malicious or unintended interactions between coexisting applications. %Components may be shared between ambients as long as they are never simultaneously assigned --- disjoint regions. Applications may observe changes to a shared component's storage (within the same world) but cannot modify or output to it if it is not explicitly assigned within their ambient --- present in ambient's region.
AURA allows a component to be assigned to more than one ambient, as long as these ambients are not in the same physical space. The physical regions defined by each ambient must remain disjoint in their use of any shared component. %This declarative startup enables safe multi-application coexistence, supports mixed automated and user-directed spatial decisions, and ensures clear boundary definitions for application behaviour.
If an application references a component that is currently invisible (i.e., not within the ambient's spatial scope), it may still be notified of updates to its data through the event system, provided the component belongs to the same world. However, applications are strictly prohibited from showing output or writing data to components that are not available in their current ambient. This constraint prevents rendering or data conflicts when multiple applications share access to the same component. \subsection{Ambient Isolation and Security Guarantees}\label{sec:aura-security}
Such access rules ensure that each application operates within a well-scoped and conflict-free view of the AR environment while still enabling loosely coupled coordination and data exchange within shared worlds. AURA enforces strong isolation through its ambient-based execution model:
\begin{itemize}
\item Shared components must not be assigned to overlapping ambients;
\item Applications can only observe and write to components within their assigned ambient;
\item Outputs (e.g., visual rendering or actuator control) must target components currently available in the ambient;
\item Cross-ambient observation requires explicit world-scoped coordination.
\end{itemize}
\section{Manifests and Runtime in AURA} These constraints mitigate several threats outlined by Ruth et al.~\cite{Ruth2019ARsecurity}, including attempts by one user to (1) share unwanted or undesirable content, (2) see private content belonging to another user, or (3) manipulate another user's AR content. By scoping visibility and interaction to well-defined ambients, AURA provides strong default boundaries that prevent such interactions unless explicitly mediated.
To illustrate how AURA operates in practice, we examine an AR photo gallery application inspired by Microsoft LightSpace~\cite{wilson2010combining}, in which users interact with projected photos across physical surfaces. We describe how AURA defines system structure and application behaviour through two complementary JSON-LD-based manifests: the \textit{application manifest} and the \textit{system manifest}. Together, they define the logical, spatial, and operational interface between AR applications and their runtime environment. AURA also focuses on isolating applications from one another by design: components are non-shareable across ambient instances unless explicitly mediated. This helps limit multi-app interference but does not yet include inter-app communication controls or shared-world consistency guarantees, which remain future work.
\subsection{Component-Based Memory Sharing}\label{sec:component-memory}
Components in AURA expose structured data stores that act as shared memory spaces. This memory is accessible to the application assigned to the ambient the component belongs to, and may be readable across ambients if the component is part of a world.
AURA supports data exchange between applications by attaching shared memory to components. This enables coordination without direct dependencies between applications. In \cref{fig:shared_memory} we show how worlds and ambients influence data exchange ensuring proper interoperability.
\paragraph{Component Storage}
Each component in the system manifest includes a structured data store. Applications can read or write to this memory under defined constraints, enabling indirect coordination. For example, placing a virtual photo on a surface may involve storing its metadata in the corresponding component's data structure.
\paragraph{Data Scoping}
When components are in an ambient that is contained in a world, their memory is shared with all the other ambients that refer to the same component in the same world. Writes, however, are ambient-scoped and conflict-free. See \cref{fig:shared_memory}.
\paragraph{Event-Driven Access}
Applications may subscribe to updates on component storage, such as when another application modifies a shared component. For example, an application monitoring a movable surface could receive events when another application moves or drops a virtual photo on it in a different ambient on the same world.
\paragraph{Request-Based Access}
Applications can query current component storage or historical logs of changes, enabling snapshot-based reasoning.
\paragraph{Snapshot Consistency and System Responsibility}
The system --- not individual applications --- must be responsible for producing consistent snapshots of component memory. Since AURA does not provide global synchronization guarantees across applications, any attempt by applications to independently maintain histories of component updates could result in inconsistent event orderings. By delegating this responsibility to the runtime, AURA ensures a coherent view of temporal changes across the shared environment.
\subsection{Interaction Semantics with Component-Based Memory}\label{sec:virtual-elements}
AURA distinguishes between system-managed components and application-defined virtual elements. Virtual elements --- such as photos, tools, avatars, or icons --- are not explicitly declared in manifests, but their behavior can be grounded and made interoperable by binding them to component-based shared memory. This model allows for spatial anchoring, inter-application observability, and indirect coordination across loosely coupled applications.
\paragraph{Data-Driven Object Sharing Across Applications}
Consider a scenario where a user is cooking in the kitchen using a recipe application projected onto the countertop. Simultaneously, their family is seated in the living room, browsing a photo gallery displayed on the dining table via a separate AR application. Both applications are deployed in distinct ambients --- one for the kitchen, one for the living room --- but are part of the same world (a ``kitchenette'') and share access to a common physical component: a lightweight physical object (e.g., a serving plate or designated tag) declared in both ambients.
The user decides to share a recipe photo with the family. First, the recipe app copies the photo's metadata into the agent's (hand) component store. Then, the user transfers the data into the shared object's component store --- effectively ``placing'' the virtual photo onto the shared object. The user then physically tosses the object from the kitchen into the living room. Upon catching it, the family interacts with the photo gallery app. Since the gallery app can observe the shared component, it retrieves the updated memory and displays the photo. The family then drags the photo from the shared object onto the dining table, which becomes the new anchor for the virtual content.
\paragraph{Cross-Ambient Semantics via Worlds}
This interaction is only possible because both ambients --- kitchen and living room --- are part of the same AURA world. Within a world, shared components remain uniquely identified and consistently observable across ambients. Although the applications are logically separated, AURA's runtime sees the physical object as a single system-managed component. Thus, any update to its memory in one ambient becomes visible in the other, enabling seamless, asynchronous coordination. This declarative and spatially scoped approach to data exchange ensures interoperability without requiring direct app-to-app communication, supporting safe and modular interaction between independently authored applications.
\paragraph{Interoperability Constraints}
While applications are free to use proprietary formats or tracking logic for virtual objects, doing so outside AURA's shared memory model undermines interoperability. To ensure system-level coordination and reuse of spatial context, application logic should rely on AURA-declared components and ambient-bound storage. By doing so, developers preserve the benefits of modularity, observability, and runtime-managed consistency.
\subsection{Cross-Application Interoperability Mechanisms} \label{sec:xdg-portals}
Beyond structured, spatially scoped memory, AURA can benefit from integration with host-level \textbf{interoperability services} such as XDG Desktop Portals~\cite{XDGDesktopPortals}. These standardized interfaces enable applications to access system services --- like file dialogs, media capture, or clipboard operations --- in a sandboxed, user-mediated manner. They complement AURA's declarative model by enabling permissioned, OS-level interaction without requiring direct inter-application communication.
We envision the following AURA-specific extensions or use cases for portal-based services:
\begin{itemize}
\item \textbf{File and clipboard exchange:} Applications may export artefacts (e.g., annotated images, sensor logs) to the host filesystem or clipboard via standardized save or copy dialogs.
\item \textbf{Permissioned service bridging:} AURA applications can delegate cross-app requests (e.g., blob sharing, identity selection) to a system-defined portal agent, enabling interactions across app boundaries with explicit user consent.
\item \textbf{Visual output redirection:} Applications may request that rendered content be redirected to a different component or shared surface (e.g., projector, virtual screen), mediated by a media-sharing portal.
\item \textbf{Embedding legacy applications:} Apps that do not provide an AURA manifest --- such as conventional desktop programs --- may be wrapped via window-sharing portals and presented as visual agents or embedded surfaces within an ambient.
\end{itemize}
This hybrid model bridges the gap between AURA's tightly scoped, manifest-driven coordination and broader interoperability with traditional system services, allowing AR applications to coexist seamlessly with host applications and general-purpose OS environments.
\subsection{Heuristics and Observational State Modelling}\label{sec:heuristics}
AURA allows applications to define \textbf{heuristics} --- semantic abstractions over component-level variables --- to express observable states and their transitions. These definitions are included in the \textit{application manifest} and enable the system to assist applications by evaluating logical conditions on tracked variables and notifying them of relevant state changes. This mechanism supports a declarative programming model where application logic can respond to high-level events such as ``object rising'' or ``hand approaching surface'' rather than continuously polling system's sensors signals.
Heuristics are based on:
\begin{itemize}
\item \textbf{Discrete variables}, derived from Boolean conditions (e.g., \texttt{distance(agent, surface) < 0.3}), that encode binary spatial or contextual predicates.
\item \textbf{Continuous variables}, representing scalar or vector quantities (e.g., position, velocity, acceleration, light intensity), whose values evolve over time and are sampled by the runtime.
\end{itemize}
A heuristic consists of named \textit{states}, each defined by an \textit{invariant} --- a logical condition that must hold for the state to be considered active. Applications may optionally define a \textit{transition model} to describe likely or expected state progressions. While not enforced by the system, these transitions can support runtime optimizations such as smoothing, prediction, or performance improvements in tracking and projection. Developers should also specify an optional \textit{activation condition} --- a separate Boolean expression used to indicate when monitoring a state should become more frequent or prioritized.
The following example defines a \texttt{juggling ball} entity that transitions through states based on the vertical component of its velocity ($V.z$):
\begin{lstlisting}[language=json, numbers=none, caption={Juggling Ball Entity's Heuristic-Driven State Model.}]
"continuous_variables": {
"V": {"exp": "ball_surface.velocity", "sample_period_ms": 20}
}, "discrete_variables": {
"T": {"exp": "room_sensor.temperature > 30", "sample_period_ms": 1000},
"H": {"exp": "room_sensor.humidity > 10"}
}, "heuristics": {
"ball_surface": {
"states": {
"up": { "invariant": "V.z > 0", "activation": "distance(agent, ball_surface) < 0.5" },
"down": { "invariant": "V.z < 0", "activation": "distance(agent, ball_surface) < 0.5" },
"idle": { "invariant": "V.z = 0", "activation": "distance(agent, ball_surface) < 0.5" },
"miss": { "invariant": "V.z is unknown", "activation": "distance(agent, ball_surface) < 0.5" }
},
"transitions": { "idle": "up", "up": "idle", "idle": "down" }
} }
\end{lstlisting}
In the \texttt{idle} state definition, the system may apply a tolerance threshold (e.g., \texttt{abs(V.z) < 0.01}) to mitigate false positives caused by sensor noise or floating-point imprecision, thereby enhancing robustness. In future work, we aim to investigate adaptive strategies for threshold tuning, clarifying the boundary between system-level inference and application-specified semantics --- particularly in cases where precise control over state transitions is essential to application behaviour.
\paragraph{System Role and Guarantees}
Although heuristics are authored by the application, the system is responsible for evaluating them at runtime and reporting state transitions. It does not interpret their meaning or enforce transitions --- it merely tracks when invariants hold or are violated. This ensures that the semantics of the states remain under application control, preserving modularity and encapsulation.
Multiple applications may observe the same component and define different heuristics for it. Each application receives only the evaluated results of its own heuristics, even if they are in the same world, allowing for individualized interpretations without conflict. The activation mechanism helps AURA prioritize state monitoring dynamically, based on spatial or contextual relevance, without requiring global synchronization or explicit inter-application coordination.
\subsection{Semantic Interoperability and Ontology-Driven Reasoning}\label{sec:semantic-interop}
The AURA vocabulary is designed with extensibility in mind, leveraging JSON-LD for semantic richness. To ensure compatibility with emerging AR technologies and applications, developers can embed domain-specific vocabularies, link to external ontologies, and declare new types of services, components, or agents.
\textbf{Example Extensions:}
\begin{itemize}
\item Declaring IoT devices with established ontologies (e.g., SAREF, SOSA/SSN).
\item Describing specialized capabilities (e.g., ``surgical\_instrument\_tracking'').
\item Defining new interaction types for domain-specific use cases, such as medical or industrial applications.
\item Including metadata for accessibility features, such as haptic feedback or audio descriptions.
\item Enabling system reasoning over application intent (e.g., prioritizing alerts over background info).
\end{itemize}
Semantic metadata can also assist the runtime in resolving conflicts (e.g., prioritizing critical overlays), adapting interaction logic, or composing behaviours from multiple applications within a world.
\section{AURA Manifests: Example and Usage}
We illustrate AURA's architecture through an AR photo gallery application inspired by Microsoft LightSpace~\cite{wilson2010combining}, showcasing how photos can be explored and manipulated across physical surfaces in a multi-user setting. We describe how AURA defines system structure and application behaviour through two complementary JSON-LD-based manifests: the \textit{application manifest} and the \textit{system manifest}. Together, they define the logical, spatial, and operational interface between AR applications and their runtime environment.
\subsection{Application Manifest: Declaring Behaviour and Requirements} \subsection{Application Manifest: Declaring Behaviour and Requirements}
The \textbf{application manifest} is authored by its developer and provides a static declaration of an application's structure and requirements. It includes metadata, agent roles, abstract components, entity definitions, and interaction triggers. The application manifest is authored by its developer and provides a static declaration of an application's structure and requirements. It includes metadata, agent roles, components, entity definitions, and interaction triggers.
\paragraph{Application Metadata} \paragraph{Application Metadata}
Each application begins with basic metadata and spatial constraints: Each application begins with basic metadata and spatial constraints:
@@ -348,40 +530,37 @@ Each application begins with basic metadata and spatial constraints:
"version": "1.0", "version": "1.0",
"description": "Interactive photo gallery and viewer.", "description": "Interactive photo gallery and viewer.",
"dimensions": { "dimensions": {
"minimum_width": 1.5, "minimum_width": 1.5, "minimum_height": 1.0
"minimum_height": 1.0
}, },
"coordinate_system": "left-handed", "coordinate_system": ["type": "left-handed", origin: "bottom-left"],
"origin": "bottom-left"
} }
\end{lstlisting} \end{lstlisting}
This instructs the system to allocate space accordingly (ambient \texttt{dimensions}) and provide component coordinates within the declared frame and in a format understood by the application (\texttt{coordinate system}, \texttt{origin}). Here, the application requests a minimum ambient size (\texttt{dimensions}), along with the coordinate system and origin it expects for spatial referencing (\texttt{coordinate system}).
\paragraph{Agents} \paragraph{Agents}
Agents represent users or sensing/actuation devices. If we need video or output over the entire ambient, we would define these devices as agents in this block. Here we define a tracked user: Agents represent users or actuation devices. Here we define a tracked user:
\begin{lstlisting}[language=json, numbers=none, caption={Agent Definition.}] \begin{lstlisting}[language=json, numbers=none, caption={Agent Definition.}]
"agents": { "agents": [{
"type": "User", "type": "User",
"id": "user_{}", "id": "user_{}",
"role": "interactor", "instances": "+",
"allowedInstances": "+",
"services": [ "services": [
{"service_type": "hand_tracking", {"service_type": "hand_tracking",
"call_type": "pooling"}, "call_type": "pooling", "required": true},
{"service_type": "position_tracking", {"service_type": "position_tracking",
"call_type": "trigger_feed"}, "call_type": "trigger_feed", "required": true},
{"service_type": "hand_visual_output"}] {"service_type": "hand_visual_output", "required": false}]
} }]
\end{lstlisting} \end{lstlisting}
The application defines that it requires at least one agent (+) in order to be executed, the system can halt the application if there are no agents in the ambient as it explicitly depends on this agent in order to be useful/helpful. The application defines that it requires at least one agent (\texttt{instances}) in order to be executed, the system can halt the application if there are no agents in the ambient as it explicitly depends on this agent in order to be useful/helpful.
With the \texttt{services} field, the application requires access to hand tracking on a pooling basis, agent coordinates for usage in trigger conditions, and the ability of showing visual output in the agent's hand. Therefore, the application may use these resources directly (system calls) or indirectly (system watchers that require this data). With the \texttt{services} field, the application requires access to hand tracking on a pooling basis, agent coordinates for usage in trigger conditions, and the ability of showing visual output in the agent's hand. Therefore, the application may use these resources directly (system calls) or indirectly (system watchers that require this data).
\paragraph{Components} \paragraph{Components}
Components specify required physical characteristics and access modes. Both entities will use a flat surface that provides video feed and with visual output capabilities: Components specify required physical characteristics and Input/Output capabilities. Both entities will use a flat surface that provides video feed and visual output capabilities:
\begin{lstlisting}[language=json, numbers=none, caption={Abstract Component for Flat Surface.}] \begin{lstlisting}[language=json, numbers=none, caption={Application Manifest's Component for Flat Surface.}]
"components": [{ "components": [{
"id": "flat_surface", "id": "flat_surface",
"type": "static_surface", "type": "static_surface",
@@ -389,65 +568,60 @@ Components specify required physical characteristics and access modes. Both enti
"minimum_width": 0.3, "minimum_width": 0.3,
"minimum_height": 0.3 "minimum_height": 0.3
}, },
"requirements": { "input": [{
"input": [{ "type": "bw_video_feed",
"type": "bw_video_feed", "minimum_width": 640,
"minimum_width": 640, "minimum_height": 480
"minimum_height": 480 }],
}], "output": [{
"output": [{ "type": "visual_output",
"type": "visual_output", "minimum_width": 1280,
"minimum_width": 1280, "minimum_height": 720
"minimum_height": 720 }]
}]
}
}] }]
\end{lstlisting} \end{lstlisting}
\textbf{Note:} AURA allows to not assume specific output devices like projectors or HMDs. Instead, it abstracts output capabilities via \texttt{visual\_output}, which could map to projection, screen display, or AR headset rendering. Similarly, input requirements such as \texttt{bw\_video\_feed} (black and white video feed) can be provided by RGB cameras, depth sensors, or other modalities. \textbf{Note:} AURA allows to not assume specific output devices like projectors or HMDs. Instead, it abstracts output capabilities via \texttt{visual\_output}, which could map to projection, screen display, or AR headset rendering. Similarly, input requirements such as \texttt{bw\_video\_feed} (black and white video feed) can be provided by RGB cameras, depth sensors, or other modalities.
\paragraph{Entities} \paragraph{Entities}
The application defines two entities with the same single component. The application defines two entities, both referring to the same application manifest component \texttt{flat\_surface}. This does not imply that both entities will have the exact same system-provided component. Application Manifest components are abstract definitions of what is required, but they only assume form inside an entity, as it is based in an entity's \texttt{instances} that the system learns how many components with certain characteristics it has to provide the application with.
The entity ``photo\_gallery'' consists on a single interactive visualiser The entity \texttt{photo\_gallery} consists of a single interactive visualiser for browsing photos. If it was defined as "1", then if the component that represents this entity was moved off of the ambient's physical space, the application could be halted by the system, as one instance of this entity would be required for it to run.
for browsing photos.
\begin{lstlisting}[language=json, numbers=none, caption={Photo Gallery Entity Definition.}] \begin{lstlisting}[language=json, numbers=none, caption={Photo Gallery Entity Definition.}]
"entities": [{ "entities": [{
"id": "photo_gallery", "id": "photo_gallery",
"components": ["flat_surface"], "components": ["flat_surface"],
"instancesAllowed": 1, "instances": "[0-1]",
"discreteVariables": [ "discrete_variables": [
"active": "distance(agent, flat_surface) < 0.3" "active": "distance(agent, flat_surface) < 0.3"
] ] },
},
\end{lstlisting} \end{lstlisting}
The entity "photo\_viewer" can have multiple instances and consists on a The entity \texttt{photo\_viewer} can have zero or more instances and consists of a photo displayer.
photo displayer.
\begin{lstlisting}[language=json, numbers=none, caption={Photo Viewer Entity Definition.}] \begin{lstlisting}[language=json, numbers=none, caption={Photo Viewer Entity Definition.}]
{ {
"id": "photo_viewer", "id": "photo_viewer",
"components": ["flat_surface"], "components": ["flat_surface"],
"instancesAllowed": "*", "instances": "*",
"discreteVariables": [ "discrete_variables": [
"active": "distance(agent, flat_surface) < 0.3" "active": "distance(agent, flat_surface) < 0.3"
] ]
}] }]
\end{lstlisting} \end{lstlisting}
When a user approaches within 0.3m of a gallery surface, the system emits an event. The application reacts accordingly by requesting access to its declared video feed or visual output. In both entities, we request the system to notify of valuation changes of the discrete variable ``active''. When a user approaches within 0.3m of a gallery or photo viewer surface, the system emits an event. This allows the application to react accordingly by requesting access to the associated video feed and/or visual output.
\subsection{System: Allocation and Coordination} \subsection{System: Allocation and Coordination}
A \textbf{system manifest} is generated at setup time or by a system administrator. It defines the physical layout, available components, agents, ambients, and their grouping into worlds. It ensures applications are isolated unless explicitly allowed to share. A \textbf{system manifest} is generated at setup time or by a system administrator. It defines the physical layout, available components, agents, ambients, and their grouping into worlds. It ensures applications are isolated unless explicitly allowed to share.
\paragraph{Physical Components} \paragraph{Components}
Components define tracked surfaces: Components in the system manifest represent real tracked structures or devices.
\begin{lstlisting}[language=json, numbers=none, caption={Component Definition.}] \begin{lstlisting}[language=json, numbers=none, caption={Component Definition.}]
"id": "table_surface", "id": "table_surface",
"name": "Office"s table-top", "name": "Office's table top",
"type": "static_surface", "type": "static_surface",
"spatialAttributes": { "spatial_attributes": {
"x": 0, "y": 0, "z": 0.75, "x": 0, "y": 0, "z": 0.75,
"width": 1.5, "height": 0.75 "width": 1.5, "height": 0.75
}, },
@@ -455,19 +629,20 @@ Components define tracked surfaces:
\end{lstlisting} \end{lstlisting}
\paragraph{Ambients and Worlds} \paragraph{Ambients and Worlds}
Each application is assigned to an ambient: Each application is assigned to an ambient, which acts as its exclusive spatial and resource scope. Here the ambient makes a (concrete/system) component available for the application assigned. It could also suggest that such component was associated to a certain application entity (usually that would happen with user guidance, however the actual attribution can only be decided by the application at runtime and can be updated at any time).
\begin{lstlisting}[language=json, numbers=none, caption={Ambient and World Declaration.}] \begin{lstlisting}[language=json, numbers=none, caption={Ambient and World Declaration.}]
"ambients": [{ "ambients": [{
"id": "ambient_gallery", "id": "ambient_gallery",
"components": ["table_surface"], "components": ["table_surface"],
"dimensions": {
"width": 2, "height": 1.5
},
"coordinate_system": ["type": "left-handed", origin: "bottom-left"],
"application": "com.devX.photo_gallery_ar_app" "application": "com.devX.photo_gallery_ar_app"
}] }]
\end{lstlisting} \end{lstlisting}
The application is responsible for selecting from the available components Ambients can be grouped into worlds for shared observation and data exchange:
which to use in each entity and then communicate back to the system.
Ambients can be grouped into worlds for coordinated observation and data exchange:
\begin{lstlisting}[language=json, numbers=none, caption={World Declaration.}] \begin{lstlisting}[language=json, numbers=none, caption={World Declaration.}]
"worlds": [{ "worlds": [{
"id": "room1", "id": "room1",
@@ -475,106 +650,23 @@ Ambients can be grouped into worlds for coordinated observation and data exchang
}] }]
\end{lstlisting} \end{lstlisting}
\subsection{Runtime Coordination and Safety} After deployment, the system proposes candidate components matching the application's requirements, which the application may confirm or remap as part of the bootstrap procedure (see \cref{sec:aura-bootstrap}).
At runtime, the system: \section{Conclusion and Future Work}
\begin{enumerate}
\item Parses application manifests and validates spatial constraints;
\item Validates that all non-disjoint ambient areas don't have common components;
\item Resolves component mappings and injects coordinates into the application's declared referential;
\item Routes sensor and actuator access through system-controlled proxies, enforcing access limitations;
\item Emits events for observable triggers, allowing the application to respond;
\item Mediates access to component data and sensors.
\end{enumerate}
Components may be shared between ambients as long as they are never simultaneously assigned --- disjoint regions. Applications may observe changes to a shared component's storage (within the same world) but cannot modify or output to it if it is not explicitly assigned within their ambient --- present in ambient's region. This paper introduced AURA, a declarative specification and runtime model for spatially structured, multi-application AR systems. By separating application logic from physical resource allocation and introducing structured data sharing, heuristic-based state modelling, and ambient scoping, AURA enables modular development, scalable coordination, and conflict-free coexistence across applications.
\paragraph{Conclusion} Currently, AURA assumes a centralized runtime and lacks global synchronization guarantees, which may lead to diverging histories when applications observe shared state independently. Heuristics are application-defined and deterministic, and semantic arbitration is not yet formalized.
Together, the application and system manifests form the core of AURA's architecture. Applications remain modular and declarative, while the system ensures spatial safety, manages interactions, and enables event-based coordination across agents and components. Future work includes implementing a reference runtime with arbitration and event routing, formal validation of manifests and ambient compatibility constraints, and distributed orchestration across heterogeneous AR platforms. We are particularly interested in probabilistic extensions to heuristic evaluation for improving tracking and rendering on moving objects, as well as developing an ambient calculus for structured data exchange between components.
\section{Data Sharing and Memory Exchange in AURA}\label{sec:ambient-calculus}
Ensuring efficient communication and state synchronization across multiple AR applications is necessary for seamless interoperability. AURA introduces a structured data-sharing model that enables applications to exchange relevant information in real time without interfering with each other's execution logic.
\subsection{Shared Data Models}
AURA defines shared data objects as part of the system manifest, ensuring that applications operating in the same environment can read or modify specific attributes as needed. These shared objects include:
\begin{itemize}
\item \textbf{Spatially Tracked Objects:} Components whose positions, orientations, or statuses are shared across applications (e.g., physical surfaces, tracked tools).
\item \textbf{Component-based Data Storage Snapshot:} A log of recent modifications to maintain continuity when users switch between applications.
\item \textbf{Environmental Metadata:} System-wide conditions such as lighting, ambient constraints, and real-world occlusions.
\end{itemize}
\subsection{Memory Exchange and Performance Considerations}
To optimize data exchange, AURA supports both \textbf{event-driven} and \textbf{request-based} memory sharing mechanisms. Event-driven updates occur when a tracked state changes (e.g., an object is picked up or moved), while request-based exchange allows applications to query system-level states when necessary, reducing computational overhead.
\section{Semantic Interoperability and Ontology-Driven Reasoning}
\subsection{Semantic Extensions}
The AURA vocabulary is designed with extensibility in mind, leveraging JSON-LD for semantic richness. Developers can extend the vocabulary to include domain-specific attributes and concepts, ensuring compatibility with emerging AR technologies and applications.
\textbf{Example Extensions:}
\begin{itemize}
\item Adding attributes for IoT integration (e.g., sensor data, network connectivity).
\item Defining new interaction types for domain-specific use cases, such as medical or industrial applications.
\item Including metadata for accessibility features, such as haptic feedback or audio descriptions.
\end{itemize}
\section{Limitations and Future Work}
AURA bridges the gap between static specification and dynamic interaction, enabling intuitive and immersive AR experiences. By dynamically inferring interaction probabilities, AURA enhances the responsiveness and adaptability of AR systems, paving the way for more sophisticated augmented environments.
Future work includes implementing a prototype system and conducting user studies to validate the hypotheses.
\paragraph{Extending State Semantics}
AURA supports simple state transitions like \texttt{idle} to \texttt{active}, but may also express more advanced heuristics. For example, a juggling ball could be represented by a state machine with \texttt{idle}, \texttt{ascending}, and \texttt{descending} states, with transitions defined by object velocity and trajectory:
\begin{lstlisting}[language=json, numbers=none, caption={Heuristic-Driven State Model.}]
"continuous_variables": ["surface.velocity"],
"discrete_variables": {
"T": "room.temperature > 30",
"H": "room.humidity > 10"
},
"heuristics": {
"flat_surface": {
"states": {
"up": {
"invariant": "Velocity = z > 0",
"common_trajectory": ""
},
"down": {
"invariant": "Velocity = z < 0",
"common_trajectory": ""
},
"idle": {
"invariant": "Velocity = z = 0",
"common_trajectory": ""
},
"miss": {
"invariant": "Velocity = unknown"
}
},
"transitions": {
"idle": "up",
"up": "idle",
"idle": "down"
}
}
}
\end{lstlisting}
These states may help the system optimize tracking or projection. While the application still defines the state model, the system observes and manages transitions.
\section{Conclusion}
AURA provides a unified, platform-independent specification for defining and managing AR applications, ensuring consistent interaction modelling, multi-application interoperability, and real-time responsiveness. By introducing structured manifests, AURA abstracts application logic from system execution, allowing applications to seamlessly integrate within shared spatial environments.
Through formalized state modelling, heuristic-based transitions, and a structured data-sharing model, AURA enhances AR system robustness while facilitating collaborative and adaptive experiences. Future research will focus on implementing a prototype system and conducting empirical evaluations to measure the impact of AURA on real-world AR applications.
%\bibliographystyle{abbrv}
\bibliographystyle{abbrv-doi}
%\bibliographystyle{abbrv-doi-narrow}
%\bibliographystyle{abbrv-doi-hyperref}
%\bibliographystyle{abbrv-doi-hyperref-narrow}
%%
%% The next two lines define the bibliography style to be used, and
%% the bibliography file.
\bibliographystyle{ACM-Reference-Format}
\bibliography{biblio} \bibliography{biblio}
\end{document} \end{document}
\endinput
%%
%% End of file `sample-sigconf-authordraft.tex'.

BIN
references/van2010survey.pdf
View File

Binary file not shown.

BIN
references/vitzthum2006modelling.pdf
View File

Binary file not shown.

989
vgtc.cls
View File

@@ -1,989 +0,0 @@
% `vgtc' LaTeX class.
% THIS FILE MAY NOT BE MODIFIED WITHOUT THE EXPRESS APPROVAL
% OF THE VGTC PUBLICATIONS CHAIR (submissions@vgtc.org).
%
% Changelog:
% - modifications by Matthew Brehmer on 2024/02/12
% - ACM CCS keywords replaced with index terms, so as to be consistent with full papers
% - added cleveref package and instructions for use, rather than using autoref (mirrorring full paper template)
% - added Supplemental Materials and Figure Credits sections at the end.
% - added supplemental materials instructions and goals, an example project
% on OSF.
% - added figure credits for CypressView.
% - replaced paper count figure with newly-made ones.
% - changed cross references to point to the top of the target float, rather than the caption.
% - added blue hyperlink coloring, now that electronic has long been the default.
% - removed sample.pdf & sample.eps.
% - removed Google Scholar fields from template.bib.
% - modifications by Cagatay Turkay and Soumya Dutta on 2019/09/11
% - modified the preprint article style to contain the IEEE copyright notices to produce IEEE compliant OA preprints.
% - included two different statements for journal and conference papers
% - added a new command \ieeedoi for authors to set IEEE generated DOIs on their preprints
% - added comments on the template.tex for preprint guidance
% - modifications by Tobias Isenberg on 2017/07/05
% - updated the instructions for author footer in template.tex for the journal template
% - modifications by Tobias Isenberg on 2017/06/14
% - improved handling of marginpars for conference style, added examples for both styles
% - modifications by Tobias Isenberg on 2017/06/13
% - updated link to ACM CCS in conference template tex
% - transitioned to the updated 2012 system to be used with \CCScatTwelve (1998 still possible)
% - updated CCS examples in conference template tex
% - added statement in journal template tex to leave the copyright block untouched
% - updated the DOI links in the bst files to use shorter https version
% - modifications by Filip Sadlo/Tobias Isenberg on 2017/03/16
% - revived latex mode (as opposed to pdflatex) by disabling \let\ifpdf\relax
% - note that packages that define \ifpdf (and thus lead to already defined
% \ifpdf) are obsolete and should be changed to use ifpdf package instead
% - added a comment to the actual tex template for those with compilation errors
% - modifications by Tobias Isenberg on 2016/07/19
% - fixed a bug in the hyperref data (missing comma, thanks to Christian
% Tominski)
% - adjusted behavior for when \vgtccategory{} is not set in review mode (print
% out "n/a")
% - added switch to print out paper type in review mode if desired in review
% mode, does not print anything if not used
% - added teaser width computation, limited the entire teaser to the width of
% the abstract
% - fixes to the bibTeX templates for how addresses in proceedings are used,
% now similar to inproceeding
% - fixes to the bibTeX templates for dois with more than one dash in them
% - fixes to the bibTeX templates: dois are now linked with https if only the
% pure doi was given
% - fixed caption behavior for tables due to caption expected above the table
% - modifications by Filip Sadlo on 2016/03/16
% - replaced \pdfoutput mechanism by \ifpdf because \pdfoutput was
% always detecting pdf output mode on current texlive installations
% - The modification follows the current version of egpubl.cls
% - modifications by Tobias Isenberg on 2016/03/24
% - improved marginpar
% - modifications by Tobias Isenberg on 2015/03/24
% - better compilation for pdfLaTeX
% - electronic option is now mandatory
% - hyperref settings redone, information automatically used for pdf information
% - microtype
% - some suggestions for style use
% - alternative bst files with DOI printing and hyperlinking
% - modifications by Meghan Haley on 2011/03/10
% - manuscript received dates changed for 2011 journal style
% - modifications by Steven Bergner on 2009/03/28
% - revived teaser feature
% - added captionmargin to align teaser caption with abstract width
% - modifications by Meghan Haley on 2006/07/20
% - manuscript received changed to 31 March for journal style
% - modifications by Steven Bergner on 2006/06/28
% - made review and preprint work for journal style
% - leveraged \firstsection{..} title above double column text
% - included diamond line (currently by loading .eps file)
% - adjusted headlines and footer (special on first page, with copyrighttext)
% - modifications by Steven Bergner on 2006/05/21
% - included 'electronic' option using method from egpubl.cls (c)by D.Fellner
% - included double column (full width) abstract/keywords/index terms,
% which can be toggled by (ex/in)clusion of 'journal' document option
% note: abstract is now a command not an environment, see template.tex
% - copyrightspace enabled by default with opt. \nocopyrightspace switch
% - 'CR categories' now called 'Index Terms'
% - adjusted {sub|subsub|}section headline spacing
% - adjusted to vgtc naming (from tcvg or acm)
% - modification of the acmsiggraph.cls class
% - modifications on 2004/04/06 by Torsten Moeller
% * many modifications to conform to VGTC standard
% - new heading style
% - new caption style
% - new reference style
% - copyrightspace reduced to 0.5in
% - borrows *heavily* from Daniel Kartch's 'siggraph' class.
% - also uses pieces of 'apalike.sty' and 'authordate1-4.cls'
% - version 0.1 2001/06/01 Stephen Spencer (spencer@acm.org)
% - version 0.2 2001/10/15 Stephen Spencer
% - the "\onlineid" variable works with the "review" mode, placing a
% banner across the top of each page "Online Submission ID 'onlineid'
% - version 0.3 2002/01/11 Stephen Spencer
% - disabled the cover page option.
% - version 0.4 2002/01/23 Stephen Spencer
% - based on suggestions from James O'Brien, the following changes:
% - correction if '\ifcamera' and '\ifcameraelse' commands
% - page numbering in both review and preprint modes
% have been made.
% ------------ identification --------------
\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{vgtc}[2006/05/21 IEEE VGTC]
% ------------ initial code --------------
\newif\ifvgtc@camera
\newif\ifvgtc@preprint
\newif\ifvgtc@review
\newif\ifvgtc@doublespaced
\newif\ifvgtc@wide \vgtc@widefalse
\newif\ifhavecopyrightspace \havecopyrightspacetrue
\newif\ifvgtcjournal \vgtcjournalfalse
\newif\iftvcgsize \tvcgsizefalse
\newcommand{\vgtc@columnmode}{}
\newcommand{\vgtc@pointsize}{}
\RequirePackage{ifpdf}%
%% These few lines make a distinction between latex and pdflatex calls and they
%% bring in essential packages for graphics and font handling.
\ifpdf% % if we use pdflatex
\pdfoutput=1\relax % create PDFs from pdfLaTeX
\pdfcompresslevel=9 % PDF Compression
\pdfoptionpdfminorversion=7 % create PDF 1.7
\ExecuteOptions{pdftex}
\RequirePackage{graphicx} % allow us to embed graphics files
\DeclareGraphicsExtensions{.pdf,.png,.jpg,.jpeg} % for pdflatex we expect .pdf, .png, or .jpg files
\else% % else we use pure latex
\ExecuteOptions{dvips}
\RequirePackage{graphicx} % allow us to embed graphics files
\DeclareGraphicsExtensions{.eps} % for pure latex we expect eps files
\fi%
% ------------ declaration of options --------------
% 'cameraready' option.
\DeclareOption{cameraready}{%
\vgtc@cameratrue%
\vgtc@preprintfalse%
\vgtc@reviewfalse%
\renewcommand{\vgtc@columnmode}{twocolumn}%
\vgtc@doublespacedfalse%
\renewcommand{\vgtc@pointsize}{9pt}}
% 'review' option.
\DeclareOption{review}{%
\vgtc@camerafalse%
\vgtc@preprintfalse%
\vgtc@reviewtrue%
\renewcommand{\vgtc@columnmode}{twocolumn}%
\vgtc@doublespacedfalse%
\renewcommand{\vgtc@pointsize}{9pt}
\havecopyrightspacefalse}
% 'widereview' option.
\DeclareOption{widereview}{%
\vgtc@camerafalse%
\vgtc@preprintfalse%
\vgtc@reviewtrue%
\renewcommand{\vgtc@columnmode}{onecolumn}%
\vgtc@widetrue%
\vgtc@doublespacedtrue%
\renewcommand{\vgtc@pointsize}{12pt}}
% 'preprint' option.
\DeclareOption{preprint}{%
\vgtc@camerafalse%
\vgtc@preprinttrue%
\vgtc@reviewfalse%
\renewcommand{\vgtc@columnmode}{twocolumn}%
\vgtc@doublespacedfalse%
\renewcommand{\vgtc@pointsize}{9pt}}
\DeclareOption{tvcgpapersize}
{\setlength\paperheight {10.75in}%
\setlength\paperwidth {7.875in}
\tvcgsizetrue
}
% 'journal' option
\DeclareOption{journal}{%
\vgtcjournaltrue %
\@twosidetrue \@mparswitchtrue %
%\ExecuteOptions{tvcgpapersize}
}
%%% the following code has partly been adapted from egpubl.cls
%\newif\ifpdf % determine if we are running PDFLaTeX or not
%\ifx\pdfoutput\undefined \pdffalse % we are not running PDFLaTeX
%\else
% %\pdfoutput=1 % we are running PDFLaTeX
% \pdftrue
%\fi
\newcommand{\vgtcinsertpkg}{}
\DeclareOption{electronic}{%
\renewcommand{\vgtcinsertpkg}{%
\RequirePackage[pagebackref,bookmarks]{hyperref}
\RequirePackage[all]{hypcap}% makes hyperlinks go to top of floats rather than the caption
\RequirePackage[svgnames]{xcolor}
\hypersetup{
pdfpagemode=UseNone,
pdftitle={\@title},
pdfauthor={\@author},
pdfsubject={VGTC Conference Paper},
pdfkeywords={\vgtc@keywords},
pageanchor=true,
plainpages=false, % for problems with page referencing
hypertexnames=false, % for handling subfigures correctly
bookmarksnumbered=false,% include the section numbers in the list
bookmarksopen=true, % In the list, display highest level only
bookmarksopenlevel=3, % display three levels of bookmarks
pdfpagemode=UseNone, % show just the page
pdfstartview=Fit, % defail page view is the whole page at once
pdfborder={0 0 0}, % we don't want those silly boxes for links
breaklinks=true, % allow breaking links
colorlinks=true, % color all links blue
linkcolor=NavyBlue,
urlcolor=NavyBlue,
citecolor=NavyBlue,
anchorcolor=black, % changing this colors te teaser caption using dvips
nesting=true,
linktocpage,
pdfdisplaydoctitle}
\ifpdf% % if we use pdflatex
\else% % else we use pure latex
\renewcommand{\pdfbookmark}[3][]{}
\fi
%% it is recommended to use ``\cref{sec:bla}`` instead of ``Sec.~\ref{sec:bla}''
%% the following lines load cleveref for consistent, style-dependent cross-references
%% then customize how sections and tables are referenced. Note that both ``\crefname``
%% AND ``\Crefname`` must be specified for each, otherwise cleveref uses whatever is
%% given for both cases.
\RequirePackage[nameinlink,capitalise]{cleveref}
\crefname{table}{Tab.}{Tabs.}
\Crefname{table}{Table}{Tables}
\crefname{section}{Sec.}{Secs.}
\Crefname{section}{Section}{Sections}
}
}
%% end of code adapted from egpubl.cls
% Assume, for the moment, that we're preparing a 'cameraready' version.
\ExecuteOptions{electronic,cameraready}
%\AtBeginDocument{\vgtcinsertpkg}
% Here's a warning command for use just below.
\newcommand{\vgtc@optwarning}[1]{%
\ifvgtc@camera
\ClassWarningNoLine{vgtc}%
{#1 option used in camera-ready mode.\MessageBreak
This violates submission specifications}
\fi
}
% The 'onecolumn' option doesn't work in 'cameraready' mode.
\DeclareOption{onecolumn}{%
\vgtc@optwarning{onecolumn}
\renewcommand{\vgtc@columnmode}{onecolumn}}
% The 'twocolumn' option works in 'cameraready' mode.
\DeclareOption{twocolumn}{%
\renewcommand{\vgtc@columnmode}{twocolumn}}
% Only the '9pt' size works in 'cameraready' mode.
\DeclareOption{9pt}{%
\renewcommand{\vgtc@pointsize}{9pt}}
\DeclareOption{10pt}{%
\vgtc@optwarning{10pt}
\renewcommand{\vgtc@pointsize}{10pt}}
\DeclareOption{11pt}{%
\vgtc@optwarning{11pt}
\renewcommand{\vgtc@pointsize}{11pt}}
\DeclareOption{12pt}{%
\vgtc@optwarning{12pt}
\renewcommand{\vgtc@pointsize}{12pt}}
% The 'singlespace' option works in 'cameraready' mode.
\DeclareOption{singlespace}{%
\vgtc@doublespacedfalse}
% The 'doublespace' option does not work in 'cameraready' mode.
\DeclareOption{doublespace}{%
\vgtc@optwarning{doublespace}
\vgtc@doublespacedtrue}
% No 'titlepage' option in 'cameraready' mode.
\DeclareOption{titlepage}{%
\OptionNotUsed%
\ClassWarningNoLine{vgtc}{titlepage option not allowed}}
% No 'landscape' mode in 'cameraready' mode, either.
\DeclareOption{landscape}{%
\OptionNotUsed%
\ClassWarningNoLine{vgtc}{landscape option not allowed}}
% Pass everything else to the 'article' class, upon which this is based.
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}
\ProcessOptions
\PassOptionsToClass{\vgtc@columnmode}{article}
\ifvgtcjournal
\PassOptionsToClass{twoside}{article}
\fi
\ifdim\vgtc@pointsize>9pt
\PassOptionsToClass{\vgtc@pointsize}{article}
\fi
% ------------ package loading --------------
\LoadClass{article}
% ------------ main code --------------
\newcommand{\vgtc@onlineid}{}
\newcommand{\onlineid}[1]{\renewcommand{\vgtc@onlineid}{#1}}
%\newcommand{\vgtc@preprinttext}{To appear in IEEE Transactions on Visualization and Computer Graphics}
%\newcommand{\preprinttext}[1]{\renewcommand{\vgtc@preprinttext}{#1}}
\newcommand{\vgtc@DOI}{xx.xxxx/TVCG.201x.xxxxxxx/}
\newcommand{\vgtc@preprinttext}{\parbox{0.9\textwidth}{$\copyright$ \the\year~IEEE. This is the author's version of the article that has been published in the proceedings of IEEE Visualization conference. The final version of this record is available at: \href{https://doi.org/\vgtc@DOI}{\color{blue}\vgtc@DOI}}}
\newcommand{\preprinttext}[1]{\renewcommand{\vgtc@preprinttext}{#1}}
\newcommand{\ieeedoi}[1]{\renewcommand{\vgtc@DOI}{#1}}
\newcommand{\vgtc@reviewtext}{Online Submission ID: \vgtc@onlineid}
\newcommand{\reviewtext}[1]{\renewcommand{\vgtc@reviewtext}{#1}}
\newcommand{\shortauthortitletext}{}
\newcommand{\shortauthortitle}[1]{\renewcommand{\shortauthortitletext}{#1}}
%\newcommand{\journalidtxt}{IEEE TRANSACTIONS ON VISUALIZATION AND
%COMPUTER GRAPHICS, VOL. 12, NO. 5, SEPTEMBER/OCTOBER 2006}
%\newcommand{\journalid}[1]{\renewcommand{\journalidtxt}{#1}}
%%Comment from here
\newcommand{\manuscriptnotetxt}{
Manuscript received xx xxx. 201x; accepted xx xxx. 201x. Date of Publication xx xxx. 201x; date of current version xx xxx. 201x. For information on obtaining reprints of this article, please send e-mail to: reprints@ieee.org. Digital Object Identifier: xx.xxxx/TVCG.201x.xxxxxxx
}
%% to here to not use the blank
%% NOTE FOR BLANK SPACING
%% uncomment from here
%\newcommand{\manuscriptnotetxt}{\vspace{.25in}}
%% to here
\newcommand{\manuscriptnote}[1]{\renewcommand{\manuscriptnotetxt}{#1}}
\newcommand{\copyrighttext}{}
%%\newcommand{\copyrighttext}{1077-2626/12/\$31.00 \copyright 2014 IEEE%
%%\hskip0.5in Published by the IEEE Computer Society}
\newcommand{\authorfootertext}{}
\newcommand{\authorfooter}[1]{\renewcommand{\authorfootertext}{{\em#1}}}
\newcommand{\firstsectiontxt}{}
\newcommand{\firstsection}[1]{\renewcommand{\firstsectiontxt}{#1}}
\newcommand{\acknowledgments}[1]{%
\ifvgtc@review\else%
\section*{Acknowledgments}
#1
\fi}
\newcommand{\ifcamera}[1]{\ifvgtc@camera #1 \fi}
\newcommand{\ifreview}[1]{\ifvgtc@review #1 \fi}
\newcommand{\ifcameraelse}[2]{\ifvgtc@camera #1 \else #2 \fi}
\newcommand{\ifreviewelse}[2]{\ifvgtc@review #1 \else #2 \fi}
\ifvgtcjournal
\renewcommand{\figurename}{Fig.}
\setlength{\textheight}{9.625in}
\setlength{\topmargin}{-0.625in}
\setlength{\headheight}{0.0625in}
\setlength{\headsep}{0.250in}
\setlength{\footskip}{0.25in}
\flushbottom
\setlength{\textwidth}{7.125in}
\setlength{\columnsep}{0.17in}
\newlength{\captionmargin}
\setlength{\captionmargin}{0in}
\iftvcgsize
\setlength\paperheight {10.75in}
\setlength\paperwidth {7.875in}
\setlength{\evensidemargin}{-0.6875in} %1in-0.3125
\setlength{\oddsidemargin}{-.58in} %1in-0.4375
\else %else assume letter
\setlength\paperheight {11in}
\setlength\paperwidth {8.5in}
\setlength{\evensidemargin}{-0.375in} %1-(0.3125+0.3125)
\setlength{\oddsidemargin}{-.25in} %1-(0.4375+0.3125)
\fi
\else
% conference template margins
\setlength{\textheight}{9.25in}
\setlength{\topmargin}{-0.700in}
\setlength{\headheight}{0.2in}
\setlength{\headsep}{0.250in}
\setlength{\footskip}{0.5in}
\flushbottom
\setlength{\textwidth}{7in}
\setlength{\oddsidemargin}{-0.25in}
\setlength{\evensidemargin}{-0.25in}
\setlength{\columnsep}{2pc}
%%\setlength{\parindent}{1em}
\newlength{\captionmargin}
\setlength{\captionmargin}{0in}
\fi
% adjust marginpars so that they can be used for comments during editing
\ifvgtcjournal % for journal style
\addtolength{\marginparwidth}{-1.5mm} % fix margin
\else % conference style
\addtolength{\marginparwidth}{16mm}
\fi
\addtolength{\marginparsep}{-2mm} % fix margin
\renewcommand{\ps@plain}%
{%
\renewcommand{\@oddhead}{}%
\renewcommand{\@oddfoot}{}%
\ifvgtc@preprint%
\renewcommand{\@oddhead}{\hfil\textit{\vgtc@preprinttext}\hfil}%
\renewcommand{\@oddfoot}{\hfil\textrm{\thepage}\hfil}%
\fi%
\ifvgtc@review%
\renewcommand{\@oddhead}{\hfil\textit{\large\vgtc@reviewtext}\hfil}%
\renewcommand{\@oddfoot}{\hfil\textrm{\thepage}\hfil}%
\fi%
\ifvgtcjournal%
\ifvgtc@review\else\ifvgtc@preprint\else%
% \renewcommand{\@evenhead}{\hfil\sffamily\small\MakeUppercase{\journalidtxt}}%
% \renewcommand{\@oddhead}{\sffamily\small\MakeUppercase{\shortauthortitletext}\hfil}%
\renewcommand{\@oddfoot}{}% no page number
\renewcommand{\@evenfoot}{\@oddfoot}%
\fi\fi%
\else%
\renewcommand{\@evenhead}{\@oddhead}%
\renewcommand{\@evenfoot}{\@oddfoot}%
\fi%
}
% will be used on the first page
\renewcommand{\ps@empty}%
{%
\renewcommand{\@oddhead}{}%
\renewcommand{\@oddfoot}{}%
\ifvgtc@preprint%
\renewcommand{\@oddhead}{\hfil\textit{\large\vgtc@preprinttext}\hfil}%
\renewcommand{\@oddfoot}{\hfil\textrm{\thepage}\hfil}%
\fi%
\ifvgtc@review%
\renewcommand{\@oddhead}{\hfil\textit{\large\vgtc@reviewtext}\hfil}%
\renewcommand{\@oddfoot}{\hfil\textrm{\thepage}\hfil}%
\fi%
\ifvgtcjournal%
\ifvgtc@review\else\ifvgtc@preprint\else%
% \renewcommand{\@oddhead}{\sffamily\small\MakeUppercase{\journalidtxt}\hfil}%
\renewcommand{\@oddfoot}{\hfil{\small\sffamily\copyrighttext}\hfil}%
\fi\fi%
\fi%
\renewcommand{\@evenhead}{\@oddhead}%
\renewcommand{\@evenfoot}{\@oddfoot}%
}
% no page numbers - they are added in production
\pagestyle{plain}
\newcommand{\vgtc@setninepoint}{
\renewcommand\normalsize{%
\@setfontsize\normalsize\@ixpt\@xpt
\abovedisplayskip 9\p@ \@plus2\p@ \@minus4\p@
\abovedisplayshortskip \z@ \@plus3\p@
\belowdisplayshortskip 6\p@ \@plus3\p@ \@minus3\p@
\belowdisplayskip \abovedisplayskip
\let\@listi\@listI}
\renewcommand\small{%
\@setfontsize\small\@viipt\@ixpt
\abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@
\abovedisplayshortskip \z@ \@plus2\p@
\belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@
\def\@listi{\leftmargin\leftmargini
\topsep 4\p@ \@plus2\p@ \@minus2\p@
\parsep 2\p@ \@plus\p@ \@minus\p@
\itemsep \parsep}%
\belowdisplayskip \abovedisplayskip}
\renewcommand\footnotesize{%
\@setfontsize\footnotesize\@viiipt{9.5}%
\abovedisplayskip 6\p@ \@plus2\p@ \@minus4\p@
\abovedisplayshortskip \z@ \@plus\p@
\belowdisplayshortskip 3\p@ \@plus\p@ \@minus2\p@
\def\@listi{\leftmargin\leftmargini
\topsep 3\p@ \@plus\p@ \@minus\p@
\parsep 2\p@ \@plus\p@ \@minus\p@
\itemsep \parsep}%
\belowdisplayskip \abovedisplayskip}
\renewcommand\scriptsize{\@setfontsize\scriptsize\@viiipt{9.5}}
\renewcommand\tiny{\@setfontsize\tiny\@vpt\@vipt}
\renewcommand\large{\@setfontsize\large\@xpt\@xiipt}
\renewcommand\Large{\@setfontsize\Large\@xiipt{14}}
\renewcommand\LARGE{\@setfontsize\LARGE\@xivpt{18}}
\renewcommand\huge{\@setfontsize\huge\@xviipt{22}}
\renewcommand\Huge{\@setfontsize\Huge\@xxpt{25}}
\selectfont
}
\ifdim\vgtc@pointsize=9pt
\vgtc@setninepoint
\fi
\newcommand{\vgtc@sectionfont}{}
\newcommand{\sectionfont}[1]{\renewcommand{\vgtc@sectionfont}{#1}}
\renewcommand\section{\@startsection{section}{1}{\z@}%
{-2ex \@plus -1ex \@minus -.2ex}%
{0.8ex \@plus .2ex}%
{\reset@font\normalsize\sffamily\bfseries\scshape\vgtc@sectionfont}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
{-1.8ex\@plus -1ex \@minus -.2ex}%
{0.8ex \@plus .2ex}%
{\reset@font\normalsize\sffamily\bfseries\vgtc@sectionfont}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
{-1.8ex\@plus -1ex \@minus -.2ex}%
{0.8ex \@plus .2ex}%
{\reset@font\sffamily\normalsize\vgtc@sectionfont}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{1em}%
{1ex \@plus 1ex \@minus.2ex}%
{-1em}%
{\reset@font\normalsize\sffamily\vgtc@sectionfont}}
%\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
% {3.25ex \@plus1ex \@minus.2ex}%
% {-1em}%
% {\reset@font\normalsize\sffamily\bfseries\vgtc@sectionfont}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
{3.25ex \@plus1ex \@minus .2ex}%
{-1em}%
{\reset@font\normalsize\sffamily\bfseries\vgtc@sectionfont}}
\ifvgtc@wide\else
%% make captionfont 8pt
\newcommand{\captionfonts}{\scriptsize\sffamily}
\def\instring#1#2{TT\fi\begingroup
\edef\x{\endgroup\noexpand\in@{#1}{#2}}\x\ifin@}
\long\def\@makecaption#1#2{%
\if\instring{Table}{#1}\else\vskip\abovecaptionskip\fi
\leftskip = \captionmargin \rightskip = \leftskip%
\sbox\@tempboxa{\captionfonts #1\ifvgtcjournal. \else: \fi #2}%
\ifdim \wd\@tempboxa >\hsize
{\captionfonts #1\ifvgtcjournal. \else: \fi #2\par}
\else %single line caption
\global \@minipagefalse
\def\@figcaptype{figure}
\hskip0.0in%needed to make leftskip work
\hb@xt@\hsize{\ifvgtcjournal\ifx\@captype\@figcaptype\else\hfil\fi\else\hfil\fi\box\@tempboxa\hfil}%
\fi
\if\instring{Table}{#1}\vskip.5\abovecaptionskip\else\vskip\belowcaptionskip\fi}
%% fix the font size of the bibliography to 8pt
\newdimen\bibindent
\newdimen\bibspacing
\setlength\bibindent{1em}
\setlength{\bibspacing}{\z@}
\renewenvironment{thebibliography}[1]
{\section*{\refname}%
\scriptsize%
\@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}%
\list{\@biblabel{\@arabic\c@enumiv}}%
{\settowidth\labelwidth{\@biblabel{#1}}%
\leftmargin\labelwidth
\advance\leftmargin\labelsep
\itemsep\bibspacing % should this be commented out?
\parsep\bibspacing % should this be commented out?
\@openbib@code
\usecounter{enumiv}%
\let\p@enumiv\@empty
\renewcommand\theenumiv{\@arabic\c@enumiv}}%
\sloppy
\clubpenalty4000
\@clubpenalty \clubpenalty
\widowpenalty4000%
\sfcode`\.\@m}
{\def\@noitemerr
{\@latex@warning{Empty `thebibliography' environment}}%
\endlist}
\fi
\newcommand{\vgtc@empty}{}
\newcommand{\vgtc@affiliation}{}
\newcommand{\affiliation}[1]{\renewcommand{\vgtc@affiliation}{#1}}
\newcommand{\vgtc@category}{}
\newcommand{\category}[1]{\renewcommand{\vgtc@category}{#1}}
\newcommand{\vgtccategory}[1]{\category{#1}}
\vgtccategory{n/a}
\newcommand{\vgtc@papertype}{}
\newcommand{\papertype}[1]{\renewcommand{\vgtc@papertype}{#1}}
\newcommand{\vgtcpapertype}[1]{\papertype{#1}}
%\newcommand{\vgtc@format}{}
%\newcommand{\format}[1]{\renewcommand{\vgtc@format}{#1}}
%\newcommand{\vgtcformat}[1]{\format{#1}}
\newcommand{\vgtcformat}[1]
{\@latex@warning{Format specification no longer required.}}
\RequirePackage{etoolbox}
\newcommand{\vgtc@teaser}{}
\newcommand{\teaser}[1]{%
\renewcommand{\vgtc@teaser}{%
%\setlength{\captionmargin}{0.33in}% TI: no longer needed since the entire teaser is now limited to the width of the abstract
\newlength{\abstractwidth}%
\setlength{\abstractwidth}{\linewidth}%
\addtolength{\abstractwidth}{-.66in}%
\begin{minipage}{\abstractwidth}
#1%
\end{minipage}
\setlength{\captionmargin}{0in}%
}%
}
\newcommand{\vgtc@abstxt}{}
\let\origabstract\abstract
\let\endorigabstract\endabstract
\renewcommand{\abstract}[1]{\renewcommand{\vgtc@abstxt}{#1}}
\newcommand{\vgtc@keywords}{}
\newcommand{\keywords}[1]{\renewcommand{\vgtc@keywords}{#1}}
\newcommand{\vgtc@indexterms}{}
\newcommand{\CCScatlist}[1]{\renewcommand{\vgtc@indexterms}{#1}}
\newcommand{\CCScat}[4]{%
#1 [#2]%
\ifx#3\vgtc@empty \else : #3\fi%
\ifx#4\vgtc@empty \else ---#4\fi%
}
\newcommand{\CCScatTwelve}[4]{%
#1%
\ifx#2\vgtc@empty \else ---#2\fi%%
\ifx#3\vgtc@empty \else ---#3\fi%
\ifx#4\vgtc@empty \else ---#4\fi%
}
% use any of the following to adjust spaces in title block
\newlength{\titlespace}
\setlength{\titlespace}{0.25in}
\newlength{\teaserspace}
\setlength{\teaserspace}{0.0in}
\newlength{\abstxtspace}
\setlength{\abstxtspace}{0.20in}
\renewcommand{\@maketitle}{%
\ifvgtc@review
\begin{center}%
\renewcommand{\thanks}[1]{}
{\sffamily\ifvgtcjournal\huge\else\LARGE\bfseries\fi%
\vgtc@sectionfont%
\@title \par}%
\vspace{1\baselineskip}%
{Category: \vgtc@category \par}%
\ifx\vgtc@papertype\vgtc@empty \else%
{\vspace{1ex}Paper Type: \vgtc@papertype \par}%
\fi%
% \vspace{0.25\baselineskip}% % no longer needed (1996)
% {Format: \vgtc@format \par}% % no longer needed (1996)
\vspace{\titlespace}%
\ifx\vgtc@teaser\vgtc@empty \else%
\begingroup%
\def\@captype{figure}%
\vgtc@teaser%
\endgroup\par%
\vspace{\teaserspace}%
\fi%
\end{center} \par%
\else
\begin{center}%
{\sffamily\ifvgtcjournal\huge\else\LARGE\bfseries\fi%
\vgtc@sectionfont%
\@title \par}%
\ifvgtcjournal%
%\vspace{2\baselineskip}%
\vspace{14pt}%
\else%
\vspace{1\baselineskip}\fi%
\large\sffamily\vgtc@sectionfont
\begin{tabular}[t]{c}%
\@author
\end{tabular}\par%
\ifx\vgtc@affiliation\vgtc@empty \else%
\par\vspace{1\baselineskip}%
\vgtc@affiliation\par%
\fi%
\ifvgtcjournal\vspace{0.08in}\else\vspace{\titlespace}\fi%
\ifx\vgtc@teaser\vgtc@empty \else%
{
\begingroup%
\def\@captype{figure}%
\vgtc@teaser%
\endgroup\par%
}
\vspace{\teaserspace}%
\fi%
\end{center} \par%
\fi
\ifvgtcjournal%
{\scriptsize\sffamily%\renewcommand{\baselinestretch}{1.1}
\leftskip = 0.33in \rightskip = \leftskip%
\ifx\vgtc@abstxt\vgtc@empty \else%
\begingroup%
{\bfseries Abstract}---\vgtc@abstxt%
\endgroup\par%
\fi%
\ifx\vgtc@keywords\vgtc@empty \else%
\begingroup%
%{\normalsize\vgtc@absfont {\bfseries Keywords - } \vgtc@keywords}%
\vspace{0.5\baselineskip}%
\par\noindent \textbf{Index Terms}---\vgtc@keywords%
\endgroup\par%
\fi%
%% \ifx\vgtc@indexterms\vgtc@empty \else%
%% \begingroup%
%% % {\normalsize\vgtc@absfont {\bfseries Index Terms - } %
%% % \vgtc@indexterms}%
%% \vspace{0.5\baselineskip}%
%% \par\noindent \textbf{Index Terms -} \vgtc@indexterms%
%% \endgroup\par%
%% \fi%
}%
\begin{center}\includegraphics{diamondrule}\end{center}
%\vspace{\abstxtspace}%
\ifx\firstsectiontxt\vgtc@empty \else
\section{\firstsectiontxt}
\fi
\fi%
}
\let\vgtc@origmaketitle\maketitle
\let\vgtc@origand\and
\renewcommand{\maketitle}{%
\let\vgtc@title\@title%
\let\vgtc@author\@author%
\vgtc@origmaketitle%
\thispagestyle{empty}%
\ifvgtc@doublespaced%
\renewcommand{\baselinestretch}{1.66}\selectfont%
\fi%
\ifvgtcjournal% no copyrightspace for journal, but authorfooter
\ifvgtc@review\else
\renewcommand{\thefootnote}{}%
\footnotetext[0]{
\begin{flushleft}
\vskip -6pt
\begin{list}{\textbullet}{
\setlength{\partopsep}{0pt}
\setlength{\topsep}{0pt}
\setlength{\itemsep}{-2pt}
\setlength{\itemindent}{-4pt}
\setlength{\leftmargin}{12pt}}
\authorfootertext
\end{list}
\vskip 4pt
\ifvgtc@preprint\else\textit{\manuscriptnotetxt}\fi
\end{flushleft}
}%
\renewcommand{\thefootnote}{\arabic{footnote}}
\fi
\else%
\ifhavecopyrightspace\copyrightspace\fi%
\ifx\vgtc@abstxt\vgtc@empty \else%
\begingroup%
\begin{origabstract} \vgtc@abstxt \end{origabstract} %
\endgroup\par%
%\vspace{\abstxtspace}%
\fi%
\ifx\vgtc@keywords\vgtc@empty \else%
\begingroup%
\vspace{0.5\baselineskip}%
\par\noindent \textbf{Index Terms: } \vgtc@keywords%
\endgroup\par%
%\vspace{\abstxtspace}%
\fi%
\ifx\vgtc@indexterms\vgtc@empty \else%
\begingroup%
% {\normalsize\vgtc@absfont {\bfseries Index Terms - } %
% \vgtc@indexterms}%
\vspace{0.5\baselineskip}%
\par\noindent \textbf{Index Terms:} \vgtc@indexterms%
\endgroup\par%
%\vspace{\abstxtspace}%
\fi%
\fi%
\ifx\firstsectiontxt\vgtc@empty \else
\ifvgtcjournal
\section*{}
\vskip -1.5em
\else
\section{\firstsectiontxt}
\fi
\fi
}
%% \newtoks\vgtc@abs
%% \ifvgtc@review
%% \long\def\vgtc@add#1{\global\vgtc@abs\expandafter{\the\vgtc@abs#1}}
%% \long\def\vgtc@collect{%
%% \global\vgtc@abs{}%
%% \let\abstract\vgtc@@collect
%% \abstract
%% }
%% \long\def\vgtc@@collect#1\end#2{%
%% \def\@tempa{#2}%
%% \ifx\@tempa\@currenvir
%% \vgtc@add{#1}%
%% \edef\abstract{\noexpand\end{\@tempa}}%
%% \else
%% \vgtc@add{#1\end{#2}}%
%% \fi
%% \abstract
%% }
%% \newcommand{\vgtc@modify}{%
%% \let\vgtc@origabs\abstract%
%% \let\vgtc@origendabs\endabstract%
%% \renewenvironment{abstract}%
%% {\vgtc@collect}%
%% {\begingroup
%% \let\abstract\vgtc@origabs
%% \let\endabstract\vgtc@origendabs
%% \begin{abstract} \the\vgtc@abs \end{abstract}
%% \endgroup}%
%% }
%% \AtBeginDocument{\vgtc@modify}
%% \fi
\newcommand{\keywordsprefix}{%
\vspace{0.5\baselineskip}%q
\par\noindent \textbf{Index Terms - } \vgtc@keywords%
}
\newenvironment{CRcatlistprefix}{%
\vspace{0.5\baselineskip}%
\par\noindent \textbf{CR Categories: }%
}{}
% leave a 0.5 inch space at the bottom of the left column
% on the first page for the copyright block.
\newlength{\vgtc@copyrightlength}
\setlength{\vgtc@copyrightlength}{0.5in}
\newcommand{\copyrightspace}{%
\renewcommand{\thefootnote}{}%
\footnotetext[0]{\rule[\vgtc@copyrightlength]{2.71828in}{0in}}%
\renewcommand{\thefootnote}{\arabic{footnote}}
}
\newcommand{\nocopyrightspace}{\havecopyrightspacefalse}
\renewcommand{\footnoterule}{%
\kern-3pt
\leftline{\hskip1in\vbox{\hrule width 0.45\columnwidth}\hfil}
\ifvgtcjournal \else \kern 2.6pt \fi
}
\newcommand{\vgtc@contactname}{}
\newcommand{\contactname}[1]{\renewcommand{\vgtc@contactname}{#1}}
\newcommand{\vgtc@contactaddress}{}
\newcommand{\contactaddress}[1]{\renewcommand{\vgtc@contactaddress}{#1}}
\newcommand{\vgtc@contactphone}{}
\newcommand{\contactphone}[1]{\renewcommand{\vgtc@contactphone}{#1}}
\newcommand{\vgtc@contactfax}{}
\newcommand{\contactfax}[1]{\renewcommand{\vgtc@contactfax}{#1}}
\newcommand{\vgtc@contactemail}{}
\newcommand{\contactemail}[1]{\renewcommand{\vgtc@contactemail}{#1}}
\newcommand{\vgtc@estpages}{}
\newcommand{\estpages}[1]{\renewcommand{\vgtc@estpages}{#1}}
\newif\ifvgtc@cover
\vgtc@coverfalse
%\ifvgtc@review
% \vgtc@covertrue
%\else
% \vgtc@coverfalse
%\fi
\newcommand{\suppresscover}{\vgtc@coverfalse}
\newcommand{\vgtc@coverpage}{%
\begin{titlepage}%
\def\thanks##1{}
\let\and\vgtc@origand
\vgtc@setninepoint\normalsize
\renewcommand{\baselinestretch}{1}\selectfont
\begin{center}%
\vspace*{\fill}
{\LARGE\sffamily\bfseries\vgtc@sectionfont \vgtc@title \par}%
\vspace{2\baselineskip}%
{\large
\begin{tabular}[t]{c}%
\vgtc@author
\end{tabular}\par%
}%
\vspace{1\baselineskip}%
{\large \vgtc@affiliation \par}%
\addvspace{3\baselineskip}%
{Category: \vgtc@category \par}%
% \vspace{0.5\baselineskip}% % no longer needed (1996)
% {Format: \vgtc@format \par}% % no longer needed (1996)
\vspace{3\baselineskip}%
\begin{tabular}{ll}
Contact: & \vgtc@contactname \\[1\baselineskip]
& \begin{tabular}[b]{@{}l@{}}
\vgtc@contactaddress
\end{tabular} \\[1\baselineskip]
phone: & \vgtc@contactphone \\
fax: & \vgtc@contactfax \\
email: & \vgtc@contactemail
\end{tabular}\par%
\vspace*{3\baselineskip}%
{Estimated \# of pages: \vgtc@estpages \par}%
\vspace*{\baselineskip}%
{Index Terms: \vgtc@keywords \par}%
\vspace*{\fill}%
\begin{minipage}{5in}%
\the\vgtc@abs
\end{minipage}\par%
\vspace*{\fill}
\end{center}%
\end{titlepage}%
}
\AtEndDocument{\ifvgtc@cover \vgtc@coverpage \fi}
\newcommand{\vgtcopening}[1]{%
\ClassError{vgtc}{%
The vgtcopening command is no longer needed.\MessageBreak%
Switch to the maketitle command and abstract environment}{}}
\InputIfFileExists{vgtc.cfg}
{\typeout{***************************************^^J%
* Local config file vgtc.cfg used *^^J%
***************************************}}
{}
\endinput
% End of file 'vgtc.cls'.