The early page turn research was based around a partial 3D publication interface and was targeted for monitors, not AR. In these models, the page was flat and could not be rotated but the page turn animation itself was in 3D and appeared to come out of the screen during a page turn sequence. One of the first roadblocks was creating a page turn animation that worked the same on all PCs, whatever the processor power. This ruled out using fixed time intervals to render a frame such as a preset FPS (Frames per second). Setting the FPS too high would result in slow machines struggling to catch up and slow down the animation. Setting the FPS too low would result in a loss of fluidity on fast machines.

The answer was in using a high precision elapsed timestamp to control frame rendering rather than a preset FPS.

Looking side on at a book for example, the page edge describes a half circle arc as it turns from one page to the next. As each frame is rendered a timestamp would pinpoint the exact position along that arc the next frame should be rendered at during the page turn sequence.

What this would result in is an identical page turn sequence on all devices. The difference being that a powerful machine would render more frames than a slower machine, but they would both render the maximum number of frames their processor and graphics hardware could handle, and the page turn sequence would always take exactly the same time to complete.

Since elapsed time is not known in advance, this meant dynamically calculating the page turn frame in real-time using the elapsed timestamp as the key variable. This ruled out pre-calculating page turn frames.

After a lot of experimentation and testing, the actual page turn sequence seems to work best when set somewhere between 0.75 and 1 second to give a fluid and fast, accurate and visually correct turn from one page to the next.

The next challenge was the page itself. It could not be flat like a board during the turn because paper bends as you turn a page and a flat page would look unnatural. A page has to gracefully flow and bend during the turn sequence to look real. This meant studying a real page and working out a mathematical equation to calculate a bending page and all its pixel positions.

The mathematical equations to calculate the position of every single pixel in a page turn frame combines conics, trigonometry and binomial equations. Then they had to go beyond that to calculate sub-pixel values. Just transferring a pixel position is not enough because the page is bending, stretching and warping meaning that a single pixel must blend into its neighboring pixels and precisely share color values to result in a rich animation without gaps and distortion.

One key requirement in the initial page turn models was that the page had to be fully scalable to meet different screen resolutions. This added another challenging factor because when a user dragged the corner of a page and resized it to their desired size, the entire content had to be refreshed to output the identical page at a new scale.

Resizing images is easy but when it comes to text output that is a completely different proposition. Text must be clear and sharp at whatever scale and layout perfectly with a font size that exactly matches the scale and with correct positioning between characters. This meant that font rendering had to be dynamic.

Due to operating system limitations in font output scaling at the time it was clear that the publication interface needed its own internal font rendering engine independent of the OS. This required extracting font vector data from font files and dynamically recalculating point values to a high precision so that the re-rendered text was always in exactly the same place at the perfect scale when a publication was resized by the user.

All the above, the page turn animation and font rendering, are processor intensive and would in a normal situation slow down rendering because of the sheer number of calculations the processor had to handle. This was solved by using optimized processor assembly language and reducing the calculations to optimized instructions sent directly to the processor rather than via the operating system using higher level programming languages.

In bypassing the operating system and directly addressing the processor an exponential speed improvement was gained in calculating page turn frames and fully scalable font output. The result was beautiful, a fluid page turn, and perfectly rendered text scaled exactly to the page.

Other components had to be incorporated but these were simple by comparison. An internal page layout engine together with custom markup language, a page position monitor to keep track of what pages should be displayed and what pages had to be turned to, and hyperlinking so that a user could easily click and turn to any page or pop back to the table of contents.

Several experimental authoring tools were built too and resulted in a fully capable editor that could be used to create any type of publication. The Editor contained the low-level components of page turning and font rendering, but with a shell built in a high-level language that could employ the full set of graphical controls a PC GUI had in its toolbox. The result was an end-to-end publishing model that had a 2D scalable page with a 3D page turn together with the means to create content.

During the initial development of a page turning interface, visionaries were talking about the coming Virtual and Augmented Reality concepts. What they were predicting and describing was both exciting and gripping. What’s more, it was clearly technically possible and only a matter of time for hardware development to catch up and make it viable.

Captivated by this fascinating VR and AR future concept, the immediate thought was: could our partial 3D publication interface be made fully 3D?

This would mean going right back to the beginning and starting again. Every pixel position of a page turn now had a new dimension, as well as font rendering had to be completely rethought out to work in 3D. All the mathematical formulas would have to be modified to include the Z factor, or the third dimension.

It was back to basics and studying the physical page turn again — but this time from all angles and distances. And then there was the page itself, which now had to incorporate perspective.

Initial development was based around wireframe models. Again, several prototypes were built and discarded because the perfect page turn needed to be discovered from trial-and-error experimentation rather than by design. The fully 3D publication interface had to incorporate the initial breakthroughs of elapsed time rendering, exact scaling, and sharp text output — but now it had to be viewed from any position and scale in 3D space and look totally natural, mimicking the real thing.

Eventually, after intensive and time-consuming research, a satisfactory wireframe model was developed and built in pure processor assembly language. It could execute a realistic page turn sequence from any viewpoint and was fully scalable.

