CollaboraOnline
Custom Font Support on Android
📝 Is your feature request related to a problem?
When editing a document on the Android app that uses a non-standard or custom font, the font is not displayed or used correctly. This forces the application to substitute the font, which breaks the document's fidelity, layout, and professional appearance on mobile devices. Because of Android security, I cannot install the font system-wide without rooting the device. Because the Collabora app does not look in user-accessible storage for fonts, I am forced to use a desktop computer to view or edit the document accurately, making the mobile app less useful for critical work.
💡 Describe the solution you'd like
I would like the Collabora Office Android application to have the capability to read and use font files (.ttf, .otf) placed in a designated, user-accessible folder on the Android device's storage. This could be implemented by:
- Checking a specific, designated folder (e.g., /Android/data/com.collabora.office/files/Fonts/ or /storage/Fonts or a user-selected folder via the Android file picker).
- Scanning for all valid font files (.ttf, .otf) in that folder upon app launch.
- Adding these fonts to the application's font cache for display and editing within documents. When editing the document, I should be able to see and select the custom font from the font dropdown list.
🔄 Describe alternatives you've considered
- Embedding the Font: This works for viewing but requires using the desktop version (LibreOffice/Collabora Office) to embed the font initially, which is inconvenient for quick mobile-first document creation.
- Rooting the Device: This is not a viable solution for most users due to security risks and complexity.
- Third-party Apps (e.g., WPS Office): Competitor office suites (like WPS Office) offer this exact functionality by simply allowing the user to drop TTF files into a designated folder, confirming that a user-space solution is technically feasible on Android.
➕ Additional context
- This feature is critical for professional use-cases where branding, layout, or legal requirements dictate the use of a specific, non-standard font.
- The implementation should respect Android's modern storage access rules (Scoped Storage) to avoid privacy and security issues. Using the File Picker API once to grant access to a "Fonts" folder, or using an app-specific folder, are potential approaches.
- This would significantly improve the mobile app's interoperability and feature parity with proprietary office solutions.
Hi I’d like to work on this issue. I’ve already set up the build environment and started exploring how the font loading works on Android. Could you please assign this issue to me?
Hi I’d like to work on this issue. I’ve already set up the build environment and started exploring how the font loading works on Android. Could you please assign this issue to me?
That is fantastic news! Thank you for offering to work on this important feature. I am subscribing to the issue and look forward to testing it once it's available. This will be a huge benefit for all users who need to maintain document fidelity with custom fonts on mobile.
@ANANYA542 thanks very much for looking at this, I've assigned you the issue!
I am the main person maintaining the Android app code so please feel free to ping me if you want any help/pointers/etc. or when you would like review :)
@Minion3665 Hi, since the issue is assigned to me, I wanted to share a quick update on my approach. What I’ve looked into so far: -How the Android app currently loads its default fonts and generates the font cache. -Android’s Scoped Storage rules and how apps can access user-selected folders. -How other Android apps load .ttf and .otf fonts without requiring root access. My plan: -Decide whether to use an app-specific folder or a user-selected folder for storing custom fonts. -Add a step during app launch to scan that folder for font files. -Load the detected fonts into the existing font cache so they appear in the font dropdown. -Test font rendering to confirm that documents display correctly with custom fonts. If there are specific parts of the Android codebase that you think I should focus on, I would appreciate any guidance. I will continue sharing updates as I make progress.
Thank you again for the detailed update, @ANANYA542!
Regarding your first planning point on the folder location, I strongly prefer the user-selected folder option, specifically allowing the app to read from a standard, easy-to-access location like /storage/Fonts (or similar root-level folder) if technically feasible.
My reasoning is that this simple, shared location greatly enhances the user experience, as seen in other office suites. If the user must manually select a folder, having one easily recognizable like 'Fonts' at the storage root is far more intuitive than navigating deep into an app-specific directory.
I understand this might require specific implementation around Android's Scoped Storage rules, but the usability benefit for users who manage many font files would be substantial.
Looking forward to your next update!
@jahedcuet Thanks for the feedback. I’ll look into whether the app can access a user-selected folder like /storage/Fonts through the Storage Access Framework and whether this works under Scoped Storage. I’ll test scanning that folder for font files and compare it with the app-specific folder option if needed. I’ll update you soon once I’ve checked feasibility.
If there are specific parts of the Android codebase that you think I should focus on, I would appreciate any guidance.
My guess is that this'll be tied to the native code, since as we use LibreOffice Kit to render documents (including the fonts...)
https://sdk.collaboraonline.com/docs/installation/Fonts.html -> here's how Collabora fonts are installed on the Collabora Online server ... I guess that probably Kit picks them up from system fonts normally, but I haven't looked directly at fonts before so I wouldn't be completely sure
Your plan sounds reasonable to me, but I guess that
-Load the detected fonts into the existing font cache so they appear in the font dropdown. -Test font rendering to confirm that documents display correctly with custom fonts.
These steps probably touch the native parts and will be less straightforward than they first sound
Forgive me, but I would like to make some suggestions about fonts.
Here are some very old fonts, which I would personally remove completely or replace. For example:
- Linux Libertine/Biolinum G: dates back to 2012, but it is now surpassed by the official Libertine or by Libertinus
- Gentium: in reality it is Gentium Basic or, I don't remember well, Gentium Plus, but look at the current state here
Maybe the better solution is to remove these fonts and make the application lighter and allow loading fonts from an external folder, although I don't know how much this is applicable in the case of the online version.
@Doc73 The "G" in Linux Libertine/Biolinum means the graphite extension, and I'm not sure that newer versions in upstream have it. Maybe you are right about Gentium.
@ANANYA542 If you can make sure that user fonts are in a certain folder on Android, you can add that directory to fontconfig configuration, and LOKit will found it. For example on macOS it is ~/Library/Fonts, on Windows it is WINDOWSUSERFONTDIR.
