public inbox for perfbook@vger.kernel.org
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: "Leonardo Brás" <leobras.c@gmail.com>
Cc: perfbook@vger.kernel.org, "Paul E. McKenney" <paulmck@kernel.org>,
	Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH -perfbook 0/6] Update Dockerfiles
Date: Fri, 16 Jun 2023 20:05:02 +0900	[thread overview]
Message-ID: <fece6e8f-4e1d-de11-a082-b80eebb28c66@gmail.com> (raw)
In-Reply-To: <170675ed7b1b5d86cc9ebac30f05a03c9677ba92.camel@gmail.com>

On 2023/06/16 15:07, Leonardo Brás wrote:
> On Thu, 2023-06-15 at 19:43 +0900, Akira Yokosawa wrote:
>> [+To: Leo]
>>
>> On 2023/06/15 18:48, Akira Yokosawa wrote:
>>> Hi Paul,
>>>
>>> Commit a80a57b21a5e ("fixsvgfonts.sh: Convert sans-serif into 'DejaVu Sans'")
>>> assumed that having "DejaVu Sans Mono" is sufficent for "DejaVu Sans".
>>>
>>> It turns out that docker/Dockerfile.fedora doesn't cover "DejaVu Sans".
>>> Fedora's dejavu-sans-mono-fonts package doesn't contain "DejaVu Sans Mono"!
>>> There is a meta package of the name dejavu-fonts-all which covers them
>>> both as well as dejavu-serif-fonts.
>>>
>>> It also turns out that Answer to #9 in FAQ-BUILD.txt saying:
>>>
>>>     As for Ubuntu and Fedora, packages listed in #5 should cover
>>>     all the font families needed.
>>>
>>> is wrong on the Fedora front.  DejaVu and Liberation fonts need
>>> font packages dejavu-fonts-all and liberation-fonts.
>>>
>>> Furthermore, Fedora 38 (released this April) has a regression of
>>> Inkscape where font markup is corrupted in SVG --> PDF conversion.
>>
>> Leo, just for you info, I see the same regression under Arch Linux.
> 
> Hello Akira, thanks for letting me know!
> 
>>
>> Pick a perfbook.pdf from your gitlab-ci build, and run:
>>
>>     pdffonts perfbook.pdf
>>
>> You will see something like (I don't know how the corrupted encoding
>> will work in your mailbox...):
>>
>> name                                 type              encoding         emb sub uni object ID
>> ------------------------------------ ----------------- ---------------- --- --- --- ---------
>> WGDPYX+LMMono8-Regular               Type 1            Custom           yes yes yes   1722  0
>> ULGKTM+TeXGyreTermesX-Regular        Type 1            Custom           yes yes yes   1725  0
>> OTFSIT+LMMono12-Regular              Type 1            Custom           yes yes yes   1726  0
>> IYVMBP+TeXGyreTermesX-Bold           Type 1            Custom           yes yes yes   1741  0
>> PSUFXP+TeXGyreTermes-Regular         Type 1            Custom           yes yes yes   1742  0
>> IMBSNT+NimbusRomNo9L-Regu-Slant_167  Type 1            Custom           yes yes yes   1929  0
>> NWEUXR+LMMonoLt10-Bold               Type 1            Custom           yes yes yes   2227  0
>> EOPMEH+LinBiolinumTI                 Type 1            Custom           yes yes yes   2673  0
>> UHVCIJ+LinBiolinumT                  Type 1            Custom           yes yes yes   2674  0
>> EOPMEH+LinBiolinumTI                 Type 1            Custom           yes yes yes   2677  0
>> OIRARM+LMMono10-Regular              Type 1            Custom           yes yes yes   2764  0
>> TLODOC+txsys                         Type 1            Builtin          yes yes yes   2828  0
>> UFJTMD+StandardSymL                  Type 1            Builtin          yes yes yes   2830  0
>> IGSKIX+NewTXMI5                      Type 1            Builtin          yes yes yes   2831  0
>> VVGNAR+TeXGyreTermesX-Italic         Type 1            Custom           yes yes yes   2921  0
>> YFRDMR+NimbusSanL-Regu               Type 1            Custom           yes yes no    2980  0
>> YFRDMR+NimbusSanL-Regu               Type 1            Custom           yes yes no    3012  0
>> JZAPTL+k湌顕                       CID Type 0C       Identity-H       yes yes yes   3038  0
>> XCILRI+i湌顕                       Type 1C           WinAnsi          yes yes yes   3039  0
>> CZRRGJ+=潌顕                       CID Type 0C       Identity-H       yes yes yes   3040  0
>> LAEXLB+o湌顕                       Type 1C           WinAnsi          yes yes yes   3041  0
>> WJVJMV+NimbusSans-Regular            Type 1C           Custom           yes yes no    3066  0
>> WGDQZH+NimbusSans-Regular            Type 1C           WinAnsi          yes yes no    3129  0
>> LSRNIT+NimbusSans-BoldItalic         Type 1C           WinAnsi          yes yes no    3130  0
>> WGDQZH+NimbusSans-Regular            Type 1C           WinAnsi          yes yes no    3159  0
>> LSRNIT+NimbusSans-BoldItalic         Type 1C           WinAnsi          yes yes no    3160  0
>> DEIMBC+j솛慕                       TrueType          WinAnsi          yes yes yes   3209  0
>> RWADWA+蛒ୖ                       TrueType          WinAnsi          yes yes yes   3238  0
>> HDCMTE+蛒ୖ                       TrueType          WinAnsi          yes yes yes   3239  0
>> JGKXJS+½���䕖                      Type 1C           WinAnsi          yes yes yes   3269  0
>> ANXDLC+Xۨ㝖                        TrueType          WinAnsi          yes yes yes   3320  0
>> RUPDBM+ѓ㡖                       Type 1C           WinAnsi          yes yes yes   3553  00
>> LWHAZS+秞煕                       Type 1C           WinAnsi          yes yes yes   3560  0
>> RQGRST+A绞煕                       TrueType          WinAnsi          yes yes yes   3561  0
>>
>> [...]
>>
>> Expected output is:
>>
>> name                                 type              encoding         emb sub uni object ID
>> ------------------------------------ ----------------- ---------------- --- --- --- ---------
>> WGDPYX+LMMono8-Regular               Type 1            Custom           yes yes yes   1722  0
>> ULGKTM+TeXGyreTermesX-Regular        Type 1            Custom           yes yes yes   1725  0
>> ICXLWS+LMMono12-Regular              Type 1            Custom           yes yes yes   1726  0
>> IYVMBP+TeXGyreTermesX-Bold           Type 1            Custom           yes yes yes   1741  0
>> PSUFXP+TeXGyreTermes-Regular         Type 1            Custom           yes yes yes   1742  0
>> IMBSNT+NimbusRomNo9L-Regu-Slant_167  Type 1            Custom           yes yes yes   1929  0
>> NUKNCC+LMMonoLt10-Bold               Type 1            Custom           yes yes yes   2227  0
>> EOPMEH+LinBiolinumTI                 Type 1            Custom           yes yes yes   2673  0
>> UHVCIJ+LinBiolinumT                  Type 1            Custom           yes yes yes   2674  0
>> EOPMEH+LinBiolinumTI                 Type 1            Custom           yes yes yes   2677  0
>> OIRARM+LMMono10-Regular              Type 1            Custom           yes yes yes   2764  0
>> TLODOC+txsys                         Type 1            Builtin          yes yes yes   2828  0
>> UFJTMD+StandardSymL                  Type 1            Builtin          yes yes yes   2830  0
>> IGSKIX+NewTXMI5                      Type 1            Builtin          yes yes yes   2831  0
>> VVGNAR+TeXGyreTermesX-Italic         Type 1            Custom           yes yes yes   2921  0
>> YFRDMR+NimbusSanL-Regu               Type 1            Custom           yes yes no    2980  0
>> YFRDMR+NimbusSanL-Regu               Type 1            Custom           yes yes no    3012  0
>> QNDHMI+NimbusSans-Regular            CID Type 0C       Identity-H       yes yes yes   3038  0
>> JKBTOX+NimbusSans-Regular            Type 1C           WinAnsi          yes yes yes   3039  0
>> BIKSFC+NimbusSans-Bold               CID Type 0C       Identity-H       yes yes yes   3040  0
>> XFXZKY+NimbusSans-Bold               Type 1C           WinAnsi          yes yes yes   3041  0
>> WJVJMV+NimbusSans-Regular            Type 1C           Custom           yes yes no    3066  0
>> WGDQZH+NimbusSans-Regular            Type 1C           WinAnsi          yes yes no    3129  0
>> LSRNIT+NimbusSans-BoldItalic         Type 1C           WinAnsi          yes yes no    3130  0
>> WGDQZH+NimbusSans-Regular            Type 1C           WinAnsi          yes yes no    3159  0
>> LSRNIT+NimbusSans-BoldItalic         Type 1C           WinAnsi          yes yes no    3160  0
>> KPAYFY+steelcitycomic                TrueType          WinAnsi          yes yes yes   3209  0
>> IGYOWD+steelcitycomic                TrueType          WinAnsi          yes yes yes   3238  0
>> LVRVOR+steelcitycomic                TrueType          WinAnsi          yes yes yes   3239  0
>> OCNFNQ+FreeMonoBold                  Type 1C           WinAnsi          yes yes yes   3269  0
>> DHHOAV+DejaVuSans                    TrueType          WinAnsi          yes yes yes   3320  0
>> RVTHEX+DejaVuSansMono-Bold           TrueType          WinAnsi          yes yes yes   3479  0
>> ODJFYL+FreeMonoBold                  Type 1C           WinAnsi          yes yes yes   3553  0
>> HAXSLA+URWGothic-DemiOblique         Type 1C           WinAnsi          yes yes yes   3560  0
>> [...]
>>
> 
> IIUC, the issue is the appearing of non-ascii chars in the output of pdffonts,
> is that correct?

