unicodefont.tex is easy enough to use but I prefer the context one as it also lists the unicode names of the chars. Let me take a screenshot to show why this is important here
@daleif I'd say a matter of preference - you could ask Frank - I guess the downside with the ConTeXt one is it's going to need a lot of space (and it's reproducing a lot of UnicodeData.txt)
Say I have a font package, where for lualatex I use fontspec. I define a fontfamily using \newfontfamily, say a package option says we'd like this as the main font, can we use the font set fron \newfontfamily to set \setmainfont? or is a redef of \rmdefault enough?
Hello! What is the best way to detect whether the TeX engine in use is 8 bit with the engine's internal character encoding scheme having 256 different code point numbers? What is the best way to detect whether the TeX engine in use is utf-8 with the engine's internal character encoding scheme having 1114112 different code point numbers?
@UlrichDiez you can see some test in iftex.sty (which tests engine by name not by testing the functionality, so needs extending when new engines like hitex appear)
@UlrichDiez basically \ifdefined\Uchar Unicode\else not\fi but ptex variants are complicated they have more than 256 characters but not full unicode support
@DavidCarlisle Thanks. Then, is there a sensible way of detecting the amount of code point numbers of the internal character encoding scheme of the tex-engine in use?
@UlrichDiez if you ignore ptex then as I say \Uchar being defined is enough as luatex and xetex have that and that's what you are looking for, ptex have separate charcodes and kcharcodes (I forget the details) so it depends what you mean...
grr, why doesn't kpfonts have a scaling option for when one wants to use the math font with a different text font. (the otf version has scaling via unicode-math)
ahh, well then one have to scale the text font down to their level ;-)
(I'm not using Fira etc as there are symbols missing)
@DavidCarlisle I think it ends up beging too fidly, easier to just scale the text font, now that autoinst was kind enough to make support for it (I use the autoinst part for pdflatex and manual fontspec for xelatex and lualatex)
@DavidCarlisle With engines where \Ucharcat is not available I'd like to get an overview of all those character codes that can be paired witch category 1 resp. 2. Is \Uchar defined with all utf-8 TeX engines? Are there older releases, e.g., of xetex or luatex where this is not the case? Seems with pTeX there are more category codes, but...
..., , but i did not yet find an explanation that could be understood by someone who does not know how to read Japanese of the correlation between \kcatcode and \catcode and why the two are needed instead of just increasing the range of possible category codes and doing with \catcode alone.
@JasperHabicht Thank you for searching. I found that one, too. ;-) Seems by the property "kcatcode" characters that can occur in input files are divided in groups: A group for non-Japanese characters and several groups of Japanese characters. And seems during tokenization the property "catcode" is relevant only for characters of the group of non-Japanese characters while ....
... while I don't know exactly what categories during tokenization get assigned to characters of the groups of Japanese characters, but I suppose, these characters never get category 1 or 2. Also I don't know exactly what rôle the "kcatcode" plays when it comes to delimiter-matching with delimited macro arguments.
@UlrichDiez I only know Chinese, so it is like reading every third word ... but it seems that this is not explained in the Japanese manual ... it only tells you what you wil already know anyways: that if you try \message{\the\catcode"53E3} you will get a "bad character code" error ...
@UlrichDiez I wouldn't call them utf-8 engines but essentially only luatex (and luametatex) and xetex have unicode support in that sense and they both have \Uchar on ptex hang on there is an English reference....
@UlrichDiez ptex is more like a built in inputenc, the two byte JIS characters are seen as two characters but get a single kcatcode for the combination
@DavidCarlisle I found that reference, too. I even have it on my system. ;-) But seems I need to study a year or so for fully grasping how things are intertwined. Besides that, it says: "This English guide (ptex-guide-en.pdf) is not meant to be a complete translation of Japanese manual (ptex-manual.pdf) ..."
@DavidCarlisle Seems with pTeX the kcatcode is not stored with the token, so seems with pTeX the kcatcode is not a relevant criterion of a japanese character-token's "shape" when it comes to delimiter matching while with upTeX the kcatcode is stored with the token and might be a relevant criterion of a japanese character-token's "shape"...
@DavidCarlisle And currently I cannot just do some testing as I am in bed in the hospital where I don't have my computer available. ;-)
@JasperHabicht Thank you. Once more I find myself looking in the mirror and doing a facepalm at myself - latexmkrc, of course... I should have known that. Don't know whether I was thinking at all... :-( ... ;-)
@UlrichDiez I also often overlook these niceties of Overleaf actually. It is really a great tool for quickly checking things and doing stuff. At least, if you're fine with using a TeX Live version that is not bleeding edge =D
@JasperHabicht Thanks for your understanding. ;-) I like Overleaf for testing aspects of the workings of TeX while not having my own machine available... Some months ago I was positively surprised that Overleaf does even handle Knitr. ;-)
@JasperHabicht With non-(u)pTeX only characters with category code 11(letter) can be used for forming names of control word tokens during tokenization. Characters with category codes differing from 11 can only form names of control symbol tokens. Seems, with (u)pTeX characters with category codes differing from 11, 16, 17 and 19 can only form names of control symbol tokens while only characters of the category codes 11, 16, 17 and 19 can form components of names of control word tokens. ;-)
@JosephWright ;-) Nevertheless I should learn a bit more about it - one of my neighbours goes to university in april for studying japanology and he already pesters me with questions regarding usage of TeX until the crows come home, and I'd like to be useful sometimes. ;-)
@JasperHabicht :) It gets tricky with some fast-evolving things. (I mostly think of the accessibility work that's being done. It if were possible to isolate it, that would be cool, but it's obviously so deep in the guts of everything that you cannot do that really.)
@yo' I currently work on a project using l3draw and l3opacity ... and I built into my code a bunch of checks and fallbacks to make it work with TL23 and the most recent versions. It is a nice training =D
