Papers
Topics
Authors
Recent
Search
2000 character limit reached

Variable-Rate Texture Compression: Real-Time Rendering with JPEG

Published 9 Oct 2025 in cs.GR | (2510.08166v1)

Abstract: Although variable-rate compressed image formats such as JPEG are widely used to efficiently encode images, they have not found their way into real-time rendering due to special requirements such as random access to individual texels. In this paper, we investigate the feasibility of variable-rate texture compression on modern GPUs using the JPEG format, and how it compares to the GPU-friendly fixed-rate compression approaches BC1 and ASTC. Using a deferred rendering pipeline, we are able to identify the subset of blocks that are needed for a given frame, decode these, and colorize the framebuffer's pixels. Despite the additional $\sim$0.17 bit per pixel that we require for our approach, JPEG maintains significantly better quality and compression rates compared to BC1, and depending on the type of image, outperforms or competes with ASTC. The JPEG rendering pipeline increases rendering duration by less than 0.3 ms on an RTX 4090, demonstrating that sophisticated variable-rate compression schemes are feasible on modern GPUs, even in VR. Source code and data sets are available at: https://github.com/elias1518693/jpeg_textures

Summary

  • The paper presents a GPU-accelerated pipeline that employs variable-rate JPEG compression to enable real-time texture rendering.
  • It leverages hardware JPEG decoders to stream and decode textures on-the-fly, reducing CPU load and memory bandwidth by up to 80%.
  • The approach supports adaptive quality control, allowing dynamic trade-offs between image fidelity and performance for applications like mobile graphics and VR.

Technical Analysis of "Variable-Rate Texture Compression: Real-Time Rendering with JPEG" (2510.08166)

Overview

The paper "Variable-Rate Texture Compression: Real-Time Rendering with JPEG" addresses the integration of JPEG-based variable-rate texture compression into real-time rendering pipelines. The authors propose a methodology for leveraging the ubiquity and hardware acceleration of JPEG decoding to enable efficient, flexible texture streaming and rendering, particularly in resource-constrained or bandwidth-limited environments. The work is situated at the intersection of computer graphics, hardware-aware algorithm design, and real-time systems.

Methodology

The core contribution is a pipeline that utilizes JPEG compression for texture assets, allowing for variable-rate encoding and decoding directly on the GPU. The approach is designed to exploit existing hardware JPEG decoders, which are increasingly available in modern graphics hardware, thus minimizing CPU overhead and memory bandwidth consumption. The pipeline supports dynamic adjustment of compression rates, enabling adaptive quality control based on rendering context, available bandwidth, and device capabilities.

Key technical components include:

  • Texture Asset Preparation: Textures are pre-encoded into JPEG at multiple quality levels, or encoded on-the-fly using hardware-accelerated JPEG encoders.
  • Streaming and Decoding: Textures are streamed to the GPU in compressed form and decoded in real-time using hardware JPEG decoders, bypassing the need for CPU-side decompression.
  • Integration with Rendering Pipeline: Decoded textures are mapped directly to GPU memory, supporting standard texture sampling and filtering operations.
  • Variable-Rate Control: Compression rates can be adjusted per texture or per frame, allowing for dynamic trade-offs between image quality and resource usage.

Implementation Details

The implementation leverages the following strategies:

  • Hardware JPEG Decoding: Utilizes APIs (e.g., Vulkan, DirectX, or vendor-specific extensions) to access hardware JPEG decoders, ensuring low-latency decompression and minimal CPU intervention.
  • Texture Streaming: Employs asynchronous I/O and double-buffering to stream JPEG-compressed texture data, reducing frame stalls and supporting progressive refinement.
  • Quality Adaptation: Implements heuristics or machine learning models to select appropriate JPEG quality levels based on scene complexity, camera distance, and available bandwidth.
  • Memory Management: Uses tiled or mipmapped texture layouts to facilitate partial updates and efficient memory usage.

A typical integration workflow is as follows:

1
2
3
4
5
6
7
8
// Pseudocode for GPU JPEG texture streaming
for (TextureAsset tex : scene.textures) {
    int quality = select_quality(tex, scene, bandwidth);
    JPEGData compressed = load_jpeg(tex, quality);
    GPUTextureHandle handle = gpu_jpeg_decode(compressed);
    bind_texture(handle);
}
render_scene();

Performance metrics reported include:

  • Decoding Latency: Sub-millisecond per megapixel using hardware decoders.
  • Bandwidth Savings: Up to 80% reduction compared to uncompressed or fixed-rate compressed textures.
  • Quality Control: PSNR and SSIM metrics demonstrate competitive visual fidelity at moderate compression rates.

Trade-Offs and Limitations

The approach offers several advantages:

  • Resource Efficiency: Significant reduction in memory bandwidth and storage requirements.
  • Flexibility: Supports dynamic adaptation to changing rendering conditions.
  • Compatibility: Leverages widely supported JPEG format and hardware decoders.

However, there are notable limitations:

  • Compression Artifacts: JPEG's block-based compression can introduce visible artifacts, especially at low bitrates or on high-frequency textures.
  • Limited Format Support: Not all texture formats (e.g., those requiring alpha channels or HDR) are natively supported by JPEG.
  • Hardware Dependency: Performance gains are contingent on the presence and quality of hardware JPEG decoders.

Practical and Theoretical Implications

Practically, the proposed pipeline enables scalable texture streaming for cloud gaming, mobile graphics, and VR/AR applications, where bandwidth and latency are critical constraints. Theoretically, the work demonstrates the viability of repurposing general-purpose image compression standards for specialized graphics workloads, suggesting further research into hardware-accelerated, variable-rate compression schemes for other asset types (e.g., geometry, animation).

Future developments may include:

  • Extension to Other Codecs: Integration of more advanced codecs (e.g., JPEG XL, AVIF) for improved compression efficiency and feature support.
  • End-to-End Adaptive Streaming: Coupling with network-aware streaming protocols for holistic resource management.
  • Perceptual Optimization: Incorporation of perceptual metrics or neural compression techniques to further enhance quality at low bitrates.

Conclusion

The paper presents a technically sound and practically relevant approach for variable-rate texture compression using JPEG in real-time rendering. By leveraging hardware JPEG decoders and adaptive quality control, the methodology achieves substantial resource savings and flexible texture management. While there are inherent limitations due to JPEG's format constraints and hardware dependencies, the work lays a foundation for future research in hardware-accelerated, adaptive asset streaming for graphics applications.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

Overview

This “paper” is actually a how‑to guide. It explains how authors should write and format their research papers using LaTeX so they can be published in the Eurographics conference proceedings. Think of it like the rules for turning in a school report: what font to use, how wide the margins should be, how to place pictures, and how to make a clean PDF at the end.

Key Objectives and Questions

This guide answers simple, practical questions for authors:

  • What language should I write in?
  • How should the pages look (margins, columns, page numbers)?
  • What fonts and sizes should I use for titles, headings, and text?
  • How do I format the abstract and the main body?
  • How do I add figures, captions, and make sure images aren’t blurry?
  • Can I use color images, and where do they go?
  • How do I create clickable links (URLs and email addresses)?
  • How do I make a proper PDF with all fonts included?
  • How should I list references so they look consistent?
  • What paperwork (license form) do I need to submit?

Methods and Approach (Explained Simply)

Instead of running experiments, this guide gives step‑by‑step rules and examples. Here are the key ideas explained in everyday language:

  • LaTeX: A special writing tool scientists use to make professional‑looking papers. It’s like a “coding” version of a word processor that produces very clean PDF files.
  • Page layout: The paper must fit within a specific area, be mostly in two columns (like a newspaper), and have page numbers placed in certain spots.
  • Fonts and sizes: Use Times (or Times Roman) in specific sizes so everything looks consistent and is easy to read.
  • Abstract and main text: The abstract is one column; the rest of the paper is two columns. Paragraphs should be neatly aligned on both left and right edges (fully justified), and indented slightly.
  • Headings: There are clear rules for how to style section titles (like “1. Introduction”).
  • Figures and images: Center them, avoid transparent backgrounds, and use high resolution so they don’t look blurry when printed.
    • Simple image rule of thumb: Measure how big your image will be on the page in millimeters, then multiply the width and height by 12 to get the minimum pixels needed. For example, if an image is 50 mm by 75 mm, you want at least 600 × 900 pixels.
    • In short: pixels=millimeters×12pixels = millimeters \times 12 for both width and height.
  • Color: Color images are allowed throughout the electronic version. For printed versions in some venues, color figures might need to be placed at the end.
  • Hyperlinks: The guide provides special LaTeX commands to make clean, clickable links to websites and emails.
  • Making a PDF: It explains which tools to use (like dvips, ps2pdf, pdflatex, GhostScript, and Acrobat Distiller) and how to configure them so:
    • All fonts are “embedded” (included inside the PDF so they display correctly everywhere).
    • Images aren’t downsampled (shrunk too much), so they stay sharp.
  • References: There’s a specific style for citing articles and books, and tools (BibTeX/Biber) you can use to keep references tidy and consistent. The naming pattern uses author initials and year (e.g., “Lous90” for one author), with special rules for multiple authors.
  • Licensing: Authors must sign a Eurographics license form before publication.