Right.

> 
> Arch Linux provides two packages for DejaVu fonts:
> ttf-dejavu and ttf-dejavu-nerd, and both seem to provide DejaVu-Sans-mono
> 
> In this test, I install them both, just for the sake of trying to fix the issue:
> https://gitlab.com/linux-kernel/perfbook/-/jobs/4485677006
> 
> I also added pdffonts command in the end to make it easier to verify if
> everything is fine, which still outputs non-ascii names. 
> 
> When I grep for DejaVuSansMono I see them appearing in the output of the job,
> and also in a previous pdf I have downloaded.
> 
> I don't quite understand this, but maybe the issue is missing other fonts?
> 
> Please help me understand the issue.

As far as I see, there is no font problem on your side.
I think this is regression of Inkscape.

As a matter of fact, Inkscape packages on most rolling-release distros
are having a more annoying regression, random SIGSEGV when run from
CLI under Gnome desktop environment.

See: https://gitlab.com/inkscape/inkscape/-/issues/4177
     "glib2 2.76.0 breaks Command Line export"

This issue was opened back on January 24, 2023.
It was once believed to have been resolved with a fix in gtk3, but the
issue still remains after the fixed version of gtk3 reached Fedora 38.
 
For gitlab-ci, where there is no Gnome desktop involved, this issue
has never affected, but the font markup corruption has sneaked in
without being reported by anyone.

