> On 2018-05-02, at 16:15, Rainer Müller <rai...@macports.org> wrote: > > On 2018-05-02 12:44, macpo...@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" >> (...) >> 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.