Adding CJK rendering

[peterspicer-catalyst]

We have a client that has docx files with Chinese in, which don't render correctly when converted to PDF.

What I've done thus far is 'encourage' the bundled LO instance to have some CJK fonts since I couldn't see how to otherwise install them via yum in the built result.

So, I manually dismantled the lo.tar.xz file, added the .ttf files from ftp://ftp.gnu.org/non-gnu/chinese-fonts-truetype/ into instdir/share/fonts/truetype (once gunzipped) and rebuilt lo.tar.xz and this seems to work for now.

Other things:

• The fonts look slightly fancier and have different hinting rules than students might be expecting, though for a lot of cases it won't matter too much.
• I couldn't figure out how to use OpenType fonts (e.g. Noto Sans) with this; LO has a list of folders it goes through and I couldn't see how to write to any of them, short of mangling the result container to have a font directory in /tmp, and then mangle all the other system fonts to be there too... there probably is something more elegant for this - note that Noto ships all the main font families as TTF, except for the CJK fonts which only ship as OTF.
• I haven't attempted Arabic but I imagine something similar will be the case there.

It'd be nice to get CJK rendering supported, either by default or as a configurable rather than what I've got here, but this does seem to work.

[mattporritt]

Hi @peterspicer-catalyst ,
Thanks heaps for looking into this. To save some research time, do you have a list of places where LO looks for fonts?
I'm, fairly sure one of the main ones is /usr/share/fonts but I need to confirm that.
What we'll likely need to do is find a match between where LO looks for fonts and the locations we have access to inside the Lambda env. Then as part of the Lambda bootstrapping process copy the fonts into that location.
Another avenue of investigation would be to see if we can define a font location as part of the LO command line.

Either way once we figure out where and how the fonts need to be we can update the Lambda side to make those available to the binary.

Cheers,
Matt P

[peterspicer-catalyst]

So LO checks <Libre>/share/fonts/truetype for TTFs (only; the equivalent ../opentype folder is completely ignored as are non-TTFs in the truetype folder), and as far as I can tell it uses all the 'standard system locations' for fonts otherwise for CentOS (which is what Amazon Linux is seemingly based on), it looks like:

• /home/$USER/.fonts (deprecated in Ubuntu, doesn't seem to be deprecated in CentOS)
• /usr/share/fonts/
• /usr/local/share/fonts

You can always list out /etc/fonts/fonts.conf to see where the system paths are for sure, I haven't had chance to fire up a Lambda instance myself to examine it yet.

It should be possible to use fc-cache to specify a new folder but all the information I've seen so far suggests you'd need sudo or similar privileges; again haven't tried it yet.

Also, finding out this information on any consistent basis seems unnecessarily hard!