![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
Henning Hraban Ramm via ntg-context schrieb am 01.08.2021 um 19:33:
Hi, I’m trying to set up a “handwriting” font.
In the example below I’m using Comic Sans, because probably everyone has it available, IRL I’m using the commercial “Supernett Cn” that has more styles. (Also, I’m using Alegreya Serif + Sans.)
If I name it "ss/sans/Sans", it works as expected, but with "hw/handwriting/Handwriting" it only uses the regular font, never other styles.
"mtxrun --script fonts ..." shows that the configured files are found.
Is this a limitation in ConTeXt, or what did I wrong?
The handwritten and calligraphic style are limited to upright alternatives. I can only speculate why this is the case but I guess Hans owns no font families where this is necessary (e.g. Lucida Bright has only one file for handwriting and calligraphy).
Adding additional alternatives to both styles is possible but the included typescripts (e.g. for lucida bright ot) have to be checked and fixed. indeed the only reason is that lucida had handwritten and calligraphy as
On 8/1/2021 8:19 PM, Wolfgang Schuster via ntg-context wrote: part of the whole package nowadays i'd just define a separate typeset set for it (same for narrow or light or ...) so, then one just switches do "handwritterm rm" or "handwritten tt" (a similar argument is with smallcaps and oldstyle, often a limiuted subset in the past but features now) in general. if you compare mkii an dmkiv (lmtx) the main differences relate to encodings (8 bit and utf) and fonts (8 bit) and because in the original tex engine font encoding determines hyphenation, and input encoding can differ, we operate (on mkii) on font encoding / input encoding / coverage (in font) / stylistic variant axis at the same time while in mkiv we have basically one input encoding (in the end all all mapped onto utf) and unicode font encoding while everythign else is features if you add mixed math fonts and a limited set of families, you can imagien that the mkii font mechanis is rather complex also because we need to retain performance; some of thsn is still present in mkiv/lmtx unless we drop old-school type 1 setups (again it's the design sizes that complicate that but only cm had that so in the end we can as well drop that bit too) compact fonts on the other hand can also make us drop some left-over complexity but there's also the sentimental 'throw away good old tex code that performs well even when not needed' syndrome that then kicks in (especially when it took some effort to actually cook it up in tex, which is sometimes not trivial given the nature of the language) .. 'hw' and 'cg' fit a bit into this category too (and i only used it the mathml manual that dates from early mkii when we first used lucida, and the opentype lucidas are not even really nice for that any more due to some shape default changed) so, basically we have [rm,ss,tt] * [full font class changes] * [features] and performance wise there is no (performance) gain in more in the first category (typescript definitions come cheap) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------