System Architecture for a Deep Archival Document-Reading Emulation

Full report

On this page

1. Executive Summary

Digital preservation systems frequently suffer from rapid technological obsolescence, where the software required to parse and present historical data degrades faster than the data itself. The mandate of this specification is to architect a standalone, zero-dependency, web-technologies-based desktop application utilizing strictly PHP, HTML, CSS, and vanilla JavaScript. Designed to function as an emulated historical workstation for the rigorous examination of canonical archival materials, the application fuses the meticulous hardware analogies of a microfilm reader, the stark utilitarianism of a 1990s library archive terminal (OPAC), and the rigid, pane-based layout of early electronic document readers, notably the Adobe Acrobat 3.0 and 4.0 interfaces1. At the core of this system is an unyielding philosophical mandate: the absolute ontological distinction between canonical source material and derived presentation. Canonical data—comprising raw master TIFF/JPEG images, plain text transcripts, Markdown research documents, and Encoded Archival Description (EAD) XML—remains strictly immutable on the storage medium4. The application merely acts as a deterministic state machine, casting this canonical data into a derived, interactive presentation layer within the Document Object Model (DOM). Local annotations, full-text search indexes, bookmarks, and user interface states are inherently ephemeral or stored strictly as discrete sidecar derivation files. By utilizing vanilla JavaScript for complex affine transformations, native CSS for period-accurate film grain aesthetics, and PHP for filesystem traversal and inverted-index generation, this architecture ensures an indefinite operational shelf-life. It remains entirely immune to the bit-rot and deprecation cycles associated with external libraries, SaaS viewers, document handling packages like PDF.js, and third-party content delivery networks. The finished application operates as serious, self-contained archival software installed on a recovered workstation.

2. Recommended Application Modes

To accommodate the disparate functional needs of forensic document analysis, macro-level structural review, and chronological research, the application operates through four mutually exclusive but deeply interconnected viewport modes. The state machine allows instantaneous transitions between these modes, preserving the active canonical document index and affine viewport coordinates across state changes.

2.1. The Microfilm Reader Mode

This mode mimics the continuous, physical scrubbing of analog film mechanics. The viewport is optimized for vertical, inertia-heavy scrolling where physical degradation and visual scanning take precedence over deep reading. Images are loaded sequentially in a continuous vertical column. A custom vanilla JavaScript scrubber mechanism occupies the rightmost edge of the interface, bypassing traditional scrollbars to allow the user to aggressively traverse a document timeline. The physics of this scrubber emulate the tension and release of physical film reels, enabling the researcher to scrub through decades of chronological navigation in seconds.

2.2. The Library Archive Terminal Mode

Inspired by 1990s Online Public Access Catalog (OPAC) systems and the visual characteristics of CRT phosphor displays, this mode is text-heavy and terminal-like6. It strips away the high-resolution scanned imagery entirely, redirecting rendering resources to present derived metadata, full-text search results, and raw plain-text transcripts. It operates almost exclusively via strict keyboard shortcuts, presenting data in monospaced, high-contrast layouts. This environment is specifically optimized for traversing Markdown research documents and historical journal pages where the semantic text is the primary subject of inquiry.

2.3. The Acrobat-Classic Split-Pane Mode

Drawing heavily from early PDF readers, this constitutes the primary analytical mode of the application. The interface features rigid, deeply nested gray frames and highly structured information hierarchies. A togglable sidebar, historically invoked via the F4 key or a local interface button, houses page thumbnails and match results2. The main viewport is split either horizontally or vertically: the canonical source image occupies one pane, while the derived transcript—parsed via a bespoke, zero-dependency PHP Markdown engine—occupies the other9. This split view preserves the absolute distinction between the original physical artifact and the modernized semantic interpretation.

2.4. The Contact-Sheet Mode

Operating as a macro-navigational tool, this mode utilizes CSS Grid architecture to lay out an entire document's thumbnails sequentially10. It allows researchers to visually parse physical degradation, recurring margin notes, or structural changes across hundreds of pages simultaneously. This functions as a high-level cartographic view of the archival object, providing an immediate visual taxonomy of the canonical source material.

3. Page-Navigation Model

