Unsolved Adding fonts to NextCloud + Collabora

[SirFiChi]

Hey folks,

is there a way to add some fonts to the nextcloud installation, so we can use them with collabora documents?
It's a very uncomfortable workflow to download all files and to correct the layout when the documents have to be printed or converted as pdf files.

Thanks for your help

Floh K.

[girish]

@SirFiChi If you have a list of missing fonts, we can add it to the collabora package.

[murgero]

@girish I think a better option would be to move, then symlink the fonts dir in the package so it can be modified freely.

in the Dockerfile file, just add this somewhere:

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

Then users will be able to add their fonts as needed

[girish]

@murgero I don't mind doing that as well. I need to look closely into how collabora works though. I wonder if it relies on client/browser fonts or fonts on the server side. Because currently the docker image basically has no fonts installed and somehow it seems to mostly work.

[girish]

There's some instructions here - https://help.nextcloud.com/t/installing-new-fonts-in-collabora/22758/3 . Maybe @nebulon has an idea.

[murgero]

@girish If it's anything like openoffice, like I believe it is - it's the server's font dir, not the clients.

[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...