Fix/system fonts api 5479

[SakShamJain8]

Description of Changes

This PR adds system fonts API endpoint and frontend integration to enable users to select from available system fonts in the Stirling PDF application.

Summary

• Backend: Added /api/v1/general/fonts public API endpoint that returns a cached list of system-installed fonts
• Backend: Implemented FontService to discover and cache fonts from AWT and system font directories
• Backend: Added FontController with endpoints:
  • GET /api/v1/general/fonts - Returns list of available fonts
  • POST /api/v1/general/fonts/refresh - Forces font cache refresh after system font installation
• Security: Added /api/v1/general/fonts to public whitelist in RequestUriUtils (no authentication required)
• Frontend: Created useSystemFonts hook that:
  • Fetches fonts from backend
  • Supports both web (Vite proxy) and Tauri desktop modes
  • Implements caching and error handling
• Frontend: Updated TextInputWithFont component to use system fonts instead of hardcoded list
• Frontend: Updated TypeSignatureText component to use system fonts with refresh button

Why This Change

Users were limited to hardcoded font lists (5 fonts) when annotating PDFs or creating signatures. This prevented them from using their system-installed fonts, reducing usability and functionality.

Challenges Encountered

1. Tauri vs Web Mode: Had to detect application mode and route API calls appropriately
2. Thread Safety: Font service runs in multi-threaded Spring context; implemented caching strategy
3. Cross-Platform: Font directories differ across Windows/Linux/macOS; implemented platform-specific paths
4. OTF/TTC Support: Java's Font.createFont() has limited format support; added fallback filename extraction

Testing

• ✅ Backend API tested with Postman: Returns 200 OK with font list (50+ fonts on Windows)
• ✅ Fonts endpoint is accessible without authentication
• ✅ Frontend hook successfully fetches and displays fonts
• ✅ Both web and Tauri modes work correctly
• ✅ Font refresh endpoint clears cache and repopulates successfully

Closes #5479

---

Checklist

General

• I have read the Contribution Guidelines
• I have read the Stirling-PDF Developer Guide
• I have performed a self-review of my own code
• My changes generate no new warnings

Documentation

• I have updated relevant docs on Stirling-PDF's doc repo (not needed - feature is self-explanatory)
• I have read the section Add New Translation Tags (no new translation tags added)

Translations (if applicable)

• I ran scripts/counter_translation.py (no new translation keys)

UI Changes (if applicable)

• Font selection dropdown now shows system fonts instead of hardcoded list

Testing (if applicable)

• I have tested my changes locally
• Backend: curl http://localhost:8080/api/v1/general/fonts returns 200 OK with full font list
• Frontend: Font dropdown populates correctly with system fonts
• Tauri and web modes both work correctly

Screenshot for Reference

[Frooodle]

Why would we want to add the fonts to auth exclusion? Only logged in users should need to access these endpoints

Edit: Great feature idea btw appreciate you making this!

[SakShamJain8]

Why would we want to add the fonts to auth exclusion? Only logged in users should need to access these endpoints

Edit: Great feature idea btw appreciate you making this!

The fonts endpoint could benefit from being public because:

1.. No Security Risk -> Font names alone won't expose sensitive data like file paths, user info, system details etc.
2. Performance -> Reduces unnecessary round-trips, It will query fonts once only when compared to after every login
3. UX Flow -> In desktop mode, we could show font previews before login

However, I understand the security-first approach. Should I move it back to authenticated-only?"