I happened to test Dockerfile.fedora (from fedora:38) and checked if
"DejaVu Sans" was used in Intel_Core2_arch-simplified.pdf as intended,
and failed to see the font markup.

So, I think there is nothing wrong in your gitlab-ci.yaml script.
You need to wait until the regression is fixed in the Arch Linux
Inkscape or its dependency.

I have no idea how long that would take, though.

Or you could switch the container to a fedora:37 or ubuntu:jammy
based one for the moment.

        Thanks, Akira

> 
> Best regards,
> Leo
> 
> 
> 
>>
>>         Thanks, Akira
>>
>>>
>>> So Deckerfile.fedora should stay with Fedora 37 for the moment.
>>>
>>> Quick search of upstream Inkscape's issue tracker didn't hit the
>>> font markup regression.  I'll open an issue there unless somebody
>>> else beats me to it.
>>>
>>> So, this patch set consists of the following
>>>
>>> Patch 1/6 adds check of "DejaVu Sans" as nice-to-have font.
>>>
>>> Patch 2/6 updates FAQ-BUILD.txt and Dockerfile.fedora for nice-to-have
>>> font packages.
>>>
>>> Patch 3/6 updates Dockerfile.fedora to stay with Fedora 37, using an ARG
>>> variable so that building from fedora:38 can be possible.
>>> It also adds popller-utils to check the font markup info in PDF properties.
>>>
>>> Patch 4/6 updates Dockerfile (from ubuntu) so that the default base
>>> image is the "latest" (jammy at the moment).  There is no reason to stick
>>> with focal (20.04).
>>>
>>> Patch 5/6 adds poppler-utils to Dockerfile (from ubuntu) to detect
>>> Inkscape regression early in case it actually sneaks in.
>>> (Note: Ubuntu 23.04 is safe at the moment.)
>>>
>>> Patch 6/6 changes the default uid:gid pair of container images built
>>> from Dockerfiles to 0:0, which is for rootless mode docker/podman.
>>> Repository at dockerhub for prebuilt images is changed to
>>> akiyks/perfbook-build, where the tags "latest" and "fedora" have
>>> uid:gid pair of 0:0.
>>>
>>>         Thanks, Akira
>>> --
>>> Akira Yokosawa (6):
>>>   Makefile: Add 'DejaVu Sans' to nice-to-have fonts
>>>   FAQ-BUILD: Update nice-to-have fonts for SVG figures
>>>   docker/Dockerfile.fedora: Stay with Fedora 37 for the moment
>>>   docker/Dockerfile: Use 'latest' as the default tag
>>>   docker/Dockerfile: Add poppler-utils package
>>>   Dockerfile: Make uid:gid = 0:0 the default
>>>
>>>  FAQ-BUILD.txt            | 37 ++++++++++++++++++++-----------------
>>>  Makefile                 | 15 ++++++++++++---
>>>  docker/Dockerfile        |  9 +++++----
>>>  docker/Dockerfile.fedora | 16 +++++++++++-----
>>>  4 files changed, 48 insertions(+), 29 deletions(-)
>>>
>>>
>>> base-commit: a80a57b21a5e8ea3dfa90471126920a1131682f7
> 

  reply	other threads:[~2023-06-16 11:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-15  9:48 [PATCH -perfbook 0/6] Update Dockerfiles Akira Yokosawa
2023-06-15  9:49 ` [PATCH -perfbook 1/6] Makefile: Add 'DejaVu Sans' to nice-to-have fonts Akira Yokosawa
2023-06-15  9:51 ` [PATCH -perfbook 2/6] FAQ-BUILD: Update nice-to-have fonts for SVG figures Akira Yokosawa
2023-06-15  9:52 ` [PATCH -perfbook 3/6] docker/Dockerfile.fedora: Stay with Fedora 37 for the moment Akira Yokosawa
2023-06-15  9:53 ` [PATCH -perfbook 4/6] docker/Dockerfile: Use 'latest' as the default tag Akira Yokosawa
2023-06-15  9:54 ` [PATCH -perfbook 5/6] docker/Dockerfile: Add poppler-utils package Akira Yokosawa
2023-06-15  9:56 ` [PATCH -perfbook 6/6] Dockerfile: Make uid:gid = 0:0 the default Akira Yokosawa
2023-06-15 10:43 ` [PATCH -perfbook 0/6] Update Dockerfiles Akira Yokosawa
2023-06-16  6:07   ` Leonardo Brás
2023-06-16 11:05     ` Akira Yokosawa [this message]
2023-09-22 23:52       ` Akira Yokosawa
2023-09-27  2:49         ` Leonardo Brás
2023-06-15 16:49 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fece6e8f-4e1d-de11-a082-b80eebb28c66@gmail.com \
    --to=akiyks@gmail.com \
    --cc=leobras.c@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=perfbook@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox