Re: ANN: Pygments support for LilyPond

[Jean Abou Samra]

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

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

without-extractpdfmark.pdf
Description: Adobe PDF document

Bold_typewriter.png
Description: PNG image