Menu
▾
▴
1 Attachments
#755 improved font selection in pdf terminal
Current font selection detects only attributes "Bold" and "Italic" in the font name.
Those are set via pango attributes, and pango maps to fontconfig (Mac OS X, probably same for Linux).
This patch for 5.2 rc2 detects many more attributes for weight, stretch, and style, and tries to set the proper family name.
The attachment contains the patch, as well as test files (which uses fonts installed on my system; change to your liking) and resulting PDFs before and after the patch.
This seems like a complicated addition that benefits only one terminal (OK, one family of terminals).
Is a more generic implementation possible? What exactly is the intended use case?
Note that the existing Bold and Italic properties are not treated as part of the font name per se but as separate, possibly transient, attributes that are applied on top of the current font. These additional properties are tracked and applied as requested by the enhanced text support routines, i.e. in the core code rather than being limited to a single terminal driver.
It is true that other than "bold", the weight and stretch font properties are not something that you would apply transiently. On the other hand treating them as part of the font name rather than as a separate attribute means that other terminals don't recognize the font at all. I.e. After this patch if you say
set label "Fancy label" font "Marker Felt-Thin" then the cairo terminals give you the requested font but all other terminals will fall back to "Sans" or something generic rather than to "Marker Felt" with the default weight and stretch.
So I would be more enthusiastic about an implementation that doesn't interfere with font name recognition by other terminals. I.e.currently a command like
set termopt font "Bookman:Italic"
is recognized by all terminals as requesting "Bookman" even if that terminal doesn't know about or doesn't support an italic variant of that font. At a minimum, I'd like to see the expanded attributes behave the same way, so
set termopt font "Marker Felt:Thin"
rather than
set termopt font "Marker Felt-Thin"
Dear Ethan, thanks for your comments, and sorry for my slow response.
The intended use case is when corporate identity or publication guidelines require the use of non-standard fonts (for high-quality printed material, or in my case mostly for presentations).
PDF is probably the most likely choice of terminal when you actually need full control over the fonts in your output. People probably care a bit less about fonts when they use e.g. pixel-based or interactive terminals, but I agree that it would be desirable that many terminals support the same "font name:attribute(s)" syntax.
So I tried what different terminals do when I use the colon ":" instead of the hyphen "-" in composite font names. There seemed to be no difference for PDF (I just used the hyphen as an old habit taken over from PostScript).
The libgd-based PNG and JPG show the desired fonts except for the Symbol font, but attributes mostly do not work (see attached fonttest-colon.png). SVG (displayed in Firefox on Mac OS Sierra) seems to set the "font-family" correctly (i.e. without attributes), but "Symbol" again does not work, and attributes also mostly don't. term/svg.trm has code to look for " bold" and " italic" strings, which is some cases sets the "font-weight" attribute in the svg file, e.g.
The X11 interactive terminal (again on the Mac, XQuartz) displays all fonts as some monospaced font except for "Times", "Helvetica", and "Symbol", which are recognized - but only if they have no extra parameters. So that terminal does not seem to support the colon notation.
Lastly, I tried the cairolatex terminal which writes tex code that does not switch fonts (I guess the point is to make the complete typesetting consistent with TeX, and anyway one has to manually make fonts available for TeX, defining font metrics and dvi-driver-dependent maps, e.g. with fontinst).
I did not try wxt with the patch because my build from the patched source did not have the required libraries. Without the patch (from a MacPorts installation) it looks like the pdf from the unpatched 5.2.rc2. But the patch changes code in the wxterminal folder, so I assume that wxt benefits too.
I also didn't try Windows and the many other device-dependent terminals.
In summary, I think that fine control over fonts may be a niche application but if you need it, it can save your day just by PDF support.
The notation "fontname:attributes" is already working to carry the required details. Many terminals support at least the fontname.
Maybe it is necessary to specify how multiple attributes should be separated, e.g. by space. PostScript names would rather connect them directly, but the patch supports both. The font name itself can definitely contain spaces. Then the issue of supporting attributes in more terminals is addressed more thoroughly.
I don't see how a more general solution could look like, except that the separation of font names and attributes could be a general function, and not located in wxterminal as the current patch is. Is that what you had in mind?
Best regards
Hanno