fix: remove UTF-8 pi symbol from basic_plots.md breaking FORD in CI #220
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The pi symbol (π) in basic_plots.md was causing UTF-8 parsing errors in the CI environment, preventing FORD from generating HTML files for: - basic_plots.html - annotation_demo.html - colored_contours.html - contour_demo.html This resulted in 404 errors on GitHub Pages. Replaced π with 'pi' to ensure ASCII-only content that works in all CI environments. Fixes GitHub Pages 404 errors for example documentation.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
krystophny
added a commit
that referenced
this pull request
Aug 23, 2025
…put docs - Replace %???? binary characters with %[binary] placeholder in scale_examples.md - Add BACKLOG.md to track current work on ASCII backend PDF output issue - Addresses issue where ASCII backend incorrectly generates PDF binary data fixes #220
krystophny
added a commit
that referenced
this pull request
Aug 23, 2025
…put docs - Replace %???? binary characters with %[binary] placeholder in scale_examples.md - Add BACKLOG.md to track current work on ASCII backend PDF output issue - Addresses issue where ASCII backend incorrectly generates PDF binary data fixes #220
krystophny
added a commit
that referenced
this pull request
Aug 23, 2025
Fixes issue #220 where .txt files generated PDF binary data instead of ASCII text. Root cause: The switch_backend_if_needed() function was hardcoding current_backend='ascii' instead of detecting the actual backend type. When a figure switched from ASCII->PDF->ASCII, the backend remained PDF but the switching logic incorrectly assumed it was ASCII, skipping the necessary switch back to ASCII backend. Solution: Use polymorphic type checking (select type) to properly detect the current backend type by examining the allocated backend object. Changes: - Replace hardcoded backend assumption with runtime type detection - Add proper imports for all backend context types - Maintain existing PNG backend workaround for segfault prevention Testing: - Verified with scale_examples.f90: .txt files now contain ASCII text - File type detection confirms files are "ASCII text" not "PDF document" - Sequential backend switching (ASCII->PDF->ASCII) works correctly 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
5 tasks
krystophny
added a commit
that referenced
this pull request
Aug 23, 2025
#222) ## Summary - Fix issue #220: ASCII backend was generating PDF binary content instead of text output for .txt files - Root cause: Backend switching logic hardcoded current backend assumption instead of detecting actual type - Solution: Use polymorphic type checking to properly detect current backend type ## Test plan - [x] Verified with scale_examples.f90: .txt files now contain proper ASCII text visualization - [x] File type detection confirms files are "ASCII text" not "PDF document" - [x] Sequential backend switching (ASCII->PDF->ASCII) works correctly - [x] Output files are UTF-8 compatible for documentation tools - [x] Box drawing characters and proper text formatting in ASCII output ## Details The bug occurred when a figure switched backends multiple times (e.g., ASCII -> PDF -> ASCII). The `switch_backend_if_needed()` function was hardcoding `current_backend = 'ascii'` instead of checking what backend was actually allocated. This caused the function to skip backend switching when it should have switched from PDF back to ASCII for .txt files. The fix uses `select type` to examine the polymorphic backend object and correctly identify whether it's an `ascii_context`, `pdf_context`, `png_context`, etc. 🤖 Generated with [Claude Code](https://claude.ai/code) --------- Co-authored-by: Claude <noreply@anthropic.com>
krystophny
added a commit
that referenced
this pull request
Aug 24, 2025
krystophny
added a commit
that referenced
this pull request
Aug 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
GitHub Pages was still showing 404 errors for example HTML documentation after PR #219, specifically:
Root Cause Analysis
Investigation of CI logs revealed that FORD was still reporting UTF-8 parsing errors for specific files:
These UTF-8 parsing errors were preventing FORD from generating HTML files for those documents.
The Issue
A single UTF-8 character (π symbol) in
basic_plots.mdwas causing the problem:While this works fine in local development environments, the CI environment has stricter UTF-8 handling that caused FORD parsing to fail.
Solution
Replace the π symbol with ASCII 'pi':
Verification
file -bi doc/example/basic_plots.mdnow returnscharset=us-asciiThis final fix should resolve the remaining GitHub Pages 404 errors.