From: "Leonardo Brás" <leobras.c@gmail.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org, "Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH -perfbook 0/6] Update Dockerfiles
Date: Tue, 26 Sep 2023 23:49:34 -0300 [thread overview]
Message-ID: <2501287715c33675a6fac1e27cb27d09d97aefd9.camel@gmail.com> (raw)
In-Reply-To: <309f740a-b678-3983-2847-e1bd9b64e90c@gmail.com>
Hello Akira,
On Sat, 2023-09-23 at 08:52 +0900, Akira Yokosawa wrote:
> Hi Leo,
>
> Follow-up news on font info in PDF:
>
> On 2023/06/16 20:05, Akira Yokosawa wrote:
> > 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.
>
> It turns out there was a regression in Cairo 1.17.8 (released Feb 2, 2023).
> It was fixed in upstream Cairo on Feb 8, 2023.
> Soon-to-be-released Cairo 1.18.0 should have the fix.
Thanks for the update!
> I guess Arch Linux will get the Cairo upgrade soon after.
Today Cairo got updated to 1.18.0 in Arch Linux, and it totally fixes the issue.
Check this pipeline (fixed):
https://gitlab.com/linux-kernel/perfbook/-/pipelines/1017496054
The previous pipeline still reproduces the issue:
https://gitlab.com/linux-kernel/perfbook/-/pipelines/1014892578
Thanks!
Leo
>
> See: https://gitlab.freedesktop.org/cairo/cairo/-/issues/806
>
> Thanks, Akira
>
> >
> > 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
> [...]
next prev parent reply other threads:[~2023-09-27 2:49 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
2023-09-22 23:52 ` Akira Yokosawa
2023-09-27 2:49 ` Leonardo Brás [this message]
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=2501287715c33675a6fac1e27cb27d09d97aefd9.camel@gmail.com \
--to=leobras.c@gmail.com \
--cc=akiyks@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).