missing dejavusansmono in rrdtool pango cairo fontconfig

[Rainer Müller]

On 2018-05-02 22:17, macports at parvis.nl wrote:
> 
>> On 2018-05-02, at 16:15, Rainer Müller <raimue at macports.org> wrote:
>>
>> On 2018-05-02 12:44, macports at parvis.nl wrote:
>>> (...)
>>> Pango has a simple tool to show font examples:
>>> pango-view --backend=<backend> --text '   iiiiwwww  ' --font 'DejaVuSansMono 36' # execute in XQuartz
>>
>> I think this should be
>> --font 'DejaVu Sans Mono 36'
>> At least it only works for me with spaces when I manually install the font to /Library/Fonts/DejaVuSansMono.ttf.
> 
> It should work with and without spaces, even in lowercase:
> fc-match dejavusansmono
> DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
> fc-match 'dejavu sans mono'
> DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

Yes, fontconfig accepts that. But when using --backend=cairo and the
quartz renderer, fontconfig is not involved. In this case, the name has
to be specified with spaces, or the font can not be found and will be
substituted. Sorry if I was unclear.

It looks like all unknown fonts are just substituted with Helvetica for
the quartz renderer.

>> However, that is only necessary if rrdtool can only work correctly with "DejaVu Sans Mono". Would it be acceptable to use a different font that is always available for the time being? Even a generic 'monospace' should give similar results.
> 
> Munin, where I am currently working on, explicitly defines DejaVuSans and DejaVuSansMono. Both are substitued by Helvetica. That cannot be handled by a wrapper but requires patches, to Menlo for example.

Ah, I assumed this was about the default in rrdtool, which is specified
in the configure script:

   RRD_DEFAULT_FONT='"DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier"'

That could be overridden with the --with-rrd-default-font option to
something like Menlo.

If you can already identify where Munin specifies the font, then writing
a patch to change that to Menlo should be quite easy.

> I never would have thought that porting Munin was so complicated. I'd prefer to start with ddrescue and foremost, my heart lies at the OS and things like filesystems.

I am sorry your experience with updating Munin to 2.x was not the best.
You really hit a can of worms there.

If you do not want to pursue updating munin further, do you think it
would be worth to attach your work-in-progress Portfile to the Trac
ticket [1] for others to pick up?

Rainer

[1] https://trac.macports.org/ticket/36860