This was patented in the US. ‘3D Publication with Page-Turn’ patent (US 2005/0066288A1), published in 2005 and granted in 2008. It is still unique and just as relevant today. There are no known other patents or patent applications that seek to improve on the concepts described in this patent.

The wireframe model gave the framework to return to pixel manipulation and duplicate the early work in 3D to render a solid graphical interface that could display a perfect page turning publication in 3D. Working models are available to demonstrate this.

But then, the next challenge was back to text output again. A 3D page turning interface is only half the equation. A 3D publication must have an internal 3D font rendering engine.

Viewing a page from any viewpoint or perspective means that text output, especially small body text, had to remain sharp, readable, and stay exactly in its place on a page when viewpoint distances change.

This is made possible because fonts are vector drawings. Vectors are made up by point data described in numbers. 3D font rendering and layout was therefore a mathematical challenge.

Again, multiple 3D font rendering prototypes were built, and the latest prototype model conclusively proves it works perfectly. The page can be rotated to any viewpoint and the characters not only re-render at any change of viewpoint but stay exactly in their same position on the page.

Page turn as navigation — The page turn is the fundamental UX primitive that defines reading flow and instant familiarity.

Elapsed-time driven animation — High‑precision timestamps, not fixed FPS, guarantee identical-duration page turns across all hardware.

Arc-based motion modeling — Page-edge trajectories are computed as mathematical arcs so every frame sits exactly where physics expects it to be.

Real-time frame computation — Frames are calculated on-the-fly from elapsed time, avoiding precomputed sequences and ensuring fluid responsiveness.

Optimal turn timing — Extensive testing found a sweet spot between 0.75 and 1 second for a page turn that feels fast, tactile, and natural.

Bending page geometry — Pages are simulated as deformable surfaces so curls, stretches, and folds match physical paper behaviour.

Per-pixel warping and sub-pixel blending — Pixel positions and color blends are computed with sub-pixel precision to avoid tearing or gaps.

Scalable layout refresh — Dragging and resizing recalculates full-page vector layouts so content remains perfectly composed at any scale.

Vector-first typography — Font outlines, not bitmaps, are the source of truth so glyphs remain crisp in perspective and distance.

Internal font engine — A dedicated rendering engine extracts and reprojects font vector data for true 3D clarity independent of OS rasterizers.

Assembly-optimized prototypes — Early builds in optimized assembly demonstrated feasibility and extreme performance on limited hardware.

GPU acceleration migration — Modern GPU pipelines now deliver equivalent or better performance with cross-platform portability.

2D-to-3D transition — The research path moved from partial 3D (flat pages with 3D turns) to full 3D pages viewable from any angle.

Z-dimension math — All page-turn equations were extended to include depth (Z) so perspective and parallax read correctly from any viewpoint.

Wireframe to pixel pipeline — Wireframe prototypes validated motion and geometry before returning to pixel-level rendering for final visuals.

Patented core concepts — The '3D Publication with Page-Turn' patent secures the unique combination of page-turn math and rendering approaches.

Deterministic pagination rules — Canonical layout rules ensure identical page breaks and composition across devices and edits.

Multi-resolution glyph strategy — Dynamic glyph tessellation and LOD caching keep small body text legible at distance without wasting GPU cycles.

Predictive and foveated rendering — Motion prediction and eye-aware LOD focus resources where the reader is actually looking.

Temporal stability techniques — Reprojection and asynchronous compositing preserve sharpness through head and eye motion.

Hybrid fallbacks — Low-end devices can use pre-rasterized pages to preserve interactivity while reducing compute load.

Page layout engine — A custom layout core handles columns, grids, floats, and hyphenation deterministically for spatial pages.

Custom markup and authoring tools — Experimental editors proved a full authoring workflow is possible with built-in page-turn primitives.

Hyperlinking and navigation model — Semantic anchors, TOC jumps, and hit-tested spatial UI map naturally to the page-turn paradigm.

Proven demos available — Working models exist that demonstrate high-fidelity page turns and 3D font rendering.

Rendering accuracy at scale — Tests confirm identical visual results when the same publication is viewed at different sizes and distances.

Localization of math for devices — Rendering pipelines adapt shader paths and precision to match device GPU and display characteristics.

Instrumentation and metrics — Runtime telemetry enables visual quality gates that trade off LOD, AA, and refresh to hit target FPS or power budgets.

Security and provenance in rendering — Render paths support watermarking and signed manifests to protect IP without visual degradation.

Accessibility baked in — Dynamic text scaling, dyslexic font support, and TTS anchors are intrinsic to the rendering and layout stack.

Cross-platform deployment — The engine is designed for WASM/WebXR, native SDKs, and head-mounted runtimes for broad device reach.

Tooling for publishers — Live preview, exportable spatial templates, and automated precompilation streamline production and distribution.

Roadmap to maturity — From assembly proofs to GPU-accelerated engines to SDKs and portal integration, the research is production-ready.

Next steps — Systematic demo polish, cross-device benchmarks, SDK wrappers, and publisher workflows to move from prototype to platform.

Why it matters — Decades of R&D solve the technical hurdles so spatial publishing can be beautiful, fast, and commercially viable the moment devices arrive.