The page-navigation architecture requires a fully decoupled relationship between the user's input, the internal state manager, and the DOM renderer. Because no external virtual-DOM libraries are permitted, the application utilizes a highly optimized vanilla JavaScript state machine to manage traversal across disparate archival formats. The application state maintains persistent trackers for the active document\_id, page\_index, zoom\_level, and rotation\_angle. The DOM is not infinitely populated with all pages of a massive historical journal; rather, a sliding window of three pages (previous, current, next) is maintained in system memory. As the user navigates, the JavaScript engine recycles the existing DOM nodes, updating the src attributes of the image elements and the innerHTML of the transcript containers. This object-pooling prevents catastrophic memory leaks during prolonged archival sessions involving gigabytes of canonical imagery. Navigation is deeply tied to historical keyboard paradigms. The keydown event listener is attached globally to the window object. To prevent modern browser interference, event.preventDefault() is systematically invoked for designated combinations12.

A fixed input field in the lower status bar accepts numerical page entry. Validating against the maximum page bounds defined in the derived metadata, the engine instantly transitions the viewport upon submission. Furthermore, this input architecture connects directly to the deep-linking logic, ensuring the URI hash always reflects the precise derived state of the active terminal session.

4. Image/Text Synchronization

A defining feature of modern forensic archival systems is the spatial synchronization between the physical scan and the digital transcript. Achieving this without relying on heavy external libraries like PDF.js requires the application to utilize the open standard hOCR format—an HTML-based optical character recognition output format that preserves bounding box geometries15. Canonical documents must be pre-processed to generate an hOCR sidecar file alongside the master image. The hOCR specification embeds spatial coordinates within the title attribute of standard HTML spans, using the rigid syntax bbox x0 y0 x1 y115. The vanilla JavaScript engine fetches this local DOM string via the native fetch() API, passing it to a DOMParser instance. The engine identifies ocr\_page, ocr\_carea, ocr\_par, ocr\_line, and ocrx\_word nodes, utilizing a regular expression pattern /bbox (\\d+) (\\d+) (\\d+) (\\d+)/ to extract the absolute integer coordinates relative to the unscaled canonical image15. Because the bounding boxes refer to the original image dimensions, the application must perfectly track the textual geography when the user interacts with the canvas. The engine calculates the relative scale factor of the current viewport ([Figure omitted from source export]). When a transcript line in the split-pane view is hovered or focused via keyboard navigation, the system maps the transcript token to the corresponding hOCR node and draws a semi-transparent highlight over the exact geometry on the scan. This synchronization must survive complex view manipulations. The application provides dedicated viewport commands: Fit Width, Fit Page, and Rotation.

• Fit Width / Fit Page: Calculating the necessary scale factor involves evaluating the ratio of the canonical image bounds against the current viewport client bounding rectangle, subsequently updating the affine matrix multiplier and resetting translation vectors.
• Rotation: Rotation operations apply a discrete orthogonal transform (90, 180, or 270 degrees) to the canvas context. This necessitates an immediate mathematical recalculation of the hOCR bounding box coordinates, applying standard 2D rotation matrices to the x0, y0, x1, y1 coordinates to ensure the transcript overlay fidelity remains perfectly aligned regardless of the orientation of the underlying scanned document page.

5. Search Architecture

Providing instantaneous full-text search (FTS) capabilities without a dedicated, running database service (e.g., Solr, Elasticsearch, or MySQL full-text indices) necessitates a bespoke, file-based inverted index generated dynamically by the PHP backend18. During the initial archival ingestion phase, or upon command execution in the recovered workstation environment, a standalone PHP script tokenizes all canonical transcripts across the entire repository. The text is normalized to lowercase, stripped of punctuation via standard regular expressions, and split by whitespace18. A predefined array of stop-words removes low-value linguistic anomalies to optimize index size. The PHP engine builds a complex multidimensional associative array mapping each discrete term to the document IDs and exact character offsets where it appears, serializing this array via json\_encode() into a static, highly compressed search\_index.json file21. When the researcher invokes Ctrl+F or clicks the dedicated search sidebar, the JavaScript engine loads this JSON index asynchronously into memory.

The results are subsequently injected into a persistent "Matches Sidebar"—a design motif directly reminiscent of early Adobe Acrobat's search pane8. Clicking a result updates the global state machine's document\_id and page\_index, instantly rendering the target page and triggering the hOCR synchronization logic to draw a high-contrast bounding box over the matched word on the source image view.

6. Citation Behavior

