Adding fonts to NextCloud + Collabora

[SirFiChi]

I also found this site and tried to write into /usr/share/fonts/truetype/, but as you know, the docker-containers are ro.
The solution of @murgero sounds great.

I think about another solution so you can add fonts directly in the nextcloud.
What about adding a dircetory there:
/app/data/admin/files/Fonts

So the admin can add fonts.
But we need a chown, chmod and a trigger for fc-cache?

[girish]

Opened https://git.cloudron.io/cloudron/collabora-app/-/issues/5 to investigate further

[sk93]

Any updates on this topic?

[nebulon]

@sk93 thanks for bringing this up again. By now we are in contact with the Collabora team for providing also a package of their production suite. I assume we will tackle this font issue with them then for both packages.

[sk93]

@nebulon nice, thanks for the update! Is there any eta planned?

[nebulon]

@sk93 no eta yet, but regarding the font issue, I will bring this up as soon as we can talk directly to their tech support to figure a good and future proof way to deal with this.

[avatar1024]

@nebulon said in Adding fonts to NextCloud + Collabora:

By now we are in contact with the Collabora team for providing also a package of their production suite.

That sounds brilliant!

[m-si]

I'am doing this first time, so foregive me mistakes I do. I went into the folder structure of the collabara_code install. To me it' obviously picking up fonts at both locations:

• at /opt/collaboraoffice/share/fonts/truetype and
• at /usr/share/fonts/

as it is disirable for some users to get rid of the preinstalled fonts we need to:

RUN mv /opt/collaboraoffice/share/fonts/ /app/data/fonts/ && ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/

right after...

ARG CODE_BRAND_VERSION=21.11-17

in the dockerfile. So users can adjust the fonts to their needs...

[nebulon]

@m-si on Cloudron all app images are immutable so in this case, unless we would remove fonts for all this would require a special app package. Your solution would work, however this would also mean the fonts will be part of the backup then and newer fonts in new upstream releases have to somehow be merged into the adjusted ones.

[m-si]

@nebulon That's definitly true...so my second best guess would be to:

RUN mv /usr/share/fonts/ /app/data/fonts/ && ln -s /app/data/fonts /usr/share/fonts/

As it seems that coolwsd is looking up there and at

etc/fonts

as well according to my understanding of https://github.com/pree/collabora-online/blob/master/coolwsd-systemplate-setup

isn't it that what usr fonts are meant to be? And we won't interfere with the collabra ones. Of course the user added fonts would be part of backup, but this shouldn't be that much of a deal (in my opinion)... But with that approach we can't get rid of the initally installed noto fonts for instance...

Edit: I see that that is exactly what murgero wrote at the very beginning so +1 for @murgero

[m-si]

I played around and maybe this is a solution to @nebulon at least for the "merge"-situation with new upstream font releases...so what about:

RUN if [ -d /app/data/fonts/ ]; then \
      rsync -a --update --existing /opt/collaboraoffice/share/fonts/ /app/data/fonts/  \
      && rm -r /opt/collaboraoffice/share/fonts/ \
    else \
      mv /opt/collaboraoffice/share/fonts/ /app/data/fonts/ \
    fi \
    && ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/

With that it checks initaly wether /app/data/fonts/ exists (if not simply moves and symlinks back) and if folder already exits updates only the files that are newer and persists the deletion of font files in /app/data/fonts/ and keep changes of files from upstream (until they are deleted)...

[nebulon]

@m-si wouldn't that also copy back your delete fonts on an app restart?

[m-si]

@nebulon no this is prevented by the --existing flag...that's the reason why I initially suggest to move the whole thing and afterwords only update the (still) existing... to get a whole copy of the primary folder one has to delete the font folder in app/data... then there will be again the full copy/move...

[m-si]

@nebulon Another try hopefully less hackish... According to the solution of rLoutrel found here ... maybe it is sufficient to simply:

RUN ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/truetype/local

This one won't add /usr/share/fonts/ as extra volume to collabora and we won' have the ability to get rid of the intially installed fonts but should make it at least possible to add custom fonts via /app/data/fonts. So this might be a solution to the initial Question of SirFiChi...

[marcusquinn]

Any chance of another look at this please @nebulon — these little things really help with user happiness, and the latest version is well worth the effort for making out go-to online office suite with Nextcloud.

[m-si]

@nebulon I see there is always a lot to do, so maybe it's an idea to mention it again. Do you think we might have a chance to add fonts like that…?

RUN ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/truetype/local

[nebulon]

Thanks for bringing this up again. I have published a new app package which supports adding fonts now. After copying the TTF fonts into the folder, the app has to be restarted as mentioned in https://docs.cloudron.io/apps/collabora/#adding-fonts

[BrutalBirdie]

@nebulon
For some reason all the fonts I added like that show in in Collabora in Nextcloud but are invisible.

Ever encountered something like that?

[nebulon]

@BrutalBirdie what does invisible mean? Where are they invisible? Does fc-match <fontname> correctly recognize the font in the webterminal?

[BrutalBirdie]

@nebulon

root@7cca863b-c650-4447-9dba-c4653dafe333:/app/code# fc-match "Droid Sans"
DejaVuSans.ttf: "DejaVu Sans" "Book"

Looks wrong to me...

root@7cca863b-c650-4447-9dba-c4653dafe333:/app/code# ls -lah /app/data/
total 20K
drwxr-xr-x 3 root     root 4.0K Aug 21 21:00 .
drwxr-xr-x 1 root     root 4.0K Sep 19 21:01 ..
-rw-r--r-- 1 cloudron root 7.0K Oct 10 12:17 coolwsd.xml
drwxr-xr-x 6 root     root 4.0K Oct 10 14:00 fonts
root@7cca863b-c650-4447-9dba-c4653dafe333:/app/code# ls -lah /app/data/fonts/
total 24K
drwxr-xr-x 6 root root 4.0K Oct 10 14:00 .
drwxr-xr-x 3 root root 4.0K Aug 21 21:00 ..
drwxr-xr-x 2 root root 4.0K Oct 10 14:00 DroidSans
drwxr-xr-x 2 root root 4.0K Oct 10 14:00 DroidSerif
drwxr-xr-x 2 root root 4.0K Oct 10 14:00 NunitoSans
drwxr-xr-x 2 root root 4.0K Oct 10 14:00 OpenSans
root@7cca863b-c650-4447-9dba-c4653dafe333:/app/code# ls -lah /app/data/fonts/DroidSans/
total 96K
drwxr-xr-x 2 root root 4.0K Oct 10 14:00 .
drwxr-xr-x 6 root root 4.0K Oct 10 14:00 ..
-rw-r--r-- 1 root root  42K Oct  9 13:47 DroidSans-Bold.ttf
-rw-r--r-- 1 root root  41K Oct  9 13:47 DroidSans.ttf

root@7cca863b-c650-4447-9dba-c4653dafe333:/app/code# fc-match DroidSans 
DejaVuSans.ttf: "DejaVu Sans" "Book"

fc-match --all

Does also not include the fonts.
Also having the .ttf files plain in no sub folder in /app/data/fonts yields the same results.

The fonts works tho on the local system.