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.
I guess Arch Linux will get the Cairo upgrade soon after.
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
[...]