Archival software designed for serious academic or legal forensics must facilitate rigorous, highly structured citation mechanics. The application features a dedicated citation architecture that explicitly respects the provenance of the material and enforces the chain of custody for derived textual artifacts. When a user selects text within the transcript pane or highlights a specific bounding box on the source-image view, an event listener intercepts the native selection API. The system constructs a citation string dynamically by querying the current document's derived metadata, which is loaded asynchronously from the Encoded Archival Description (EAD) XML file. The generated string conforms to standard archival citation practices, appending the specific deep-link URI fragment required to recreate the state. A standard generated citation takes the programmatic structure: \[Creator\], "\[Document Title\]," \[Date\]. Collection: \[Fonds\], Box \[X\], Folder \[Y\]. Canonical Source ID: \[ID\]. Page \[N\]. Retrieved via Emulation Terminal at \[DeepLink URI\]. To enforce this rigorously, the native copy event on the document object is overridden via event.preventDefault(). If the user attempts to copy raw transcript text or markdown research text, the JavaScript engine automatically appends a shortened provenance tail to the clipboard payload using navigator.clipboard.writeText(). This deliberate interception ensures that no derived text is ever divorced from its canonical origin when pasted into an external text editor or research manifest. Furthermore, invoking the native browser print dialog (via Ctrl+P) triggers a dedicated @media print CSS payload. This specialized stylesheet aggressively strips the period-accurate UI, sidebar panes, microfilm scrubbers, and match results. It forces the DOM to transmit only the high-resolution canonical source image or the formatted plain-text transcript to the operating system's print spooler. This action guarantees that physical reproductions maintain pure archival fidelity, untainted by the emulation interface.

7. Properties/Provenance UI

The Document Properties panel serves as the central nervous system for archival transparency, mimicking the dense, tabbed dialog boxes of Windows 95 and Acrobat 3.0 interfaces1. This modal overlay provides exhaustive insights into the structural and preservation history of the canonical object being viewed. The properties panel renders raw metadata derived directly from Encoded Archival Description (EAD) and PREMIS (Preservation Metadata: Implementation Strategies) standards4.

• EAD Extraction: The panel parses the XML to display the \<eadheader\>, \<filedesc\>, \<profiledesc\>, and physical extent data5. This establishes exactly what the document is, identifying the specific sub-series, item-level records, and the broader archival hierarchy. It utilizes the \<relatedmaterial\> tags to generate actionable hyperlinks to "Related Documents," enabling lateral traversal of the archive based on subject matter or shared provenance28.
• PREMIS Integration: The panel displays rigorous preservation events29. Specifically, it enumerates the precise digitization date, the scanner hardware taxonomy, the original capture resolution, the color depth, and the compression algorithm applied to the canonical source image.

To mathematically prove the canonical file has not suffered silent data corruption or tampering on the recovered workstation, the PHP backend utilizes the hash\_file('sha256', $file\_path) function upon document initialization31. This calculated cryptographic checksum is displayed prominently in the properties panel alongside the original source identifier. The JavaScript frontend compares this real-time hash against the static manifest checksum. Any discrepancy flags the document with a high-contrast, flashing visual warning, alerting the researcher to a breach in canonical integrity.

8. Local Annotations Model

A critical feature of any profound research tool is the ability to generate marginalia. However, to maintain the absolute distinction between the canonical source and the derived presentation, annotations are never written back to the original files, databases, or cloud environments. They are handled locally utilizing the rigorous W3C Web Annotation Data Model32. Annotations, bookmarks, and structural highlights are constructed dynamically as standardized JSON-LD objects33. When a researcher draws a bounding polygon on the image or highlights text in the transcript pane, the vanilla JavaScript engine generates a compliant data structure. The selector relies heavily on the TextQuoteSelector class, which stores the exact string matched, alongside a prefix and suffix property for contextual anchoring35. This layered selector chain ensures that if the derived transcript undergoes minor re-parsing or formatting changes, the annotation can fuzzily re-anchor itself to the text. These JSON-LD objects are serialized and pushed into the browser's persistent localStorage. Furthermore, they can be manually exported as a standalone .json file, forming the basis of the "Research Tray." The Research Tray module aggregates user-defined bookmarks and local annotations across multiple discrete canonical sessions. Upon loading any page, the engine parses local storage, identifies annotations matching the active source identifier, and re-anchors them to the DOM dynamically, injecting visual indicators into the period-style UI.

9. Thumbnail/Contact-Sheet Design

The contact sheet mode offers a macro-level, cartographic overview of the archival object. Given the rigid restriction against importing third-party masonry or grid libraries, this interface is architected using native CSS Grid modules coupled with a bespoke vanilla JavaScript virtual scrolling algorithm10. The layout utilizes a highly responsive CSS structural grid: display: grid; grid-template-columns: repeat(auto-fill, minmax(150px, 1fr)); gap: 1rem;11. This ensures that thumbnails dynamically reflow as the application window is resized, maximizing screen real estate on modern widescreen displays while maintaining the rigid square framing typical of early graphical interfaces. Rendering hundreds of high-resolution page thumbnails simultaneously would overwhelm the browser's rendering engine and crash the emulation. To counter this, a virtual scrolling algorithm monitors the scrollTop offset of the contact sheet container10.

• The total scroll height is mathematically predetermined prior to rendering: [Figure omitted from source export].
• A phantom \<div\> element forces the container to this massive scrollable height.
• An IntersectionObserver or high-performance scroll event listener calculates which rows logically fall within the current viewport viewport ([Figure omitted from source export]).
• Only the \<img\> tags for strictly visible thumbnails are injected into the DOM, pointing to heavily down-sampled sidecar images. As they scroll out of view, the DOM nodes are aggressively recycled, guaranteeing a flat memory footprint regardless of collection size.

10. Deep-Link Format

Navigational state must be perfectly serialized into the URL fragment, enabling the researcher to bookmark, store in the Research Tray, or share a link that reconstructs the exact environment, viewport, and specific focus of their analytical session. The deep-link architecture utilizes a key-value hash string schema, completely bypassing the PHP backend router to remain an instantaneous client-side execution. The standardized format follows: /\#doc=\[ID\]\&page=\[N\]\&mode=\[MODE\]\&zoom=\[Z\]\&pan=\[X,Y\]\&search=\[QUERY\] Upon the native hashchange event or the initial window load sequence, the JavaScript engine parses this fragment. The execution sequence is highly deterministic:

1. doc=journal\_vol3: Asynchronously loads the canonical metadata and Markdown transcripts into memory.

2. page=42: Updates the global state index and fetches the specific canonical image.

3. mode=split: Renders the Acrobat-style two-pane view.

4. zoom=2.5\&pan=150,300: Applies the precise affine transformation matrix to the canvas, centering the view on a specific paragraph.

5. search=telegraph: Automatically executes the FTS inverted index lookup, populates the matches sidebar, and highlights the specific instances on page 42\.

This stateless rehydration ensures the application remains highly resilient; refreshing the browser simply rebuilds the exact archival environment from the fragment parameters.

11. Accessibility Behavior

An application simulating a historically restrictive retro environment must not inherit the exclusionary accessibility failures inherent to the software of the 1990s. The visual styling mimics the past, but the underlying DOM tree must satisfy rigorous modern Web Content Accessibility Guidelines (WCAG) requirements. All interactive elements, even those styled to look like the flat bitmap buttons of the Windows 95 era, are implemented as semantically correct \<button\> or \<a\> tags. The application heavily utilizes ARIA hooks (aria-live="polite", aria-hidden="true", aria-expanded) to announce state changes to assistive technologies38. Because the interface relies on dynamic pane swapping and modal properties dialogs, strict focus traps are implemented via vanilla JavaScript. When the Document Properties modal opens, focus is programmatically shifted to its first input, and tabbing is constrained exclusively within the modal until explicitly dismissed38. The transcript pane ensures its contents remain continuously readable by screen readers, intelligently hiding the raw OCR confidence artifacts and bounding box coordinates unless explicitly requested for forensic review.

12. Performance Considerations

