[Sorry for Werner who will receive this email
twice, I initially sent it from an address that
is not subscribed to the list.]
Le 27/11/2021 à 17:36, Jean Abou Samra a écrit :
Excerpt from an email that became private more or
less by accident (I've asked Werner):
Anyway, as far as I know the package cfr-lm does provide LatinModern
monowidth typewriter italic, bold and bold italic.
https://ctan.org/pkg/cfr-lm
Yes, it does. However, there is no need to look at this package; the
fonts in question are from the 'lm' family, and there is no additional
value in 'cfr-lm' for the task at hand.
It is non-trivial to set 'lm' up for texinfo. Main reason is that
there is no 'OT1' font encoding (and its siblings for 'OT1TT' and
'OT1OT' for typewriter and italic, respectively) available – texinfo
is*not* suited to 'T1' encoding in general. It would thus be
necessary to set up virtual fonts (`.vf`) together with its metrics
files (`.tfm`), and those files had to be distributed with LilyPond.
Using CTAN's `fontinst` package it is not very complicated to create
such VFs, but we would also need to add proper CMap support to make
copy-and-paste work in PDFs. As you can see, there is*a lot* of
things to do.
Of course, you could argue that we only need to have fonts for the
`@example` environment. However, due to page breaking (which adds
page headers and footers and takes care of footnotes), I'm not sure
whether we could completely replace the fonts without interfering with
texinfo's output routines, which switches fonts forth and back.
Life would be much easier if we would drop pdfTeX support, using XeTeX
or luatex only. We could then directly use the OpenType font version
of 'lm', for example. However, I favor generic solutions for all
three TeX engines.
---------------------------
I tried this solution, and I am experiencing a few
problems. For one thing, Firefox doesn't render the
bold typewriter fonts as bold (this is not happening
in your pygments.pdf, but, for reasons I don't understand,
it happens with the doc build). Also, when extractpdfmark
is used and the TeX engine is XeTeX, GhostScript gives
errors:
Making Documentation/out-www/en/changes.pdf < texi
**** Error: File did not complete the page properly and may be
damaged.
Output may be incorrect.
**** Error: File did not complete the page properly and may be
damaged.
Output may be incorrect.
**** Error: File did not complete the page properly and may be
damaged.
Output may be incorrect.
**** Error: File did not complete the page properly and may be
damaged.
Output may be incorrect.
In this case, even Evince doesn't render the bold.
See the attached PDFs, without-extractpdfmark.pdf and
after-extractpdfmark-and-gs.pdf. (You'll find the
extractpdfmark and gs invocations in Documentation/GNUmakefile.)
The only difference is in the invocation, either
'make -C Documentation out=www out-www/en/changes.pdf' or
'make -C Documentation out=www USE_EXTRACTPDFMARK=no
out-www/en/changes.pdf'.
(In my environment, XeTeX is being used by default.)
Also, the bold text looks a bit 'hirsute' when zomming out
in Evince. I guess that's the hinting issue you mentioned.
I tried to reduce the boldness by changing the value 0.2
in common-macros.itexi but it didn't have an effect -- I
wonder what's going on.
Any ideas? You can reproduce all this by checking out
my branch (if you visit the merge request, GitLab
gives you command-line instructions in 'Check out branch').
Thanks,
Jean
I am not sure how I wrote this. For the most part,
it is plain wrong. I must have messed up in my tests.
So, the real story is that a specific combination
triggers the problem: XeTeX and extractpdfmark.
Here is a standalone reproducer: take your file
pygments.texinfo, and run
PDFTEX=xetex texi2pdf -o pygments-initial.pdf pygments.texinfo &&
extractpdfmark -o pygments.pdfmark pygments-initial.pdf && gs -dBATCH
-dNOSAFER -dNOPAUSE -sDEVICE=pdfwrite -dAutoRotatePages=/None
-dPrinted=false -sOutputFile=pygments-after-gs.pdf -c "30000000
setvmthreshold" -I out-fonts/ -I out-fonts/Font pygments.pdfmark
pygments-initial.pdf
(I am not sure why having built LilyPond and passing
"-I out-fonts -I out-fonts/Font" to gs is necessary.)
Without PDFTEX=xetex, all is fine. With it, you should get
GPL Ghostscript 9.54.0 (2021-03-30)
Copyright (C) 2021 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO
WARRANTY:
see the file COPYING for details.
Processing pages 1 through 1.
Page 1
**** Error: File did not complete the page properly and may be
damaged.
Output may be incorrect.
and the file pygments-after-gs.pdf, created from pygments-initial.pdf
through gs, will not display bold.
Also, forget about Firefox not displaying the bold glyphs.
It actually does, but much more lightly, which is why I
didn't notice it.