[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: Pygments support for LilyPond

From: Jean Abou Samra
Subject: Re: ANN: Pygments support for LilyPond
Date: Sat, 27 Nov 2021 17:36:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

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.
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

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').


Attachment: after-extractpdfmark-and-gs.pdf
Description: Adobe PDF document

Attachment: without-extractpdfmark.pdf
Description: Adobe PDF document

Attachment: Bold_typewriter.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]