Operating highly complex image manipulations and string parsing without the aid of WebGL wrappers or Canvas libraries requires rigorous, mathematical optimization of native APIs. The zooming, rotating, and panning of canonical source images operate on a continuous scale. To achieve 60 frames-per-second manipulation during intense physical scrubbing, CSS transform: matrix(a, b, c, d, tx, ty) is applied directly to the image wrapper, offloading the calculation to the GPU compositor39. When a user executes a mouse wheel event, the scale changes relative to the cursor position: [Figure omitted from source export] The translation offsets ([Figure omitted from source export]) must be simultaneously adjusted so the image zooms exactly where the user points, preventing visual disorientation: [Figure omitted from source export] This continuous math executes exclusively inside a requestAnimationFrame loop, guaranteeing tear-free rendering during rapid user input39. Furthermore, rendering research documents and annotations written in Markdown requires backend processing. To parse this in PHP without a massive library dependency like Parsedown, the system uses a highly optimized regular expression pipeline, functioning similarly to early procedural parsers9. A strictly bounded series of preg\_replace calls converts canonical Markdown to HTML:

• Headers: preg\_replace('/^(\#{1,6})\\s\*(.+)$/m', '\<h$1\>$2\</h$1\>', $text)
• Bold Elements: preg\_replace('/\\\\\\(.+?)\\\\\\/s', '\<strong\>$1\</strong\>', $text) This zero-dependency regex approach guarantees negligible memory overhead on the PHP server compared to full Abstract Syntax Tree (AST) parsing implementations9.

13. Mobile Behavior

Though the primary emulation target is a desktop workstation interface, practical access to the recovered archive may require interaction via tablet devices. Mobile touch events completely bypass the keyboard keydown logic, preventing event bubbling conflicts. A dedicated touch event handler manages touchstart, touchmove, and touchend phases.

• Pinch Zoom: The engine detects two concurrent touches by evaluating e.touches.length \=== 2\. It calculates the Euclidean distance between them continuously using Math.hypot(x1 \- x2, y1 \- y2)41. As the distance changes during the touchmove phase, the resulting ratio updates the Affine scale matrix, enabling smooth, native-feeling pinch-to-zoom over the historical documents.
• Macro-Swiping: Horizontal swipes with a calculated velocity exceeding a predefined millisecond threshold trigger a hard page turn or previous/next record traversal, mimicking the physical gesture of discarding a page.

14. Period-Style Design Recommendations

The aesthetic simulation of the emulation is paramount to conveying the gravitas and structural intent of a historical research terminal. To replicate the harsh glow of an OPAC terminal and the physical degradation inherent to microfilm projection, the system utilizes SVG filters applied dynamically via CSS42. An inline SVG \<filter\> generates procedural noise using the \<feTurbulence type="fractalNoise" baseFrequency="0.85" numOctaves="3" /\> primitive42. This filter is applied to a transparent overlay div spanning the viewport, set to mix-blend-mode: multiply. This casts a dynamic, organic grain over the stark digital scans, simulating physical film media. The terminal mode utilizes high-contrast \#00FF00 (phosphor green) or \#FFB000 (amber) typographies against deep black backgrounds7. Text is rendered with a slight CSS text-shadow: 0 0 5px rgba(0,255,0,0.5) to mathematically simulate CRT electron beam spread. The Acrobat-classic split-pane and properties views utilize rigid, non-anti-aliased borders. The color palette relies heavily on \#C0C0C0 (classic Windows gray), with inset and outset CSS border styles (border-top: 2px solid white; border-bottom: 2px solid \#888) to mimic the brutalist, purely functional UI controls of early desktop software1.

15. What Should Remain Modern for Usability

While the aesthetic and control paradigms are strictly retro by design, underlying operational mechanics must utilize modern paradigms to prevent profound user hostility and software failure.

1. High-DPI Font Rendering: Unlike true 1990s emulations constrained to bitmap fonts, semantic text must remain mathematically crisp on Retina and 4K displays. The transcript fonts, even if styled as a period-accurate serif like Times New Roman, must rely on modern OS-level subpixel anti-aliasing to prevent severe eye strain during deep archival reading.

2. Asynchronous Loading: Loading a 1,000-page TIFF collection in 1996 meant waiting minutes for a sequential read. This application uses the modern fetch() API and JavaScript Promises to silently preload the adjacent ([Figure omitted from source export], [Figure omitted from source export]) canonical images in the background, ensuring immediate transitions upon key press.

3. UTF-8 Canonical Encoding: Transcripts must support full Unicode standards, unlike legacy ASCII restrictions. This ensures that historical glyphs, mathematical symbols, marginalia symbols, and multi-language diacritics are accurately represented in the DOM without character corruption.

16. Detailed Interaction Test Matrix

