Windows Support Feasibility Analysis

[kyamagu]

Windows Support Feasibility Analysis

This issue documents the feasibility and requirements for adding Windows platform support to fontconfig-py.

Summary

Verdict: Technically feasible but requires 1-2 weeks of focused work

Both core dependencies (FreeType and fontconfig) support Windows builds, making this realistic to implement. However, the limited use case and maintenance burden suggest waiting for actual user demand before investing effort.

Current State

• Supported platforms: Linux and macOS only
• Build system: Bash script using autotools
• CI/CD: GitHub Actions with Ubuntu and macOS runners
• No existing Windows-related issues or PRs (as of Dec 2024)

Technical Feasibility ✅

Dependencies Status

FreeType - ✅ Excellent Windows support

• Native CMake support (CMakeLists.txt present in submodule)
• Ships with Visual Studio project files
• Available through vcpkg
• Static linking is the default
• Well-documented Windows builds

Fontconfig - ⚠️ Possible but challenging

• Modern Meson build system (found in submodule)
• vcpkg provides Windows support (v2.15.0, Dec 2024)
• Some community MSVC patches exist
• Not officially Windows-native but builds successfully via vcpkg/Meson

Other dependencies (from setup.py):

• expat: ✅ Available via vcpkg
• zlib: ✅ Built into Windows or vcpkg

Recommended Implementation Approach

Option 1: vcpkg + cibuildwheel (Recommended)

Add Windows to CI matrix and use vcpkg for dependency management:

# In .github/workflows/wheels.yaml
strategy:
  matrix:
    os: [ubuntu-latest, ubuntu-24.04-arm, macOS-latest, windows-latest]

# Add Windows-specific configuration:
CIBW_BEFORE_ALL_WINDOWS: |
  vcpkg install fontconfig:x64-windows-static freetype:x64-windows-static expat:x64-windows-static

Advantages:

• vcpkg handles all dependency complexity
• Static linking is straightforward
• Works with cibuildwheel
• Battle-tested by other projects

Challenges:

• Configure library paths for setup.py
• Platform-specific compilation flags
• vcpkg installation time in CI

Option 2: Build from source with Meson

• Use Meson to build both freetype and fontconfig
• More control but more complexity
• Would need PowerShell equivalent of build_third_party.sh

Implementation Challenges

1. Build Infrastructure (Medium difficulty)

• Add Windows runners to GitHub Actions
• Write PowerShell/batch build scripts (or Windows-compatible build_third_party script)
• Configure MSVC toolchain
• Handle library paths (Windows doesn't have /usr/local/lib)

2. Dependencies (Low-Medium difficulty)

All dependencies are available, but need proper configuration:

• Path configuration for Windows library locations
• Linking static libraries with MSVC conventions
• Handling .lib vs .a file extensions

3. Runtime Considerations (Low difficulty)

• fontconfig needs font configuration paths (different on Windows)
• Windows uses different font system (GDI, DirectWrite)
• May need Windows-specific config file locations (C:\Windows\Fonts, etc.)
• Font paths and configurations differ from Unix systems

4. Testing (Medium difficulty)

• Font availability differs across platforms
• System font paths are different
• Need Windows-specific test fixtures
• Existing tests may fail due to missing fonts (e.g., Arial)

Effort Estimation

Task	Difficulty	Estimated Time
vcpkg integration	Medium	1-2 days
Windows CI setup	Easy	0.5 day
setup.py modifications	Medium	1 day
Testing & debugging	High	2-3 days
Documentation	Easy	0.5 day
Total	Medium-High	5-7 days

Important Considerations

Limited Use Case ⚠️

• Windows has native font APIs (DirectWrite, GDI)
• Most Windows applications don't use fontconfig
• Other Python fontconfig bindings don't support Windows (e.g., Python-fontconfig is POSIX/macOS only)
• Primary users would be:
  • Cross-platform tools needing consistent font handling
  • Linux developers working on Windows
  • WSL-style environments

Maintenance Burden

• Additional CI costs (Windows runners are more expensive)
• Platform-specific bug reports
• Keeping up with Windows toolchain changes
• More complex troubleshooting and support

User Demand

• No existing GitHub issues requesting Windows support
• No community PRs attempting it
• No mentions in discussions
• This suggests low current demand

Recommendation

Should We Implement Windows Support?

✅ YES IF:

• Users explicitly request it
• There's demonstrated need from the community
• Project wants to be the most complete Python fontconfig binding

❌ NO IF:

• It's purely speculative
• No user demand exists
• Limited resources/time available

🤔 MAYBE IF:

• Want to explore Windows compatibility
• Willing to maintain experimental support
• Have time for a technical challenge

Minimal Viable Approach

If proceeding, start with:

1. Add Windows to CI matrix (experimental)
2. Use vcpkg for all dependencies
3. Conditionally compile on Windows with minimal changes
4. Document as "experimental Windows support"
5. Iterate based on user feedback
6. Don't promise full feature parity initially

Alternative: Wait and See

Given the lack of user demand:

• Keep this issue open for future reference
• Wait for users to request Windows support
• Link this analysis when questions arise
• Revisit if multiple users express interest

References

• vcpkg fontconfig package (v2.15.0)
• vcpkg freetype package
• Building FreeType on Windows
• cibuildwheel Windows C extensions
• fontconfig with MSVC support
• Building Custom Python Wheels with C Extensions
• Python-fontconfig PyPI (POSIX/macOS only)
• Gramps discussion on building fontconfig on Windows with MSYS2

Next Steps

If you decide to proceed:

1. Set up vcpkg in CI for Windows
2. Create Windows-specific build script
3. Modify setup.py for Windows library paths
4. Add Windows test configuration
5. Update documentation
6. Test on actual Windows systems
7. Release as experimental feature

---

Analysis Date: December 2024
Conclusion: Feasible but not recommended without user demand