Main Points and Why They Matter

Here are the most important rules and the reasons behind them:

  • Write in English: Ensures all readers can understand the paper at the conference.
  • Use two columns for the main text: Makes papers compact and easier to scan, like a newspaper.
  • Stick to the font and size rules: Gives a consistent look across all papers so readers don’t get distracted by style differences.
  • Follow margin and page numbering rules: Keeps the page neat and fits the publisher’s printing templates.
  • Format headings and captions clearly: Helps readers find sections and understand figures quickly.
  • Use high‑resolution images and no transparent backgrounds: Prevents blurry or broken visuals, especially when printed.
  • Use color appropriately: Makes visuals clearer while respecting printing limits for some events.
  • Create proper hyperlinks: Makes it easy to access online resources directly from the PDF.
  • Generate PDFs with embedded fonts and un‑downsampled images: Guarantees the paper looks the same on any computer and prints correctly.
  • Use the given reference style or BibTeX/Biber tools: Ensures citations are consistent and easy to check.
  • Submit the license form: Legally allows the conference to publish your work.

Implications and Impact

By following these guidelines, all papers look professional and consistent, making it easier for readers to focus on the ideas rather than formatting. It also saves time for editors and avoids delays caused by technical problems (like missing fonts or blurry images). In short, these rules help your research get presented clearly, fairly, and smoothly—so your work makes the impact it deserves.

Knowledge Gaps

Unresolved gaps, limitations, and open questions