To guarantee the reliability of the derived state machine and ensure all features trigger the correct architectural responses, the following interaction matrix defines expected behaviors for QA verification.

17. Implementation Phases

To deploy this complex, zero-dependency architecture safely, development proceeds in four distinct, logically sequential phases.

Phase 1: The Core Rendering Engine

Establish the PHP directory routing and the vanilla JavaScript state machine. Build the virtualized DOM loader capable of reading a local directory of canonical images and transcripts, mapping them precisely to the URI hash fragment. Implement the CSS Grid contact sheet mechanics, the virtual scrolling calculations, and the foundational keyboard navigation overrides.

Phase 2: The Parsing and Synchronization Layer

Implement the bespoke PHP Markdown regular expression parser for formatting research documents9. Introduce the hOCR sidecar parsing algorithms in the JavaScript frontend. Map the extracted bounding boxes to the image coordinates and build the Affine transformation matrix logic for zooming, panning, fitting, and rotating. Ensure text highlights track perfectly with the scaled image during continuous transformations.

Phase 3: Archival Intelligence and Search

Develop the PHP tokenization engine to build the search\_index.json inverted index from the canonical transcripts19. Build the frontend binary search logic to rapidly resolve FTS queries. Implement the EAD and PREMIS metadata ingest pipelines, surfacing canonical structures, physical extent data, and related materials within the period-accurate Document Properties modal.

Phase 4: Aesthetic Emulation and Annotation

Apply the final visual layers: the SVG \<feTurbulence\> film grain overlays, the CRT phosphor CSS styling, and the rigid gray Acrobat-style borders42. Implement the W3C Web Annotation Data Model to facilitate local localStorage highlighting, bookmarking, and the Research Tray compilation35. Finalize the overarching citation architecture, overriding copy and print behaviors to guarantee provenance. By maintaining strict adherence to these implementation parameters, the resulting application will stand as a profoundly resilient, hyper-focused engine for historical inquiry—immune to modern web bloat, visually authentic to its era, and rigorously defensive of canonical truth.

Works cited

1. Enable thumbnail preview of PDFs in Windows Explorer, https://helpx.adobe.com/acrobat/using/enable-pdf-thumbnail-preview-windows-explorer.html

2. Always show Acrobat page thumbnail sidebar \- Sam Young, https://www.samyoung.co.nz/2019/07/always-show-acrobat-page-thumbnail.html

3. The evolution of the command line interface (CLI) \- Contentstack, https://www.contentstack.com/blog/tech-talk/the-evolution-of-command-line-interface-cli-a-historical-insight

4. Encoded Archival Description (EAD) \- Metadata Standards Index, https://msi.dublincore.org/standards/ead

5. Encoded Archival Description \- Wikipedia, https://en.wikipedia.org/wiki/Encoded\_Archival\_Description

6. History of Interface Design on Unix \- CATB.org, http://www.catb.org/esr/writings/taoup/html/ch11s02.html

7. NovusGFX/retro-design-system \- GitHub, https://github.com/NovusGFX/retro-design-system

8. Remove or prevent sidebar from opening by default on Adobe Reader, https://superuser.com/questions/902758/remove-or-prevent-sidebar-from-opening-by-default-on-adobe-reader

9. How to parse Markdown in PHP? \- Stack Overflow, https://stackoverflow.com/questions/5116187/how-to-parse-markdown-in-php

10. vicentelyrio/virtual-grid: A React virtualization library for ... \- GitHub, https://github.com/vicentelyrio/virtual-grid

11. An Interactive Guide to CSS Grid • Josh W. Comeau, https://www.joshwcomeau.com/css/interactive-guide-to-grid/

12. Event: preventDefault() method \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault

13. How to Handle Keyboard Events in JavaScript \- Mimo, https://mimo.org/tutorials/javascript/how-to-handle-keyboard-events-in-javascript

14. Prevent default 'ctrl pageup' and 'ctrl pagedown' in Chrome, https://stackoverflow.com/questions/15094920/prevent-default-ctrl-pageup-and-ctrl-pagedown-in-chrome

15. hOCR \- OCR Workflow and Output embedded in HTML, http://kba.github.io/hocr-spec/1.2/

16. How to Preserve Font Formatting and Typography Metadata When, https://picturetext.org/blog/how-to-preserve-font-formatting-and-typography-metadata-when-extracting-text-with-ocr

