Alpine images missing fontconfig

[gdams]

Alpine images need the following command added:

RUN apk add --no-cache fontconfig
RUN ln -s /usr/lib/libfontconfig.so.1 /usr/lib/libfontconfig.so && \
    ln -s /lib/libuuid.so.1 /usr/lib/libuuid.so.1 && \
    ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1
ENV LD_LIBRARY_PATH /usr/lib

As discussed in #75

[aahlenst]

@gdams I've not seen the need to symlink libraries in the past on Alpine to get the font support working. Considering how old the linked issue is, ...

[ReillyTevera]

We've left that workaround in our images ever since we encountered that issue. I'll test it over the next few weeks and see if it's still necessary with the newest Docker images.

[karianna]

We've left that workaround in our images ever since we encountered that issue. I'll test it over the next few weeks and see if it's still necessary with the newest Docker images.

@ReillyTevera any luck?

[DRoppelt]

@karianna I am not OP, but I am also facing issues that were resolved with a workaround mentioned here #75 (comment)

demo-gh529.zip

I have attached a testframe based on spring-boot (1:1 off of https://start.spring.io/), where I added some code that tries to load an Arial.tff which I have copied from my W10 machine. I assume that it is OPs issue as well.

Strangely enough, we dont face this issue with a build from abot 2020-10-* (but I need to refine that from my side, I have no luck reproducing it when pulling the same tag)

It is self-contained and only requires this call for testing:

docker build . -t alpinefontconfig && docker run alpinefontconfig -it

Where this Dockerfile will produce a running application:

FROM adoptopenjdk/openjdk15:alpine as builder
WORKDIR /workspace/app

COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src

RUN chmod +x mvnw && ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)

FROM adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.10_9

# this comment also adds symlinks + ENV instruction, but this also seems to do the trick
# https://github.com/AdoptOpenJDK/openjdk-docker/issues/75#issuecomment-638496817
RUN apk add --no-cache fontconfig ttf-dejavu

VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
RUN mkdir /app
COPY --from=builder ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=builder ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=builder ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.demo.DemoApplication"]

Output:

C:\Users\ddrop\Downloads\demo-gh529\demo
λ docker build . -t alpinefontconfig && docker run alpinefontconfig -it
...
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.4)

2021-03-31 16:47:17.466  INFO 1 --- [           main] com.example.demo.DemoApplication         : Starting DemoApplication using Java 11.0.10 on 6a5c07b0b8e5 with PID 1 (/app started by root in /)
2021-03-31 16:47:17.468  INFO 1 --- [           main] com.example.demo.DemoApplication         : No active profile set, falling back to default profiles: default
2021-03-31 16:47:17.939  INFO 1 --- [           main] com.example.demo.DemoApplication         : Started DemoApplication in 0.752 seconds (JVM running for 0.993)

Whereas commenting out

# RUN apk add --no-cache fontconfig ttf-dejavu

Leads to

λ docker build . -t alpinefontconfig && docker run alpinefontconfig -it
...
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.4.4)

2021-03-31 16:51:04.375  INFO 1 --- [           main] com.example.demo.DemoApplication         : Starting DemoApplication using Java 11.0.10 on 52fa05aed023 with PID 1 (/app started by root in /)
2021-03-31 16:51:04.377  INFO 1 --- [           main] com.example.demo.DemoApplication         : No active profile set, falling back to default profiles: default
2021-03-31 16:51:04.677  WARN 1 --- [           main] s.c.a.AnnotationConfigApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'fontManager': Invocation of init method failed; nested exception is java.io.IOException: Problem reading font data.
2021-03-31 16:51:04.683  INFO 1 --- [           main] ConditionEvaluationReportLoggingListener :

Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2021-03-31 16:51:04.707 ERROR 1 --- [           main] o.s.boot.SpringApplication               : Application run failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'fontManager': Invocation of init method failed; nested exception is java.io.IOException: Problem reading font data.
        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:160) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:422) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1778) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:602) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:944) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) ~[spring-context-5.3.5.jar:5.3.5]
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583) ~[spring-context-5.3.5.jar:5.3.5]
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:769) ~[spring-boot-2.4.4.jar:2.4.4]
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:761) ~[spring-boot-2.4.4.jar:2.4.4]
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:426) ~[spring-boot-2.4.4.jar:2.4.4]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:326) ~[spring-boot-2.4.4.jar:2.4.4]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1313) ~[spring-boot-2.4.4.jar:2.4.4]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1302) ~[spring-boot-2.4.4.jar:2.4.4]
        at com.example.demo.DemoApplication.main(DemoApplication.java:10) ~[app/:na]
Caused by: java.io.IOException: Problem reading font data.
        at java.desktop/java.awt.Font.createFont0(Unknown Source) ~[na:na]
        at java.desktop/java.awt.Font.createFont(Unknown Source) ~[na:na]
        at com.example.demo.FontManager.postConstruct(FontManager.java:23) ~[app/:na]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[na:na]
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:na]
        at java.base/java.lang.reflect.Method.invoke(Unknown Source) ~[na:na]
        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:389) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:333) ~[spring-beans-5.3.5.jar:5.3.5]
        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:157) ~[spring-beans-5.3.5.jar:5.3.5]
        ... 18 common frames omitted