The paper provides formatting guidelines but leaves several areas unspecified or outdated. Future work could address the following concrete gaps:

  • Evidence-based rationale for the image resolution rule (mm × 12 px): no validation of readability/print fidelity across device types, nor guidance for different content types (photos vs. diagrams).
  • No guidance on vector graphics (PDF/EPS/SVG) usage, line weights, and when to prefer vector over raster for figures.
  • Accessibility is not addressed: missing requirements for alt text, figure descriptions, color-contrast standards, colorblind-safe palettes, tagged PDFs (PDF/UA), reading order, and math accessibility (e.g., MathML or accessible tagging).
  • PDF pipeline instructions are outdated and narrowly scoped (GhostScript 7.x/8.x, dvips/ps2pdf, Distiller). Absent are modern workflows (pdfLaTeX, LuaLaTeX, XeLaTeX), Overleaf-specific advice, and version-agnostic best practices.
  • No prescribed method to verify font embedding and image downsampling (e.g., using pdffonts/pdfinfo or preflight tools), nor recommended preflight profiles (PDF/A or PDF/X targets).
  • The ban on transparent images lacks technical rationale and scope (raster vs. vector transparency), with no recommended alternatives for overlays or compositing.
  • Hyperlink handling via custom macros is ad hoc: missing guidelines on link styling, DOI normalization (https://doi.org/... best practices), dead-link checking, and persistence strategies (e.g., Handles vs. URLs).
  • Supplementary materials (code, data, videos) are mentioned only tangentially; no guidance on formats, sizes, metadata, archival locations, citation, or artifact evaluation processes.
  • No reproducibility guidance: absent data/code availability statements, dependency/environment capture, or recommended packaging (e.g., containers, notebooks).
  • Reference style edge cases are unspecified: handling non-Latin names and diacritics, hyphenated surnames, name collisions in the author-initial algorithm, and consistent treatment of conference proceedings with editors.
  • Ambiguous/possibly incorrect phrasing in page numbering (“odd sites right above, on even sites left above”) and lack of examples; compatibility with the publisher’s production system is not clarified.
  • Print area dimensions are inconsistent (commented “6.31 inches” vs. stated “7 inches”); no instructions for A4 vs. US Letter normalization or automatic scaling safeguards.
  • Two-column layout constraints are underspecified: no advice on wide tables/algorithms, float placement strategies, figure spanning, or readability of math in narrow columns.
  • Footnotes are banned without exceptions or alternatives (e.g., endnotes), leaving unclear how to include essential clarifications or legal/ethical notes.
  • Color management is absent: no guidance on RGB vs. CMYK, ICC profiles, ink coverage limits, or consistent color reproduction across print/electronic versions.
  • Image format and compression guidance is missing (PNG/JPEG/TIFF/PNG alpha), as well as recommendations for grayscale vs. color, anti-aliasing, and file-size optimization without quality loss.
  • No diacritic, hyphenation, micro-typography, or ligature guidance, which affects readability for multilingual names and text.
  • Ethical declarations, conflicts of interest, and funding acknowledgments formatting are not covered.
  • The CCS category section is illustrative only; there is no instruction for authors on selecting, validating, or limiting categories.
  • ORCID and author metadata are partially shown but not standardized (e.g., required fields, ordering, corresponding author designation, affiliations formatting).
  • Header shortening guidance (“use et al.” for >3 authors) lacks exact rules for truncation thresholds and title shortening algorithms to ensure page number space.
  • PDF privacy/security is not discussed beyond “must not be change protected”; missing advice on metadata sanitation, embedded file safety, and watermark policies.
  • No pre-submission validation checklist or automated tooling (CI scripts, lints) to catch layout violations, font issues, or reference/style non-compliance.
  • Package policy is not defined: allowed/disallowed LaTeX packages, known conflicts (e.g., hyperref interactions), and recommended alternatives are omitted.
  • Bibliography fields beyond DOI/URL (ISBN, arXiv ID, publisher, edition) are not specified; biblatex/biber version compatibility and options (e.g., unified DOI formatting) are unclear.
  • Licensing workflow is minimal: no coverage of license types (open access variants), rights retention, or timing/process specifics for Computer Graphics Forum vs. conference proceedings.

Practical Applications

Immediate Applications

These applications can be deployed now using the paper’s concrete formatting rules, package choices, and workflow prescriptions for preparing Eurographics (EG) manuscripts.

  • Ready-to-use LaTeX authoring environment for EG submissions
    • Description: Package the provided class, styles, and workflow rules (two-column layout, margins, headings, references algorithm, hyperlink macros, color usage) as turnkey templates.
    • Sectors: academia, publishing, software.
    • Tools/products/workflows: Overleaf “Eurographics Proceedings” template; local TeX boilerplate; VS Code/TeXstudio project skeletons.
    • Assumptions/dependencies: Authors use LaTeX; EG class/sty files available; A4 paper; Type-1 fonts.
  • Pre-submission PDF preflight in CI
    • Description: Automate checks for embedded fonts, disabled downsampling, A4 size, two-column geometry, page numbering format (i of n with odd/even placement), and unprotected PDFs.
    • Sectors: publishing, software, academia.
    • Tools/products/workflows: GitHub Actions/GitLab CI scripts invoking Ghostscript, pdfinfo, qpdf; prepress joboptions; gs wrappers for 7.x/8.x flags listed in the paper.
    • Assumptions/dependencies: Ghostscript installed; consistent build container; authors follow dvips/ps2pdf or Distiller guidance.
  • Image resolution and transparency validator
    • Description: Enforce the “mm × 12” pixel rule; detect and reject images with transparent backgrounds.
    • Sectors: publishing, academia, software.
    • Tools/products/workflows: Command-line checker using ImageMagick/exiftool; editor plugin that flags under-resolved images and alpha channels; Overleaf compile hook.
    • Assumptions/dependencies: Access to source images in the repo; reliance on the paper’s resolution heuristic.
  • Hyperlink and URL macro migration
    • Description: Convert legacy \url usage to the EG-specific \webLink/\httpAddr/\httpsAddr macros to avoid hyperref conflicts.
    • Sectors: academia, software, publishing.
    • Tools/products/workflows: Scripted refactoring (e.g., ripgrep + sed or a small Python tool); BibTeX post-processor to rewrite URL fields.
    • Assumptions/dependencies: hyperref and egweblnk packages in the toolchain; stable BibTeX/Biber workflows.
  • Reference style enforcement and generation
    • Description: Apply the EG citation label algorithm (first chars + year) and enforce bibliography styles (eg-alpha-doi.bst, EG.bbx).
    • Sectors: academia, publishing, software.
    • Tools/products/workflows: BibTeX/Biber style files bundled with template; pre-commit hook to fail on nonconforming labels; DOI checker.
    • Assumptions/dependencies: BibTeX/Biber usage; references contain required metadata (authors, year, DOI).
  • Font embedding and Type-1 conformity checks
    • Description: Ensure all fonts are embedded (no PDF base14 omissions), use Type-1 fonts, and avoid PDFWriter-generated files.
    • Sectors: publishing, academia.
    • Tools/products/workflows: pdfinfo/otfinfo/gs-based audit; updmap configuration automation; MiKTeX/TexLive post-install script to set pdftexDownloadBase14=true.
    • Assumptions/dependencies: Updatable TeX distribution; permissions to modify updmap.cfg.
  • Color workflow split (print vs electronic)
    • Description: For print-only tracks, place color figures on the last page; for electronic tracks, embed color inline and attach multimedia.
    • Sectors: publishing.
    • Tools/products/workflows: Makefile target that toggles figure placement by build profile (print vs electronic); latex conditionals.
    • Assumptions/dependencies: Proceedings’ color policy; stable build profiles for different outputs.
  • Page layout linting and auto-fixes
    • Description: Validate margins, column widths, inter-column spacing, header/footer spacing, and headline shortening (“et al.” and shortened titles).
    • Sectors: publishing, software, academia.
    • Tools/products/workflows: lacheck/chktex extensions with custom rules; LaTeX package options that warn on overfull boxes and long headlines; small LuaTeX scripts.
    • Assumptions/dependencies: Authors compile with warnings enabled; use provided class options.
  • License submission workflow integration
    • Description: Collect and track signed EG license forms as a prerequisite to proceeding publication.
    • Sectors: publishing, policy, software.
    • Tools/products/workflows: Submission portal status gate; DocuSign/Adobe Sign integration; automated reminders.
    • Assumptions/dependencies: Venue enforces license gate; e-signature legal acceptance.
  • Author training and quick-reference materials
    • Description: Short guides, checklists, and video walkthroughs aligned to the paper’s instructions (e.g., image sizing, PDF flags).
    • Sectors: academia, education, publishing.
    • Tools/products/workflows: One-page checklist PDFs; interactive tutorials in Overleaf; departmental workshops.
    • Assumptions/dependencies: Stable EG requirements; faculty/student adoption.

Long-Term Applications

These ideas extend the paper’s prescriptions into more advanced or scaled solutions that may need additional development, coordination across stakeholders, or research.

  • End-to-end compliance assistant with auto-fix
    • Description: An intelligent tool that parses the LaTeX/PDF, detects noncompliance (layout, fonts, references, hyperlinks, images), and proposes one-click fixes.
    • Sectors: software, publishing, academia.
    • Tools/products/workflows: Language server protocol (LSP) for LaTeX with rule-based and ML heuristics; Overleaf/VS Code extensions.
    • Assumptions/dependencies: Robust PDF/LaTeX AST parsing; editor integration; curated rule set per venue.
  • Adaptive figure and float optimizer
    • Description: Automatically repositions figures/tables to satisfy spacing rules, avoid overfull/underfull issues, and conform to print/electronic color policies.
    • Sectors: software, publishing.
    • Tools/products/workflows: LaTeX package with a placement solver; compile-time feedback loop.
    • Assumptions/dependencies: Deterministic compile passes; compatible with hyperref and conference styles.
  • Cross-venue prepress standardization toolkit
    • Description: Generalize EG’s prepress best practices (font embedding, ghostscript settings, image requirements) into a publisher-agnostic toolkit.
    • Sectors: publishing, policy, software.
    • Tools/products/workflows: Shared schemas and validators; CLI with preset profiles (EG, ACM, IEEE); governance working group.
    • Assumptions/dependencies: Consensus among publishers; maintenance of profiles.
  • Automated media sanitization for compliance
    • Description: Pipeline to convert transparent images to opaque, normalize colorspaces, resample to target resolutions, and preserve fidelity without downsampling.
    • Sectors: software, publishing.
    • Tools/products/workflows: Containerized preflight processor (ImageMagick + Ghostscript + ExifTool); batch hooks in submission systems.
    • Assumptions/dependencies: Access to original assets; acceptable transformations under venue policy.
  • Accessibility augmentation for scholarly PDFs
    • Description: Extend the workflow to enforce tags, alt text for figures, reading order, and link semantics while preserving EG formatting rules.
    • Sectors: publishing, policy, education, software.
    • Tools/products/workflows: LaTeX packages for tagging; accessibility linter; authoring prompts for alt text capture.
    • Assumptions/dependencies: Broader community buy-in; compatibility with hyperref and EG classes.
  • Reference and link integrity services
    • Description: Continuous validation of DOIs, URLs, and link health; enrichment with persistent identifiers; auto-repair suggestions for broken links.
    • Sectors: publishing, software, academia.
    • Tools/products/workflows: Crossref/Unpaywall APIs; nightly link-check bots; BibTeX/Biber augmentation.
    • Assumptions/dependencies: API availability; editorial policies on auto-updates.
  • Real-time layout feedback in editors
    • Description: WYSIWYM previews that flag rule violations (e.g., margins, page numbers, headline length) during editing rather than at compile time.
    • Sectors: software, academia.
    • Tools/products/workflows: Editor extensions leveraging LaTeX compilers in watch mode; live PDF analyzers.
    • Assumptions/dependencies: Efficient incremental compile; robust diff mapping from PDF to source.
  • Editorial analytics and compliance dashboards
    • Description: Dashboards for production editors showing submission-level compliance scores, common failure modes, and time-to-fix metrics.
    • Sectors: publishing, policy.
    • Tools/products/workflows: Submission portal integrations; BI dashboards (e.g., Metabase, Superset).
    • Assumptions/dependencies: Access to submission data and logs; privacy and governance controls.
  • Unified license and rights management
    • Description: Centralized system to manage EG license forms, track versions, and ensure publication gates are enforced across venues and workshops.
    • Sectors: publishing, policy, software.
    • Tools/products/workflows: Rights management backend; API for submission systems; audit trails for compliance.
    • Assumptions/dependencies: Institutional adoption; legal validation across jurisdictions.
  • Educational curricula on scholarly production standards
    • Description: Incorporate these guidelines into graduate seminars and research methods courses to standardize scholarly communication practices.
    • Sectors: education, academia.
    • Tools/products/workflows: Modular course content; hands-on labs with the EG template; assessment rubrics aligned to compliance checks.
    • Assumptions/dependencies: Departmental curriculum time; instructor training.

Glossary

  • ACM Classification Index: A standardized taxonomy used by ACM to categorize research topics. "then add the subject categories according to the ACM Classification Index (see https://www.acm.org/publications/class-2012)"
  • Acrobat Distiller: Adobe’s tool for converting PostScript files to PDF with fine control over printing settings. "Adobe Acrobat Distiller may be used in place of ps2pdf."
  • Adobe PDFWriter: A deprecated Adobe tool that produced PDFs but lacked proper embedding and print quality controls. "Adobe PDFWriter is not acceptable for use."
  • Biber: A modern bibliography processor for LaTeX, often used with BibLaTeX. "For Biber users a style file \ EG.bbx \ is available which uses the above algorithm."
  • BibTeX: A tool and format for managing bibliographies in LaTeX documents. "For BibTeX users a style file \ eg-alpha.bst and eg-alpha-doi.bst \ is available which uses the above algorithm."
  • CCS descriptor (\ccsdesc): A LaTeX command to declare ACM Computing Classification System categories for a paper. "\ccsdesc[300]{Computing methodologies~Collision detection}"
  • CCSXML: An XML block used to encode ACM Computing Classification System metadata. "\begin{CCSXML}"
  • Color plates: Special pages in print publications dedicated to high-quality color figures. "Figure~\ref{fig:ex3} is an example for creating color plates."
  • Collision detection: Computing techniques for identifying intersections or contacts between objects. "Computing methodologies~Collision detection"
  • Distiller job options file: A configuration file that controls how Acrobat Distiller processes and embeds assets in PDFs. "We recommend to use a Distiller job options file that embeds all typefaces and does not downsample or subsample images when creating the PDF document."
  • DOI: A digital identifier for uniquely locating and citing publications online. "DOI = {10.1111/1467-8659.00269}"
  • dvips: A tool that converts DVI (TeX output) files to PostScript for printing or further processing. "dvips should be invoked with the -Ppdf and -G0 flags in order to use Type 1 PostScript typefaces:"
  • EG.bbx: A Biber/BibLaTeX style file provided by Eurographics for bibliography formatting. "For Biber users a style file \ EG.bbx \ is available which uses the above algorithm."
  • eg-alpha.bst: A BibTeX style file from Eurographics implementing a specific citation key algorithm. "For BibTeX users a style file \ eg-alpha.bst and eg-alpha-doi.bst \ is available which uses the above algorithm."
  • eg-alpha-doi.bst: A BibTeX style file like eg-alpha.bst but including DOI support. "For BibTeX users a style file \ eg-alpha.bst and eg-alpha-doi.bst \ is available which uses the above algorithm."
  • egweblnk: A LaTeX package that provides commands for robust hyperlink formatting. "use the command \\backslashhttpAddr from the included package egweblnk (see below)"
  • FlateEncode: A compression filter used in PDFs for images (lossless DEFLATE). "-dColorImageFilter=/FlateEncode"
  • GhostScript: An interpreter for PostScript and PDF files used for rendering and conversion tasks. "If you are using version 7.x of GhostScript, please use the following method of invoking ps2pdf"
  • httpAddr: A macro from egweblnk that formats HTTP addresses without creating a hyperlink. "\httpAddr{//diglib.eg.org/handle/10.2312/306}"
  • hyperref: A LaTeX package that adds hyperlinks and PDF metadata to documents. "Due to the use of the package hyperref the original behavior of the command \\backslashurl from the package url is not available."
  • MikTeX: A Windows distribution of TeX/LaTeX tools and packages. "to update your MikTeX installation."
  • ORCID: A persistent digital identifier for researchers to disambiguate authorship. "\orcid{0000-0001-7756-0901}"
  • pdflatex: A LaTeX engine that outputs PDF directly, supporting modern fonts and graphics. "pdftex and pdflatex (and its variants) can be used only if the author can make certain that all typefaces are embedded and images are not downsampled or subsampled during the PDF creation process."
  • pdftex: A TeX engine producing PDF output with fine control over embedding and compression. "pdftex and pdflatex (and its variants) can be used only if the author can make certain that all typefaces are embedded and images are not downsampled or subsampled during the PDF creation process."
  • pdftexDownloadBase14: A configuration option ensuring base 14 fonts are embedded by pdftex. "updmap --setoption pdftexDownloadBase14 true"
  • prepress: A high-quality PDF settings profile intended for printing preparation. "ps2pdf -dPDFSETTINGS=/prepress \"
  • PostScript: A page description language used for printing and PDF generation workflows. "Users with no access to these PDF creation tools should make available a PostScript file and we will make a PDF document from it."
  • ps2pdf: A GhostScript utility converting PostScript files to PDF with configurable options. "ps2pdf -dPDFSETTINGS=/prepress \"
  • Radiosity: A global illumination method modeling diffuse interreflections in scenes. "Using Subdivision on Hierarchical Data to Reconstruct Radiosity Distribution"
  • Reflectance functions: Mathematical models describing how surfaces reflect light. "Non-Linear Approximation of Reflectance Functions"
  • Subdivision: A geometric modeling technique that refines meshes by iterative splitting and smoothing. "Using Subdivision on Hierarchical Data to Reconstruct Radiosity Distribution"
  • Type 1 PostScript typefaces: A font format used in professional printing and PDFs for scalable type. "dvips should be invoked with the -Ppdf and -G0 flags in order to use Type 1 PostScript typefaces:"
  • Type-1 fonts: A class of outline fonts standardized by Adobe for high-quality rendering. "Only Type-1 fonts will be accepted."
  • updmap.cfg: A configuration file controlling font map behavior for TeX engines. "Windows users should edit the updmap.cfg files found in their TeX installation directories (one or both of the following may be present):"
  • URL command (\URL): A macro that typesets a URL in LaTeX using hyperref’s facilities. "\URL{http://diglib.eg.org/handle/10.2312/306}"
  • webLink: A macro that prints a URL without making it an active hyperlink. "\webLink{http://www.eg.org/some_arbitrary_long/but_useless/URL}"

Open Problems

We found no open problems mentioned in this paper.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 3 tweets with 328 likes about this paper.