Benutzerdefinierte Designs
Gestalten Sie den Viewer passend zu Ihrer App
Der Viewer wird mit einem neutralen, auf Bootstrap basierenden Look geliefert, der aus den eingebetteten Ressourcen (viewer.css sowie feature‑spezifischen Stylesheets wie searchBar.css und annotationBar.css) stammt. Das Theming erfolgt auf drei Ebenen – wählen Sie die flachste Ebene, die Ihr Ziel erreicht.
Ebene 1 — Konfigurieren Sie die Oberfläche
Viel „Theming“ ist eigentlich nur Konfiguration:
ViewerConfig.ShowThumbs = false— kein Miniaturbild‑Panel.ViewerConfig.FitType = "height" | "width"— wie Seiten den Viewport füllen.ViewerConfig.ShowThumbs = falsezusammen mit selektivenCssConfig/ScriptConfig‑Bündeln — behalten Sie nur die Oberfläche, die Ihr Host verwendet.
Ebene 2 — Überschreiben Sie das CSS
Viewer.ReferenceCss() erzeugt einfache <link>‑Tags; alles, was Sie nach ihnen laden, gewinnt die Kaskade. Größe und Rahmen des Viewers aus Ihrem eigenen Stylesheet festlegen:
/* Your stylesheet, loaded after ReferenceCss() */
/* The two containers you own */
#divDocViewer { width: 100%; height: calc(100vh - 48px); }
/* Widget page cards */
.docPage { max-width: none; }Die Host‑Seite steuert das äußere Layout vollständig – das Widget rendert innerhalb des von Ihnen bereitgestellten Containers #divDocViewer / #div_ctlDoc (das Standard‑Container‑Paar aus dem Quick‑Start).
Zwei praktische Regeln:
- Laden Sie Bootstrap nicht doppelt. Wenn Ihre App bereits Bootstrap mitliefert, überspringen Sie
IncludeBootstrapCss/IncludeBootstrapund lassen Sie das Widget Ihr Bootstrap erben – das allein lässt den Viewer nativ in Ihrer App aussehen. - Binden Sie nur die Bündel ein, die Sie verwenden. Jede
CssConfig/ScriptConfig‑Option ist optional; weniger Bündel, weniger Styles, mit denen Sie kämpfen müssen.
Ebene 3 — Erstellen Sie Ihre eigene Symbolleiste
Für ein vollständig gebrandetes Erlebnis steuern Sie das Widget über Ihre eigene UI – genau so baut das Referenzbeispiel seine Haupt‑Viewer‑Symbolleiste. Diese Symbolleiste besteht aus Host‑Markup plus einem app‑spezifischen Helfer; sie ist kein eingebettetes SDK‑Ribbon. Die bei der Initialisierung zurückgegebene docViewer‑Instanz ist Ihre API‑Oberfläche, zusammen mit Ihren eigenen Endpunkten:
<div id="toolbar">
<button id="btnOpen">Open</button>
<button id="btnPrev">‹</button>
<button id="btnNext">›</button>
<!-- your design system, your icons -->
</div>
<div id="divDocViewer"><div id="div_ctlDoc"></div></div>
<script>
const objViewer = $('#div_ctlDoc').docViewer({
showThumbs: true,
autoLoad: false,
BasePath: '/',
ResPath: 'doconut-res/images',
onViewerReady: () => { /* enable your buttons */ },
onError: (msg) => console.error('DocViewer:', msg)
});
document.getElementById('btnOpen').addEventListener('click', async () => {
const resp = await fetch('/api/open?fileName=Sample.pdf', { method: 'POST' });
const token = await resp.text();
objViewer.View(token);
});
</script>Suche und Annotation unterscheiden sich: ihre optionalen Ribbon‑Komponenten sind im SDK (IncludeSearchBar, IncludeAnnotationBar) eingebettet und erzeugen ihr eigenes DOM. Sie können sie zusammen mit Ihrer benutzerdefinierten Viewer‑Symbolleiste verwenden oder sie überspringen und die zugrunde liegenden Widget‑APIs selbst aufrufen. Siehe das komplette Viewer‑Paket im Quick‑Start für die vollständige Integrationsreihenfolge.
Dunkelmodus und RTL
Das Widget liefert kein dunkles Theme; ein Override auf Ebene 2, das Ihre Dark‑Mode‑Klasse (z. B. .dark #divDocViewer { … }) für Hintergründe und Rahmen anspricht, deckt die meisten Anforderungen ab, da der Seiteninhalt selbst als Bild gerendert wird. Für RTL‑Hosts funktioniert der Viewer problemlos innerhalb eines RTL‑Layouts – stellen Sie sicher, dass Ihre eigene Symbolleiste RTL‑bewusst ist.
Was Sie nicht tun sollten
Forken oder bearbeiten Sie die eingebetteten Stylesheets nicht: Sie werden im Paket mitgeliefert und bei jedem Update ersetzt. Overrides in Ihrem eigenen Stylesheet überleben Upgrades; Änderungen an viewer.css nicht.
War diese Seite hilfreich?