[DRoppelt]

Strangely enough, we dont face this issue with a build from abot 2020-10-* (but I need to refine that from my side, I have no luck reproducing it when pulling the same tag)

I was now able to reproduce this as well, here is another testframe

demo-gh529-fontConfigProperties.zip

When copying fontconfig.properties to /opt/java/openjdk/lib/ .

version=1
sequence.allfonts=alphabetic/default,dingbats,symbol

The issue does NOT appear without fontconfig (so vanilla image without apk add...) for these two tags:

FROM adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.9_11
FROM adoptopenjdk/openjdk11-openj9:x86_64-alpine-jre-11.0.9_11_openj9-0.23.0

While it breaks with these (and newer images as well)

FROM adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.10_9
FROM adoptopenjdk/openjdk11-openj9:x86_64-alpine-jre-11.0.10_9_openj9-0.24.0

Also interesting: with that font-config file, ttf-dejavu is also not necessary anymore, and only following is needed (at least for that test with spring-boot)

RUN apk add --no-cache fontconfig

[aahlenst]

Please all forget past experiences. A lot has changed since then, most recently in January. Everything from before then is moot.

We unbundled Freetype with the January 2021 updates. Since then, you have to bring your own copy. See https://blog.adoptopenjdk.net/2021/01/adoptopenjdk-8u282-11010-and-1502-available/ for the announcement. https://blog.adoptopenjdk.net/2021/01/prerequisites-for-font-support-in-adoptopenjdk/ lists what's necessary except for Alpine. But you can see the equivalent in https://github.com/AdoptOpenJDK/openjdk-infrastructure/blob/6265fbf2648bd495b1dff903af371897ca7f12e9/ansible/playbooks/AdoptOpenJDK_Unix_Playbook/roles/DockerStatic/Dockerfiles/Dockerfile.alp311#L4-L5.

One thing you have to pay attention to: If the JDK was built with glibc, you may not pull in the Alpine packages that are based on musl libc. Otherwise, you end up with the mess I described in #520 (comment).

[DRoppelt]

Ah okay, understood (I think).

Instead of being halfbaked (where some libs would still be missing), images are now blank regarding tools that would be needed for font processing?

One thing you have to pay attention to: If the JDK was built with glibc, you may not pull in the Alpine packages that are based on musl libc

IIRC, that musl/glibc incompatibility may occur for anything before jdk16? https://openjdk.java.net/jeps/386 , jdk16 builds and onward are based on musl. And this is not backported to e.g. 8/11, correct?

From my understanding, alpine images then need following libs that should be installed by the user, not provided generally?

RUN apk add --no-cache fontconfig ttf-dejavu

That seems to be the minimum, based on that article I used FontTest as following:

FontTest.java:

import java.awt.*;

public class FontTest {

    public static void main(String[] args) {
        String[] names = GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();

        System.out.println("Found " + names.length + " fonts:");

        for (String name : names) {
            System.out.println(name);
        }
    }
}

DockerFile:

FROM adoptopenjdk/openjdk11:alpine as builder
WORKDIR /workspace/app

COPY FontTest.java .

RUN javac FontTest.java

FROM adoptopenjdk/openjdk11:jre-11.0.10_9-alpine
RUN apk add --no-cache fontconfig ttf-dejavu

COPY --from=builder /workspace/app/FontTest.class .

ENTRYPOINT ["java","FontTest"]

Output:

λ docker build . -t alpinefontconfig && docker run alpinefontconfig -it
...
Found 18 fonts:
DejaVu LGC Sans
DejaVu LGC Sans Condensed
DejaVu LGC Sans Light
DejaVu LGC Sans Mono
DejaVu LGC Serif
DejaVu LGC Serif Condensed
DejaVu Math TeX Gyre
DejaVu Sans
DejaVu Sans Condensed
DejaVu Sans Light
DejaVu Sans Mono
DejaVu Serif
DejaVu Serif Condensed
Dialog
DialogInput
Monospaced
SansSerif
Serif

[aahlenst]

Instead of being halfbaked (where some libs would still be missing), images are now blank regarding tools that would be needed for font processing?

From my POV, container images should bring everything needed to run a Java application. This includes freetype, fontconfig, and a couple of fonts. Any image should install libxrender, libxi, libxtst, alsa-lib, libx11, fontconfig, libxext, freetype, zlib, ttf-dejavu.

IIRC, that musl/glibc incompatibility may occur for anything before jdk16?

At the moment, yes.

jdk16 builds and onward are based on musl.

We have tarballs for musl. Ready-made container images are still based on glibc, for some reason.

And this is not backported to e.g. 8/11, correct?

8 is unlikely, 11 might be possible, but I'm not aware of any effort to backport JEP 386 to 11.

[DRoppelt]

From my POV, container images should bring everything needed to run a Java application... Any image should install ...

Would that also include ready-made images? So future builds would have these libs installed?