17. Adding hOCR parser example for xml output · Issue \#562 \- GitHub, https://github.com/mindee/doctr/issues/562

18. Let's build a Full-Text Search engine \- Artem Krylysov, https://artem.krylysov.com/blog/2020/07/28/lets-build-a-full-text-search-engine/

19. Designing Inverted Index, https://lessthan12ms.com/inverted-index.html

20. How we built SmithDB's inverted index for full-text search \- LangChain, https://www.langchain.com/blog/full-text-search-in-smithdb-constructing-and-querying-our-inverted-index-pt-2

21. Assistance with building an inverted-index \- Stack Overflow, https://stackoverflow.com/questions/2570169/assistance-with-building-an-inverted-index

22. Searching through huge amounts of unstructured data fast(Inverted, https://medium.com/@varppi/searching-through-huge-amounts-of-unstructured-data-fast-inverted-index-834b84139e86

23. Full-text inverted index \- StarRocks Docs, https://docs.starrocks.io/docs/table\_design/indexes/inverted\_index/

24. 3 Obsolete 1990s UX Design Classics That We Love | by Designlab, https://blog.prototypr.io/3-obsolete-1990s-ux-design-classics-that-we-love-5476b084faf5

25. PREMIS | DCC \- Digital Curation Centre, https://www.dcc.ac.uk/resources/metadata-standards/premis

26. PREMIS: Preservation Metadata Maintenance Activity (Library of, https://www.loc.gov/standards/premis/

27. EAD Tag Library for Version 1.0: Overview of the EAD Structure, https://www.loc.gov/ead/tglib1998/tlover.html

28. Shape the Future of EAD: A Call to Action – Part III \- Descriptive Notes, https://saadescription.wordpress.com/2024/06/11/shape-the-future-of-ead-a-call-to-action-part-iii/

29. Metadata and documentation \- Digital Preservation Handbook, https://www.dpconline.org/handbook/organisational-activities/metadata-and-documentation

30. What Is PREMIS, and Why Should You Care About It?, https://www.backlog-archivists.com/blog/premis-metadata

31. SHA256 checksum for project folder \- NI Community, https://forums.ni.com/t5/LabVIEW/SHA256-checksum-for-project-folder/td-p/4347817

32. annotation-model \- GitHub, https://github.com/goodmansasha/annotation-model

33. MeshNotes Annotation Format Specification — Version 1.0, https://meshnotes.org/spec/annotation/v1/

34. Annotation-based enrichment of Digital Objects using open-source, https://journal.code4lib.org/articles/12582

35. Annotation Systems for Evolving Documents \- wal.sh, https://wal.sh/research/annotation-systems/

36. Virtual Scrolling in Angular Data Grid \- Syncfusion, https://ej2.syncfusion.com/angular/documentation/grid/scrolling/virtual-scrolling

37. JavaScript Virtual Scrolling Library For Large Lists, https://www.html-code-generator.com/javascript/virtual-scrolling

38. Keyboard Accessibility with Vanilla JS: Focus, Shortcuts, and ARIA, https://namastedev.com/blog/keyboard-accessibility-with-vanilla-js-focus-shortcuts-and-aria-hooks/

39. Zoom in on a point (using scale and translate) \- Stack Overflow, https://stackoverflow.com/questions/2916081/zoom-in-on-a-point-using-scale-and-translate

40. PHP Web Scraping Tutorial: cURL, Guzzle, DomCrawler \- Olostep, https://www.olostep.com/blog/web-scraping-php

41. Simplest way to detect a pinch \- javascript \- Stack Overflow, https://stackoverflow.com/questions/11183174/simplest-way-to-detect-a-pinch

42. SVG Filter Effects: Creating Texture with \- Codrops, https://tympanus.net/codrops/2019/02/19/svg-filter-effects-creating-texture-with-feturbulence/

43. Film grain filter using svg's and HTML \- GitHub Gist, https://gist.github.com/skeptrunedev/e1f0cf00641fb26bbd0acf937f57c6a5

44. Revisiting SVG filters \- my forgotten powerhouse for duotones, noise, https://utilitybend.com/blog/revisiting-svg-filters-my-forgotten-powerhouse-for-duotones-noise-and-other-effects/

45. Working with the Keyboard \- KIRUPA, https://www.kirupa.com/html5/keyboard\_events\_in\_javascript.htm