Support custom fonts from Android res/font resources

[Zellius]

Related issue: #786

Android allows resources to be provided using either the res or assets folders. Classic Android apps provide most resources, such as images, strings, and fonts, using res making them easy to use in XML layouts, views, and composables.

Currently, Readium allows custom fonts to be provided only through the assets folder. This means apps need to store the same font in both res and assets to use it in XML and in Readium.

This PR removes that limitation and allows the font family to be specified using either a single font file or an Android XML font family.

Summary

• Add support for using Android res/font resources as Readium font families in the EPUB navigator.
• Support both single font files (.ttf/.otf) and XML font family resources (res/font/*.xml) when building @font-face declarations.

Changes

Core navigator support

• Added Android resource URL mapping helper to generate WebView compatible resource paths:
  • readium/navigator/src/main/java/org/readium/r2/navigator/epub/resources/ResourcePaths.kt
• Added font resource parsing utilities:
  • Parse XML definitions and direct font files
  • Extract weight/style metadata per font variant
  • readium/navigator/src/main/java/org/readium/r2/navigator/epub/resources/ResourceFontFamily.kt
• Added configuration extension to register a FontFamily from Android font resources:
  • Configuration.addFontFamilyDeclaration(...)
  • readium/navigator/src/main/java/org/readium/r2/navigator/epub/resources/FontFamilyDeclarations.kt

WebView serving updates

• Updated EPUB WebView server asset loading to include Android resources under a dedicated path prefix.

[qnga]

Hi !
Thanks for you PR. Could you rebase your work on develop? I fixed the CORS issue separately as it was urgent. I understand the need for supporting Android resources, I've had the same duplication issue with Compose resources in some app. I'm more on the fence regarding the Android XML fonts as we have our own system to build font families. Why would we need this?

[Zellius]

@qnga Hey! :)

Could you rebase your work on develop?

Sure! Thanks for fixing the issue.

Why would we need this?

I agree that Readium already has a good system to build font families through addFontFamilyDeclaration.

In our app Android XML font family resources are the source of truth. We use them across XML layouts and Compose. The app is white-label, with 100+ flavors, and each flavor can override resources such as strings, colors, font families, etc.

This follows Android’s built in approach for defining font families in resources, as described here. The XML file groups the font files together with their style and weight details, and exposes them as a single font resource.

Without XML font family support in Readium we need to duplicate the same font family definition in EpubNavigatorFragment.Configuration. Every font file, weight and style must be declared again manually with addFontFamilyDeclaration. This creates two sources of truth:

1. Android res/font/*.xml, used by the rest of the app.
2. Readium font declarations, maintained separately for the EPUB navigator.

Our app could parse these XML files itself and convert them to Readium declarations but then every app with the same need would have to implement its own parser/bridge. Since this is a standard Android resource format and maps directly to Readium’s existing @font-face declarations it seems useful to support it in Readium itself.

This PR does not replace Readium’s font family system. It only adds a bridge from Android res/font resources to Readium’s existing @font-face declaration system, so apps can reuse an existing R.font.some_family without duplicating its XML contents in Kotlin.