> On 2018-05-02, at 16:15, Rainer Müller <[email protected]> wrote:
>
> On 2018-05-02 12:44, [email protected] 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"
>> (...)
>> I cannot oversee the consequences of disabling 'quartz' for cairo.
>
> The native macOS font renderer searches for fonts only in paths such as
> ~/Library/Fonts, /Library/Fonts, and /System/Library/Fonts as documented in
> [1]. There does not seem to be a way to extend that.
Indeed, symlinks don't work, copy does.
If you manually install DejaVu from /opt/local/share/fonts, FontBook complains
that it cannot validate, but FB is too picky here.
>
> We could install our fonts to a path such as /Library/Fonts/MacPorts/ to make
> them available to native applications by default. However, this would be a
> long-term solution as that requires changes in base for a ${fonts_dir} to be
> handled just like ${applications_dir}.
That is probably the best solution, but indeed for the long term.
>> On the pango mailing list, Behdad Esfahbod offered the solution to set
>> environment variable 'env var PANGOCAIRO_BACKEND=fc' and that works fine.
>
> While I agree this is a problem that should be solved for all ports, one
> workaround for rrdtool would be to use a simple shell script wrapper that
> exports this environment variable before executing the real binary.
Can do, but there are other applications that use fonts from macports. Making a
wrapper for all is also a lot of work, for a temporary solution.
> 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.
> Rainer
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.
Paul.
